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

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

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

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

Distributed Cloud コネクテッドを使用すると、IPv4/IPv6 デュアルスタック ネットワーキングを使用するクラスタを作成できます。この機能を利用するには、デュアルスタック IPv4/IPv6 ネットワーキングを有効にして Distributed Cloud コネクテッドを注文する必要があります。Distributed Cloud コネクテッドの既存の IPv4 のみのデプロイを IPv4/IPv6 デュアルスタック ネットワーキングに再構成することはできません。デプロイで 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 デュアルスタック クラスタへのワークロードのデプロイの詳細については、以下をご覧ください。

Distributed Cloud Edge Network API を有効にする

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

コンソール

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

    API の有効化

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

gcloud

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

gcloud services enable edgenetwork.googleapis.com

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

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

Distributed Cloud コネクテッド サーバーには、次の制限が適用されます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ネットワークを作成する

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

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

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

Distributed Cloud コネクテッド サーバーの場合、VLAN ID を使用してサブネットワークを構成することしかできません。CIDR ベースのサブネットワークは対象外です。

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

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

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

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

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

  3. ルーターを作成します。このルーターは、前のステップで作成した Interconnect アタッチメントを使用して、Interconnect とネットワーク間のトラフィックをルーティングします。

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

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

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

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

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

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

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

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

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

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

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

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

設定をテストする

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

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

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

  3. Interconnect の動作ステータスを確認します。

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

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

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

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

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

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

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

Distributed Cloud コネクテッドは、仮想ネットワーキング サブシステムでアイランド モードをサポートしています。アイランド モードでは、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 サービスでアイランド モードを構成するには、前のセクションの手順を完了し、 networking.gke.io/gke-gateway-clusterip-cidr アノテーションを Network リソース に追加して、ビジネスニーズに応じて値を設定します。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 コネクテッドには、次のロード バランシング ソリューションが付属しています。

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

Distributed Cloud コネクテッドに組み込まれているロード バランシング ソリューションでは、重複する Kubernetes Service 仮想 IP 接頭辞を使用できません。レイヤ 2 MetalLB ロード バランシングを使用する既存の Distributed Cloud コネクテッド デプロイがあり、Google Distributed Cloud ロードバランサを使用してレイヤ 3 ロード バランシングに切り替える場合は、レイヤ 2 MetalLB ロード バランシング構成で使用されている接頭辞と重複しない Service 仮想 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 Service のアドレスプールを指定します。ネットワーク管理者は、適切な 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 Service の構成でこのプールからアドレスを手動で割り当てることができます。

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

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

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

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

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

対応する LoadBalancer Service の 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 Service に、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 Service を作成する

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

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 Service が 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 上り（内向き）

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 コネクテッド サーバーでは使用できません。

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

デフォルトでは、Distributed Cloud コネクテッド クラスタを作成すると、Distributed Cloud はクラスタの istio-ingress Service を自動的に構成します。istio-ingress Service なしで 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 Service

Distributed Cloud コネクテッドは、任意のポート番号で Distributed Cloud ノードの接続をリッスンする Kubernetes NodePort Service をサポートしています。NodePort Service は、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 コネクテッドは、内部ネットワーキングと外部ネットワーキングの両方で、プライマリ ネットワーク インターフェース上の 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

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

この機能は、Distributed Cloud コネクテッド サーバーでは使用できません。

次のステップ