バージョン情報については、Distributed Cloud 接続のリリースノートをご覧ください。

Distributed Cloud のネットワーキング機能

このページでは、サブネットワーク、BGP ピアリングセッション、ロードバランシングなど、Google Distributed Cloud のネットワーキング機能について説明します。

Distributed Cloud Edge Network API を有効にする

Distributed Cloud ネットワーキングを構成する前に、Distributed Cloud Edge Network API を有効にする必要があります。手順は次のとおりです。

コンソール

コンソールで、 [Distributed Cloud Edge Network API] ページに移動します。 Google Cloud

API の有効化
[有効にする] をクリックします。

gcloud

次のコマンドを使用します。

gcloud services enable edgenetwork.googleapis.com

Distributed Cloud ネットワーキングを構成する

このセクションでは、Distributed Cloud ネットワーキングコンポーネントを構成する方法について説明します。

Distributed Cloud の一般的なネットワーク構成は、次の手順で構成されます。

省略可: 必要に応じて、ターゲットゾーンのネットワーク構成を初期化します。
ネットワークを作成する。
ネットワーク内に 1 つ以上のサブネットワークを作成します。
対応する相互接続アタッチメントを使用して、PE ルーターとのノースバウンド BGP ピアリングセッションを確立します。
対応するサブネットワークを使用して、ワークロードを実行する Pod とのサウスバウンド BGP ピアリングセッションを確立します。
省略可: 高可用性のためにループバック BGP ピアリングセッションを確立します。
設定をテストします。
Pod をネットワークに接続します。

省略可: Distributed Cloud ゾーンのネットワーク構成を初期化する

次のような場合は、Distributed Cloud ゾーンのネットワーク構成を初期化する必要があります。

Distributed Cloud ハードウェアがオンプレミスにインストールされた直後。
既存の Distributed Cloud デプロイで Distributed Cloud バージョン 1.3.0 以降にアップグレードしたが、Distributed Cloud Edge Network API のプライベートプレビューに参加していない場合。

ゾーンのネットワーク構成を初期化すると、default という名前のデフォルトルーターと default という名前のデフォルトネットワークが作成されます。また、Distributed Cloud ハードウェアを注文したときにリクエストしたすべての相互接続とピアリングするように default ルーターを構成します。これは、対応する相互接続アタッチメントを作成することで行われます。この構成により、Distributed Cloud デプロイにローカルネットワークへの基本的なアップリンク接続が提供されます。

ゾーンのネットワーク構成の初期化は 1 回限りの手順です。詳細な手順については、ゾーンのネットワーク構成を初期化するをご覧ください。

ネットワークを作成する

新しいネットワークを作成するには、ネットワークを作成するの手順に沿って操作します。また、Distributed Cloud ノードがネットワークに接続できるようにするには、ネットワーク内に少なくとも 1 つのサブネットワークを作成する必要があります。

1 つ以上のサブネットワークを作成する

サブネットワークを作成するには、サブネットワークを作成するの手順に沿って操作します。ノードがネットワークにアクセスできるようにするには、ネットワーク内に少なくとも 1 つのサブネットワークを作成する必要があります。作成した各サブネットワークに対応する VLAN は、ゾーン内のすべてのノードで自動的に使用できます。

ノースバウンド BGP ピアリングセッションを確立する

ネットワークとその対応するサブネットワークを作成すると、それらは Distributed Cloud ゾーンに対してローカルになります。アウトバウンド接続を有効にするには、ネットワークとピアリングエッジルーターの間に少なくとも 1 つのノースバウンド BGP ピアリングセッションを確立する必要があります。

ノースバウンド BGP ピアリングセッションを確立する手順は次のとおりです。

ゾーンで使用可能な相互接続を一覧表示し、このピアリングセッションのターゲット相互接続を選択します。
選択した相互接続に 1 つ以上の相互接続アタッチメントを作成します。相互接続アタッチメントは、次のステップで作成するルーターを選択した相互接続にリンクします。
ルーターを作成します。このルーターは、前のステップで作成した相互接続アタッチメントを使用して、相互接続とネットワーク間のトラフィックをルーティングします。
この手順で作成した相互接続アタッチメントごとに、ルーターにインターフェースを追加します。各インターフェースには、Distributed Cloud ラック内の対応するトップオブラック（ToR）スイッチの IP アドレスを使用します。手順については、ノースバウンドピアリングセッションを確立するをご覧ください。
ピアを追加します。前のステップでルーターに作成したインターフェースごと

サウスバウンド BGP ピアリングセッションを確立する

ローカルネットワークからワークロードへのインバウンド接続を有効にするには、ピアリングエッジルーターと Pod が属するサブネットワークの間に 1 つ以上のサウスバウンド BGP ピアリングセッションを確立する必要があります。各サブネットワークのゲートウェイ IP アドレスは、Distributed Cloud ラック内の対応する ToR スイッチの IP アドレスです。

サウスバウンド BGP ピアリングセッションを確立する手順は次のとおりです。

インバウンド接続でプロビジョニングするサブネットワークごとに、ターゲットネットワークのルーターにインターフェースを追加します。手順については、サウスバウンドピアリングセッションを確立するをご覧ください。
ピアを追加します前のステップでルーターに作成したインターフェースごとに。

省略可: ループバック BGP ピアリングセッションを確立する

ワークロードとローカルネットワーク間の高可用性接続を有効にするには、ターゲット Pod と Distributed Cloud ラック内の両方の ToR スイッチの間にループバック BGP ピアリングセッションを確立します。ループバックピアリングセッションは、Pod に対して 2 つの独立したピアリングセッションを確立します。1 つは各 ToR スイッチとのセッションです。

ループバック BGP ピアリングセッションを確立する手順は次のとおりです。

ターゲットネットワークのルーターにループバックインターフェースを追加します。手順については、ループバックピアリングセッションを確立するをご覧ください。
ピアを追加します。ループバックインターフェース

設定をテストする

作成したネットワークコンポーネントの構成をテストする手順は次のとおりです。

Pod をネットワークに接続する

Pod をネットワークに接続して高度なネットワーク機能を構成するには、ネットワーク機能オペレータの手順に沿って操作します。

ロードバランシング

Distributed Cloud には、レイヤ 2 モードのMetalLB に基づくネットワークロードバランシングソリューションがバンドルされています。このソリューションを使用すると、次のように仮想 IP アドレス（VIP）を使用して、Distributed Cloud ゾーンで実行されるサービスを外部に公開できます。

ネットワーク管理者は、ネットワークトポロジを計画し、Distributed Cloud の注文時に必要な仮想 IPv4 アドレスサブネットワークを指定します。Google は、配送前に Distributed Cloud ハードウェアを適切に構成します。次の点に注意してください。
- この VIP サブネットワークは、Distributed Cloud ゾーン内で実行されるすべての Kubernetes クラスタ間で共有されます。
- リクエストされた VIP サブネットワークのルートは、Distributed Cloud ゾーンとローカルネットワーク間の BGP セッションを通じてアドバタイズされます。
- サブネットワーク内の最初（ネットワーク ID）、2 番目（デフォルトゲートウェイ）、最後（ブロードキャストアドレス）のアドレスは、コアシステム機能用に予約されています。これらのアドレスを MetalLB 構成のアドレスプールに割り当てないでください。
- 各クラスタは、構成された VIP サブネットワーク内の個別の VIP 範囲を使用する必要があります。
Distributed Cloud ゾーンにクラスタを作成するときに、クラスタ管理者は CIDR 表記を使用して Pod と ClusterIP Service のアドレスプールを指定します。ネットワーク管理者は、適切な LoadBalancer VIP サブネットワークをクラスタ管理者に提供します。
クラスタが作成されたら、クラスタ管理者は対応する VIP プールを構成します。リモートコントロールプレーンクラスタの場合は、kubectl edit コマンドまたは kubectl replace コマンドを使用して、metallb-system 名前空間の metallb-config ConfigMap を編集する必要があります。kubectl apply コマンドは使用しないでください。使用すると、Distributed Cloud によって変更が上書きされます。

次の例は、このような構成を示しています。
```
# metallb-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: metallb-config
data:
  config: |
    address-pools:
    - name: default
      protocol: layer2
      addresses:
      - 192.168.1.2-192.168.1.254
```
ローカルコントロールプレーンクラスタの場合は、クラスタの作成時に --external-lb-ipv4-address-pools フラグを使用して VIP プールを指定する必要があります。詳細については、生存モードをご覧ください。
クラスタ管理者は、適切な Kubernetes LoadBalancer Service を作成します。

単一ノードプールの Distributed Cloud ノードは共通のレイヤ 2 ドメインを共有するため、MetalLB ロードバランサノードでもあります。 Google Cloud で実行される Distributed Cloud コントロールプレーンノードは、ロードバランサノードとして機能しません。

Distributed Cloud Ingress

Distributed Cloud は、ロードバランシングに加えて、Kubernetes Ingress リソースもサポートしています。Kubernetes Ingress リソースは、Distributed Cloud クラスタで実行される Kubernetes Service への HTTP(S) トラフィックのフローを制御します。次の例は、一般的な Ingress リソースを示しています。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
      paths:
      - backend:
          service:
            name: my-service
            port:
              number: 80
        path: /foo
        pathType: Prefix

構成すると、ネットワークトラフィックは istio-ingress Service を通過します。この Service には、デフォルトで MetalLB 構成で指定された VIP プールからランダムな IP アドレスが割り当てられます。istio-ingress Service 定義の loadBalancerIP フィールドを使用して、MetalLB 構成から特定の IP アドレスまたは仮想 IP アドレスを選択できます。次に例を示します。

apiVersion: v1
kind: Service
metadata:
  labels:
    istio: ingress-gke-system
    release: istio
  name: istio-ingress
  namespace: gke-system
spec:
  loadBalancerIP: <targetLoadBalancerIPaddress>

デフォルトの Distributed Cloud `Ingress` リソースを無効にする

デフォルトでは、Distributed Cloud クラスタを作成すると、Distributed Cloud によってクラスタの istio-ingress Service が自動的に構成されます。istio-ingress Service なしで Distributed Cloud クラスタを作成することもできます。手順は次のとおりです。

gcloud

次の内容で SystemsAddonConfig.yaml という名前の YAML 構成ファイルを作成します。
```
systemAddonsConfig:
 ingress:
   disabled: true
```
クラスタ作成コマンドで --system-addons-config フラグを使用して、SystemsAddonConfig.yaml ファイルを渡します。この機能を使用するには、gcloud alpha バージョンを使用する必要があります。次に例を示します。
```
gcloud alpha edge-cloud container clusters create MyGDCECluster1 --location us-west1 \
    --system-addons-config=SystemsAddonConfig.yaml
```
Distributed Cloud クラスタの作成の詳細については、クラスタを作成するをご覧ください。

API

クラスタ作成リクエストの JSON ペイロードに次の JSON コンテンツを追加します。
```
"systemAddonConfig" {
   "ingress" {
           "disabled": true
   }
}
```
クラスタを作成するの説明に従って、クラスタ作成リクエストを送信します。

SCTP のサポート

Distributed Cloud は、内部ネットワーキングと外部ネットワーキングの両方で、プライマリネットワークインターフェース上の Stream Control Transmission Protocol（SCTP）をサポートしています。SCTP のサポートには、NodePort、LoadBalancer、ClusterIP の Service タイプが含まれます。Pod は SCTP を使用して、他の Pod や外部リソースと通信できます。次の例は、SCTP を使用して IPERF を ClusterIP Service として構成する方法を示しています。

apiVersion: v1
kind: Pod
metadata:
  name: iperf3-sctp-server-client
  labels:
    app.kubernetes.io/name: iperf3-sctp-server-client
spec:
  containers:
  - name: iperf3-sctp-server
    args: ['-s', '-p 31390']
    ports:
      - containerPort: 31390
        protocol: SCTP
        name: server-sctp
  - name: iperf3-sctp-client
    ...

---

apiVersion: v1
kind: Service
metadata:
  name: iperf3-sctp-svc
spec:
  selector:
    app.kubernetes.io/name: iperf3-sctp-server-client
  ports:
    - port: 31390
      protocol: SCTP
      targetPort: server-sctp

SCTP カーネルモジュール

バージョン 1.5.0 以降では、Distributed Cloud は sctp Edge OS カーネルモジュールをロード可能として構成します。これにより、カーネルユーザー空間に独自の SCTP プロトコルスタックをロードできます。

また、Distributed Cloud はデフォルトで次のモジュールをカーネルにロードします。

モジュール名	構成名
`fou`	`CONFIG_NET_FOU`
`nf_conntrack_proto_gre`	`CONFIG_NF_CT_PROTO_GRE`
`nf_conntrack_proto_sctp`	`CONFIG_NF_CT_PROTO_SCTP`
`inotify`	`CONFIG_INOTIFY_USER`
`xt_redirect`	`CONFIG_NETFILTER_XT_TARGET_REDIRECT`
`xt_u32`	`CONFIG_NETFILTER_XT_MATCH_U32`
`xt_multiport`	`CONFIG_NETFILTER_XT_MATCH_MULTIPORT`
`xt_statistic`	`CONFIG_NETFILTER_XT_MATCH_STATISTIC`
`xt_owner`	`CONFIG_NETFILTER_XT_MATCH_OWNER`
`xt_conntrack`	`CONFIG_NETFILTER_XT_MATCH_CONNTRACK`
`xt_mark`	`CONFIG_NETFILTER_XT_MARK`
`ip6table_mangle`	`CONFIG_IP6_NF_MANGLE`
`ip6_tables`	`CONFIG_IP6_NF_IPTABLES`
`ip6table_filter`	`CONFIG_IP6_NF_FILTER`
`ip6t_reject`	`CONFIG_IP6_NF_TARGET_REJECT`
`iptable_mangle`	`CONFIG_IP_NF_MANGLE`
`ip_tables`	`CONFIG_IP_NF_IPTABLES`
`iptable_filter`	`CONFIG_IP_NF_FILTER`

`ClusterDNS` リソース

Distributed Cloud は、spec.domains セクションを使用して、特定のドメインのアップストリームネームサーバーを構成するための Google Distributed Cloud ClusterDNS リソースをサポートしています。このリソースの構成の詳細については、spec.domains をご覧ください。

次のステップ

Pod と Service のネットワークアドレス割り当て

Distributed Cloud のネットワーキング機能 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

Distributed Cloud Edge Network API を有効にする

コンソール

gcloud

Distributed Cloud ネットワーキングを構成する

省略可: Distributed Cloud ゾーンのネットワーク構成を初期化する

ネットワークを作成する

1 つ以上のサブネットワークを作成する

ノースバウンド BGP ピアリング セッションを確立する

サウスバウンド BGP ピアリング セッションを確立する

省略可: ループバック BGP ピアリング セッションを確立する

設定をテストする

Pod をネットワークに接続する

ロード バランシング

Distributed Cloud Ingress

デフォルトの Distributed Cloud Ingress リソースを無効にする

gcloud

API

SCTP のサポート

SCTP カーネル モジュール

ClusterDNS リソース

次のステップ

Distributed Cloud のネットワーキング機能

ノースバウンド BGP ピアリングセッションを確立する

サウスバウンド BGP ピアリングセッションを確立する

省略可: ループバック BGP ピアリングセッションを確立する

ロードバランシング

デフォルトの Distributed Cloud `Ingress` リソースを無効にする

SCTP カーネルモジュール

`ClusterDNS` リソース