このページでは、サブネットワークやロード バランシングなど、Google Distributed Cloud コネクテッドのネットワーク機能について説明します。
Distributed Cloud Edge Network API を有効にする
Distributed Cloud のコネクテッド デプロイでネットワークを構成する前に、Distributed Cloud Edge Network API を有効にする必要があります。これを行うには、このセクションの手順を完了します。デフォルトでは、Distributed Cloud コネクテッド サーバーには、Distributed Cloud Edge Network API がすでに有効になっています。
コンソール
コンソールで、 [Distributed Cloud Edge Network API] ページに移動します。 Google Cloud
[有効にする] をクリックします。
gcloud
次のコマンドを使用します。
gcloud services enable edgenetwork.googleapis.com
Distributed Cloud コネクテッドでネットワークを構成する
このセクションでは、Distributed Cloud コネクテッド デプロイでネットワーク コンポーネントを構成する方法について説明します。
Distributed Cloud コネクテッド サーバーには、次の制限が適用されます。
- サブネットワークのみを構成できます。
- サブネットワークは VLAN ID のみをサポートします。CIDR ベースのサブネットワークはサポートされていません。
Distributed Cloud コネクテッドの一般的なネットワーク構成は、次の手順で構成されます。
省略可: 必要に応じて、ターゲット ゾーンのネットワーク構成を初期化します。
ネットワークを作成する。
ネットワーク内に 1 つ以上のサブネットワークを作成します。
設定をテストする。
Pod をネットワークに接続する。
Distributed Cloud ゾーンのネットワーク構成を初期化する
オンプレミスに Distributed Cloud コネクテッド ハードウェアをインストールしたら、すぐに Distributed Cloud コネクテッド ゾーンのネットワーク構成を初期化する必要があります。ゾーンのネットワーク構成の初期化は、1 回限りの手順です。
ゾーンのネットワーク構成を初期化すると、default という名前のデフォルト ネットワークが作成されます。
この構成により、Distributed Cloud コネクテッド デプロイにローカル ネットワークへの基本的なアップリンク接続が提供されます。
手順については、 ゾーンのネットワーク構成を初期化するをご覧ください。
ネットワークを作成する
新しいネットワークを作成するには、 ネットワークを作成するの手順に沿って操作します。 また、Distributed Cloud コネクテッド ノードがネットワークに接続できるようにするには、ネットワーク内に少なくとも 1 つのサブネットワークを作成する必要があります。
1 つ以上のサブネットワークを作成する
サブネットワークを作成するには、 サブネットワークを作成するの手順に沿って操作します。 ノードがネットワークにアクセスできるようにするには、ネットワーク内に少なくとも 1 つのサブネットワークを作成する必要があります。作成した各サブネットワークに対応する VLAN は、ゾーン内のすべてのノードで自動的に使用できます。
設定をテストする
作成したネットワーク コンポーネントの構成をテストするには、次の操作を行います。
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
アイランド モードが有効になっていることを確認するには、次の操作を行います。
テスト 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"]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 には、レイヤ 2 モードのMetalLB に基づくネットワーク ロード バランシング ソリューションがバンドルされています。このソリューションを使用すると、仮想 IP アドレス(VIP)を使用して、Distributed Cloud ゾーンで実行されるサービスを外部に公開できます。
- ネットワーク管理者は、ネットワーク トポロジを計画し、Distributed Cloud の注文時に必要な仮想 IPv4 アドレス サブネットワークを指定します。Google は、配信前に Distributed Cloud ハードウェアを適切に構成します。
次の点に注意してください。
- この VIP サブネットワークは、Distributed Cloud ゾーン内で実行されるすべての Kubernetes クラスタ間で共有されます。
- サブネットワークの最初(ネットワーク ID)、2 番目(デフォルト ゲートウェイ)、最後(ブロードキャスト アドレス)のアドレスは、コア システム機能用に予約されています。これらのアドレスを MetalLB 構成のアドレスプールに割り当てないでください。
- 各クラスタは、構成された VIP サブネットワーク内の個別の VIP 範囲を使用する必要があります。
- Distributed Cloud ゾーンにクラスタを作成するときに、クラスタ管理者は CIDR 表記を使用して Pod と ClusterIP サービスのアドレスプールを指定します。ネットワーク管理者は、適切な
LoadBalancerVIP サブネットワークをクラスタ管理者に提供します。 クラスタが作成されたら、クラスタ管理者は対応する 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: falseVIP アドレスプールを指定するには、ペイロードに次の情報を指定します。
name: この VIP アドレスプールを一意に識別する説明的な名前。addresses: このアドレスプールに含める IPv4 アドレス、アドレス範囲、サブネットワークのリスト。avoid_buggy_ips:.0または.255で終わる IP アドレスを除外します。manual_assign: MetalLB コントローラが自動的に割り当てるのではなく、 ターゲットLoadBalancerサービスの構成でこのプールからアドレスを手動で割り当てることができます。
VIP アドレスプールの構成の詳細については、MetalLB ドキュメントの アドレスプールを指定する をご覧ください。
クラスタ管理者は、適切な Kubernetes
LoadBalancerサービスを作成します。
単一ノードプール内の Distributed Cloud ノードは共通のレイヤ 2 ドメインを共有するため、MetalLB ロードバランサ ノードでもあります。この手順に沿って操作すると、MetalLB を使用したレイヤ 2 ロード バランシングが自動的に構成されます。
ClusterDNS リソース
Distributed Cloud コネクテッドは、Google Distributed Cloud ClusterDNS
リソースをサポートしています。このリソースを使用すると、spec.domains
セクションを使用して、特定のドメインのアップストリーム ネームサーバーを構成できます。このリソースの構成の詳細については、spec.domains をご覧ください。