Distributed Cloud コネクテッドのネットワーキング機能

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

このページの手順は、Distributed Cloud 接続ラックにのみ適用されます。ただし、ロード バランシングは Distributed Cloud 接続ラックと Distributed Cloud 接続サーバーの両方に適用されます。

IPv4 / IPv6 デュアルスタック ネットワーキング

Distributed Cloud Connected を使用すると、IPv4/IPv6 デュアルスタック ネットワーキングを使用するクラスタを作成できます。この機能を利用するには、デュアルスタック IPv4/IPv6 ネットワーキングが有効になっている Distributed Cloud を注文する必要があります。IPv4/IPv6 デュアルスタック ネットワーキングに接続されている Distributed Cloud の既存の IPv4 専用デプロイを再構成することはできません。デプロイで IPv4/IPv6 デュアルスタック ネットワーキングがサポートされているかどうかを確認するには、マシンの情報を取得するの手順に沿って、dualstack_capable ラベルの戻り値を確認します。

デュアルスタック クラスタでは、IPv4 スタックはアイランド モードを使用し、IPv6 スタックはフラットモードを使用します。そのため、同じサブネットワークに属する個別のノードと Pod の IPv6 アドレスを指定する必要があります。詳細については、フラットモードとアイランド モードのネットワーク モデルをご覧ください。

たとえば、Distributed Cloud 接続ノードと他のローカル マシンが同じレイヤ 2 ドメインにある場合は、クラスタの IPv6 CIDR ブロックを次のように指定できます。

ブロックの目的	ブロック範囲	ブロックサイズ
IPv6 サブネットワーク	fd12::/56	2^72
Pod	fd12::1:0/59	2^69
サービス	fd12::2:0/59	2^69

この例では、次のことを前提としています。

• ノード、Pod、Service の CIDR ブロックは fd:12::/56 スーパーネットワークに属しています。
• ノード、Pod、Service の IP アドレスは、指定された CIDR ブロックのサブネットワークです。
• サブネットワークが重複していない。

IPv4/IPv6 デュアルスタック ネットワーキングでは、IPv4 BGP ピアリングにレイヤ 2 ロード バランシング、IPv6 ピアリングにレイヤ 3 ロード バランシングが必要です。詳細については、ロード バランシングをご覧ください。

IPv4/IPv6 デュアルスタック クラスタへのワークロードのデプロイの詳細については、以下をご覧ください。

• IPv4 / IPv6 デュアルスタック ネットワーキング
• IPv4/IPv6 デュアルスタック

Distributed Cloud Edge Network API を有効にする

Distributed Cloud の接続されたデプロイでネットワーキングを構成する前に、Distributed Cloud Edge Network API を有効にする必要があります。手順は次のとおりです。デフォルトでは、Distributed Cloud コネクテッド サーバーには Distributed Cloud Edge Network API がすでに有効になっています。

コンソール

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

   API の有効化

2. [有効にする] をクリックします。

gcloud

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

gcloud services enable edgenetwork.googleapis.com

Distributed Cloud コネクテッドでネットワークを構成する

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

Distributed Cloud 接続サーバーには、次の制限が適用されます。

• サブネットワークのみを構成できます。
• サブネットワークは VLAN ID のみをサポートします。CIDR ベースのサブネットワークはサポートされていません。

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

1. 省略可: 必要に応じて、ターゲット ゾーンのネットワーク構成を初期化します。

2. ネットワークを作成する。

3. ネットワーク内に 1 つ以上のサブネットワークを作成します。

4. 対応するインターコネクト アタッチメントを使用して、PE ルーターとのノースバウンド BGP ピアリング セッションを確立します。

5. 対応するサブネットワークを使用して、ワークロードを実行する Pod とサウスバウンド BGP ピアリング セッションを確立します。

6. 省略可: 高可用性のためにループバック BGP ピアリング セッションを確立します。

7. 構成をテストします。

8. Pod をネットワークに接続します。

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

Distributed Cloud 接続ハードウェアがオンプレミスにインストールされたら、すぐに Distributed Cloud 接続ゾーンのネットワーク構成を初期化する必要があります。ゾーンのネットワーク構成の初期化は、1 回限りの手順です。

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

手順については、ゾーンのネットワーク構成を初期化するをご覧ください。

ネットワークの作成

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

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

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

Distributed Cloud 接続サーバーの場合、VLAN ID を使用してサブネットワークを構成することしかできません。CIDR ベースのサブネットワークはサポートされていません。

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

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

アップストリーム BGP ピアリング セッションを確立するには、次の操作を行います。

1. ゾーンで使用可能な相互接続を一覧表示し、このピアリング セッションのターゲット相互接続を選択します。

2. 選択した相互接続に 1 つ以上の相互接続アタッチメントを作成します。Interconnect アタッチメントは、次のステップで作成するルーターを選択した相互接続にリンクします。

3. ルーターを作成する。このルーターは、前の手順で作成した相互接続アタッチメントを使用して、相互接続とネットワーク間のトラフィックをルーティングします。

4. この手順で作成した相互接続アタッチメントごとに、ルーターにインターフェースを追加します。各インターフェースには、Distributed Cloud 接続ラック内の対応するトップオブラック（ToR）スイッチの IP アドレスを使用します。手順については、ノースバウンド ピアリング セッションを確立するをご覧ください。

5. 前の手順でルーターに作成したインターフェースごとにピアを追加します。

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

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

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

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

2. 前の手順でルーターに作成したインターフェースごとにピアを追加します。

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

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

ループバック BGP ピアリング セッションを確立するには、次の操作を行います。

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

2. ループバック インターフェースのピアを追加します。

設定をテストする

作成したネットワーク コンポーネントの構成をテストするには、次の操作を行います。

1. ネットワークの運用ステータスを確認します。

2. 各サブネットワークのプロビジョニング ステータスを確認します。

3. 相互接続の動作ステータスを確認します。

4. 相互接続アタッチメントの動作ステータスを確認します。

5. ルーターの動作ステータスを確認します。

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

Pod をネットワークに接続して高度なネットワーク機能を構成するには、ネットワーク機能オペレータの手順に沿って操作します。この機能は、仮想マシンのワークロードでは使用できません。

（省略可）クラスタ ネットワーク分離を構成する

Distributed Cloud connected は、クラスタ ネットワークの分離をサポートしています。ネットワーク分離クラスタに割り当てられたノードは、同じ Distributed Cloud 接続ゾーン内の他のノードと通信できません。クラスタ ネットワーク分離を有効にするには、クラスタの作成または変更時に --enable-cluster-isolation フラグを使用します。詳細については、クラスタの作成と管理をご覧ください。

（省略可）アイランド モードを構成する

Distributed Cloud connected は、仮想ネットワーキング サブシステムのアイランド モードをサポートしています。アイランド モードでは、Pod のセカンダリ ネットワーク インターフェースに分離された IP アドレス範囲を指定できます。この分離されたアドレス範囲は、プライマリ ネットワーク インターフェース VLAN のアドレス範囲とは独立しています。アイランド モード用に構成された Pod には、この分離された「アイランド」アドレス範囲のアドレスのみが割り当てられます。詳細については、フラットモードとアイランド モードのネットワーク モデルをご覧ください。

アイランド モード用に指定する分離された IP アドレス範囲は、次の IP アドレス範囲と競合しないようにする必要があります。

• クラスタで構成されたネットワークのプライマリ VLAN CIDR
• Network リソースの networking.gke.io/gdce-lb-service-vip-cidrs アノテーションで指定されたロードバランサの仮想 IP アドレス範囲
• クラスタ内の他のネットワークのアイランド モードに使用される IP アドレス範囲

アイランド モードを設定する

Pod レベルでアイランド モードを構成するには、対応する Network カスタム リソースに networking.gke.io/gdce-pod-cidr アノテーションを追加します。アノテーション値を分離されたターゲット IP アドレス範囲に設定し、変更した Network リソースをクラスタに適用します。次に例を示します。

networking.gke.io/gdce-pod-cidr: 172.15.10.32/27

次のパラメータも設定する必要があります。

• type を L3 に設定する必要があります。
• IPAMMode を Internal に設定する必要があります。

次に例を示します。

apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: my-network
  annotations:
    # Enable island mode and specify the isolated address range.
    networking.gke.io/gdce-pod-cidr: 172.15.10.32/27
    # Specify the VLAN ID for this secondary network.
    networking.gke.io/gdce-vlan-id: "561"
    # Specify the CIDR block for load balancer services on this network.
    networking.gke.io/gdce-lb-service-vip-cidrs: 172.20.5.180/30
spec:
  # Network type must be L3 for island mode.
  type: L3
  # IPAMMode must be Internal for island mode.
  IPAMMode: Internal
  nodeInterfaceMatcher:
    interfaceName: gdcenet0.561 # The name for the target network interface.
  gateway4: 172.20.5.177 # Gateway IP address; must be unique in this CR.
  externalDHCP4: false
  dnsConfig:
    nameservers:
    - 8.8.8.8

アイランド モードが有効になっていることを確認するには、次の操作を行います。

1. テスト Pod を作成してクラスタに適用します。次に例を示します。

   apiVersion: v1
   kind: Pod
   metadata:
     name: island-pod-tester
     annotations:
       networking.gke.io/interfaces: '[{"interfaceName":"eth1","network":"test-network-vlan561"}]'
       networking.gke.io/default-interface: "eth1"
   spec:
     containers:
     - name: sample-container
       image: busybox
       command: ["/bin/sh", "-c", "sleep 3600"]
   

2. Pod の IP アドレスを取得します。

   kubectl get pod island-pod-tester -o wide
   

   このコマンドは、指定した分離アドレス範囲内の Pod の IP アドレスを返します。

ClusterIP サービスを使用してアイランド モードを構成する

ClusterIP サービスでアイランド モードを構成するには、前のセクションの手順を完了してから、Network リソースに networking.gke.io/gke-gateway-clusterip-cidr アノテーションを追加し、ビジネスニーズに応じて値を設定します。Network リソースで指定されたアドレス範囲は重複してはいけません。次に例を示します。

apiVersion: networking.gke.io/v1
kind: Network
metadata:
  annotations:
    networking.gke.io/gdce-lb-service-vip-cidrs: 172.20.5.180/30
    networking.gke.io/gdce-pod-cidr: 172.15.10.32/27
    networking.gke.io/gdce-vlan-id: "561"
    networking.gke.io/gke-gateway-clusterip-cidr: 10.20.1.0/28
  name: test-network-vlan561
spec:
  IPAMMode: Internal
  dnsConfig:
    nameservers:
    - 8.8.8.8
  externalDHCP4: false
  gateway4: 172.20.5.177
  nodeInterfaceMatcher:
    interfaceName: gdcenet0.561
  type: L3

負荷分散

Distributed Cloud connected には、次のロード バランシング ソリューションが付属しています。

• MetalLB を使用したレイヤ 2 ロード バランシング
• Google Distributed Cloud ロードバランサを使用したレイヤ 3 ロード バランシング

Distributed Cloud connected に組み込まれているロード バランシング ソリューションでは、重複する Kubernetes サービス仮想 IP プレフィックスを使用できません。レイヤ 2 の MetalLB ロード バランシングを使用する既存の Distributed Cloud 接続デプロイがあり、Google Distributed Cloud ロードバランサでレイヤ 3 ロード バランシングに切り替える場合は、レイヤ 2 の MetalLB ロード バランシング構成で使用されるプレフィックスと重複しないサービス仮想 IP プレフィックスを使用する必要があります。

MetalLB を使用したレイヤ 2 ロード バランシング

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

1. ネットワーク管理者は、ネットワーク トポロジを計画し、Distributed Cloud の注文時に必要な仮想 IPv4 アドレスと IPv6 アドレスのサブネットワークを指定します。Google は、配送前に Distributed Cloud ハードウェアを適切に構成します。次の点にご注意ください。
   • この VIP サブネットワークは、Distributed Cloud ゾーン内で実行されるすべての Kubernetes クラスタで共有されます。
   • リクエストされた VIP サブネットワークのルートは、Distributed Cloud ゾーンとローカル ネットワーク間の BGP セッションを介してアドバタイズされます。
   • サブネットワークの最初（ネットワーク ID）、2 番目（デフォルト ゲートウェイ）、最後（ブロードキャスト アドレス）のアドレスは、コア システム機能用に予約されています。これらのアドレスを MetalLB 構成のアドレスプールに割り当てないでください。
   • 各クラスタは、構成された VIP サブネットワーク内の個別の VIP 範囲を使用する必要があります。
2. Distributed Cloud ゾーンにクラスタを作成するときに、クラスタ管理者は CIDR 表記を使用して Pod と ClusterIP サービスのアドレスプールを指定します。ネットワーク管理者は、適切な LoadBalancer VIP サブネットワークをクラスタ管理者に提供します。

3. クラスタが作成されると、クラスタ管理者は対応する VIP プールを構成します。クラスタの作成時に --external-lb-address-pools フラグを使用して VIP プールを指定する必要があります。このフラグは、次の形式の YAML または JSON ペイロードを含むファイルを受け入れます。

    addressPools:
    - name: foo
      addresses:
      - 10.2.0.212-10.2.0.221
      - fd12::4:101-fd12::4:110
      avoid_buggy_ips: true
      manual_assign: false
   
    - name: bar
      addresses:
      - 10.2.0.202-10.2.0.203
      - fd12::4:101-fd12::4:102
      avoid_buggy_ips: true
      manual_assign: false
   

   VIP アドレス プールを指定するには、ペイロードに次の情報を指定します。

   • name: この VIP アドレス プールを一意に識別する説明的な名前。
   • addresses: このアドレスプールに含める IPv4 アドレス、IPv6 アドレス、アドレス範囲、サブネットワークのリスト。
   • avoid_buggy_ips: .0 または .255 で終わる IP アドレスを除外します。
   • manual_assign: MetalLB コントローラが自動的に割り当てるのではなく、ターゲット LoadBalancer サービスの構成でこのプールからアドレスを手動で割り当てることができます。

   VIP アドレスプールの構成の詳細については、MetalLB ドキュメントのアドレスプールを指定するをご覧ください。

4. クラスタ管理者は、適切な Kubernetes LoadBalancer サービスを作成します。

単一のノードプール内の Distributed Cloud ノードは共通のレイヤ 2 ドメインを共有するため、MetalLB ロードバランサ ノードでもあります。

Google Distributed Cloud ロードバランサを使用したレイヤ 3 ロード バランシング

Distributed Cloud Connected には、BGP スピーカーとして構成されたレイヤ 3 モードの Google Distributed Cloud バンドル ロードバランサに基づくネットワーク ロード バランシング ソリューションのバンドルが付属しています。このソリューションを使用すると、Distributed Cloud 接続ゾーンで実行されているサービスを VIP を使用して外部に公開できます。

対応する LoadBalancer サービスの VIP 範囲は、metallb-config ConfigMap を使用して指定できます。次に例を示します。

kind: ConfigMap
apiVersion: v1
data:
  config: |
    address-pools:
    - name: default
      protocol: bgp
      addresses:
      - 10.100.10.66/27
metadata:
  name: metallb-config
  namespace: metallb-system

上記の例では、構成した各 LoadBalancer サービスに、ConfigMap で指定された 10.100.10.66/27 範囲の仮想 IP アドレスが自動的に割り当てられます。これらの VIP は、BGPPeer リソースを介して ToR スイッチに構成された Distributed Cloud BGP スピーカーによって北方向にアドバタイズされます。

Distributed Cloud クラスタを作成すると、次のリソースがそのクラスタに自動的に作成されます。

• BGP ロードバランサをインスタンス化する BGPLoadBalancer リソース。
• BGP スピーカーに使用するローカル フローティング IP アドレスを指定する NetworkGatewayGroup リソース。これらの IP アドレスは、クラスタに割り当てられた Kubernetes ノード サブネットワークの最後の 2 つの IP アドレスに自動的に設定されます。

これらのリソースを配置したら、対応する BGPPeer リソースを構成して、Distributed Cloud ToR スイッチへの BGP セッションを設定できます。これを行うには、必要な自律システム番号（ASN）と ToR スイッチのループバック ピア IP アドレスが必要です。これらの IP アドレスは、デフォルトのネットワーク リソース上の ToR スイッチ BGP セッション エンドポイントとして機能します。network パラメータの値は pod-network である必要があります。

2 つの BGPPeer リソースの例を次に示します。

kind: BGPPeer
apiVersion: networking.gke.io/v1
metadata:
  name: bgppeertor1
  labels:
    cluster.baremetal.gke.io/default-peer: "true"
  namespace: kube-system
spec:
  network: pod-network
  localASN: 64777
  peerASN: 64956
  peerIP: 10.112.0.10
  sessions: 1

kind: BGPPeer
apiVersion: networking.gke.io/v1
metadata:
  name: bgppeertor2
  labels:
    cluster.baremetal.gke.io/default-peer: "true"
  namespace: kube-system
spec:
  network: pod-network
  localASN: 64777
  peerASN: 64956
  peerIP: 10.112.0.11
  sessions: 1

IPv6 ピアリング用にレイヤ 3 BGP ロード バランシングの自動化を構成する

IPv4/IPv6 デュアルスタック ネットワーキング クラスタで IPv6 ピアリングの使用を開始する前に、Google サポートと協力して、Distributed Cloud 接続デプロイで Google Distributed Cloud ロードバランサの自動化を有効にする必要があります。

レイヤ 3 LoadBalancer サービスを作成する

Distributed Cloud 接続デプロイで Google Distributed Cloud ロードバランサの自動化を有効にしたら、レイヤ 3 LoadBalancer サービスをインスタンス化します。次に例を示します。

apiVersion: v1
kind: Service
metadata:
  name: my-service
  labels:
    app.kubernetes.io/name: MyApp
spec:
  ipFamilyPolicy: PreferDualStack
  ipFamilies:
  - IPv6
  - IPv4
  selector:
    app.kubernetes.io/name: MyApp
  type: LoadBalancer
  ports:
    - protocol: TCP
      port: 80

BGP セッションとロード バランシング サービスのステータスを確認する

BGP セッションの状態を確認するには、次のコマンドを使用します。

kubectl get bgpsessions.networking.gke.io -A

このコマンドでは、次の例のような出力が返されます。

NAMESPACE     NAME                                                 LOCAL ASN   PEER ASN   LOCAL IP        PEER IP         STATE            LAST REPORT
kube-system   bgppeertor1-np-den6-120demo-den6-04-6ad5b6f4         64777       64956      10.100.10.61    10.112.0.10     Established      2s
kube-system   bgppeertor2-np-den6-120demo-den6-04-6ad5b6f4         64777       64956      10.100.10.61    10.112.0.11     Established      2s

LoadBalancer サービスが BGP スピーカーによってアドバタイズされていることを確認するには、次のコマンドを使用します。

kubectl get bgpadvertisedroutes.networking.gke.io -A

このコマンドでは、次の例のような出力が返されます。

NAMESPACE      NAME                           PREFIX            METRIC
kube-system    bgplb-default-service-tcp      10.100.10.68/32
kube-system    bgplb-default-service-udp      10.100.10.77/32

Distributed Cloud Ingress

Distributed Cloud Connected は、ロード バランシングに加えて、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 サービス定義の 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 接続サーバーでは使用できません。

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

デフォルトでは、Distributed Cloud 接続クラスタを作成すると、Distributed Cloud はクラスタの istio-ingress サービスを自動的に構成します。istio-ingress サービスなしで Distributed Cloud 接続クラスタを作成することもできます。手順は次のとおりです。

gcloud

1. 次の内容で SystemsAddonConfig.yaml という名前の YAML 構成ファイルを作成します。

   systemAddonsConfig:
    ingress:
      disabled: true
   

2. クラスタ作成コマンドで --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

1. クラスタ作成リクエストの JSON ペイロードに次の JSON コンテンツを追加します。

   "systemAddonConfig" {
      "ingress" {
              "disabled": true
      }
   }
   

2. クラスタを作成するの説明に沿って、クラスタ作成リクエストを送信します。

NodePort サービス

Distributed Cloud Connected は、選択したポート番号で Distributed Cloud ノードの接続をリッスンする Kubernetes NodePort サービスをサポートしています。NodePort サービスは、TCP、UDP、SCTP プロトコルをサポートしています。次に例を示します。

apiVersion: v1
kind: pod
metadata:
  name: socat-nodeport-sctp
  labels:
    app.kubernetes.io/name: socat-nodeport-sctp
spec:
  containers:
  - name: socat-nodeport-sctp
    ...
    ports:
      - containerPort: 31333
        protocol: SCTP
        name: server-sctp

---

apiVersion: v1
kind: service
metadata:
  name: socat-nodeport-sctp-svc
spec:
  type: NodePort
  selector:
    app.kubernetes.io/name: socat-nodeport-sctp
  ports:
    - port: 31333
      protocol: SCTP
      targetPort: server-sctp
      nodePort: 31333

SCTP のサポート

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

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

この機能は、Distributed Cloud 接続サーバーでは使用できません。

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

この機能は、Distributed Cloud 接続サーバーでは使用できません。

次のステップ

• Pod とサービスのネットワーク アドレスの割り振り