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

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 デュアルスタッククラスタへのワークロードのデプロイの詳細については、以下をご覧ください。

Distributed Cloud Edge Network API を有効にする

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 接続サーバーには、次の制限が適用されます。

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

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

省略可: 必要に応じて、ターゲットゾーンのネットワーク構成を初期化します。
ネットワークを作成する。
ネットワーク内に 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 は、ゾーン内のすべてのノードで自動的に使用できます。

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

ノースバウンド 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 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 ゾーンで実行されているサービスを外部に公開できます。

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

次の内容で 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
   }
}
```
クラスタを作成するの説明に沿って、クラスタ作成リクエストを送信します。

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 とサービスのネットワークアドレスの割り振り

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

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

Distributed Cloud Edge Network API を有効にする

コンソール

gcloud

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

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

ネットワークの作成

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

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

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

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

設定をテストする

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

負荷分散

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

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

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

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

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

Distributed Cloud Ingress

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

gcloud

API

NodePort サービス

SCTP のサポート

SCTP カーネル モジュール

ClusterDNS 個のリソース

次のステップ

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

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

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

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

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

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

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

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

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

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

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

SCTP カーネルモジュール

`ClusterDNS` 個のリソース