このページでは、サブネットワークやロード バランシングなど、Google Distributed Cloud 接続のネットワーキング機能について説明します。
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] ページに移動します。
[有効にする] をクリックします。
gcloud
次のコマンドを使用します。
gcloud services enable edgenetwork.googleapis.com
Distributed Cloud コネクテッドでネットワークを構成する
このセクションでは、Distributed Cloud 接続デプロイでネットワーキング コンポーネントを構成する方法について説明します。
Distributed Cloud 接続サーバーには、次の制限が適用されます。
- サブネットワークのみを構成できます。
- サブネットワークは VLAN ID のみをサポートします。CIDR ベースのサブネットワークはサポートされていません。
Distributed Cloud Connected の一般的なネットワーク構成は、次の手順で構成されます。
省略可: 必要に応じて、ターゲット ゾーンのネットワーク構成を初期化します。
ネットワークを作成する。
ネットワーク内に 1 つ以上のサブネットワークを作成します。
構成をテストします。
Pod をネットワークに接続します。
Distributed Cloud ゾーンのネットワーク構成を初期化する
Distributed Cloud 接続ハードウェアがオンプレミスにインストールされたら、すぐに Distributed Cloud 接続ゾーンのネットワーク構成を初期化する必要があります。ゾーンのネットワーク構成の初期化は、1 回限りの手順です。
ゾーンのネットワーク構成を初期化すると、default という名前のデフォルト ネットワークが作成されます。この構成により、Distributed Cloud 接続デプロイにローカル ネットワークへの基本的なアップリンク接続が提供されます。
手順については、ゾーンのネットワーク構成を初期化するをご覧ください。
ネットワークの作成
新しいネットワークを作成するには、ネットワークを作成するの手順に沿って操作します。Distributed Cloud 接続ノードがネットワークに接続できるようにするには、ネットワーク内に少なくとも 1 つのサブネットワークを作成する必要があります。
1 つ以上のサブネットワークを作成する
サブネットワークを作成するには、サブネットワークを作成するの手順に沿って操作します。ノードがネットワークにアクセスできるようにするには、ネットワークに少なくとも 1 つのサブネットワークを作成する必要があります。作成した各サブネットワークに対応する VLAN は、ゾーン内のすべてのノードで自動的に使用できます。
設定をテストする
作成したネットワーク コンポーネントの構成をテストするには、次の操作を行います。
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
アイランド モードが有効になっていることを確認するには、次の操作を行います。
テスト 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 ロードバランサ ノードでもあります。
ClusterDNS 個のリソース
Distributed Cloud connected は、spec.domains セクションを使用して特定のドメインのアップストリーム ネームサーバーを構成するための Google Distributed Cloud ClusterDNS リソースをサポートしています。このリソースの構成の詳細については、spec.domains をご覧ください。