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

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

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

Distributed Cloud Edge Network API を有効にする

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

コンソール

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

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

gcloud

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

gcloud services enable edgenetwork.googleapis.com

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

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

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

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

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

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

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

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

サウスバウンド BGP ピアリングセッションを確立するには、次の操作を行います。

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

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

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

ループバック 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 Namespace の 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 サービスなしで 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 サービスタイプが含まれます。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 とサービスのネットワークアドレスの割り振り

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

Distributed Cloud Edge Network API を有効にする

コンソール

gcloud

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

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

ネットワークの作成

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` 個のリソース