このドキュメントでは、Google Distributed Cloud をインストールして操作するためのネットワーク要件について説明します。
外部ネットワークの要件
Google Distributed Cloud の操作にはインターネット接続が必要です。Google Distributed Cloud は Container Registry からクラスタ コンポーネントを取得し、クラスタは Connect に登録されます。
HTTPS、バーチャル プライベート ネットワーク(VPN)、または Dedicated Interconnect 接続を介して公共のインターネットを使用し、Google に接続できます。
管理ワークステーションとクラスタノードに使用しているマシンがプロキシ サーバーを使用してインターネットにアクセスする場合、プロキシ サーバーで特定の接続を許可する必要があります。詳細については、プロキシの背後でインストールするの前提条件のセクションをご覧ください。
内部ネットワークの要件
Google Distributed Cloud は、クラスタノード間のレイヤ 2 またはレイヤ 3 接続で動作します。ロードバランサ ノードは、コントロール プレーン ノードまたは専用ノードのセットです。詳細については、ロードバランサの選択と構成をご覧ください。
MetalLB にバンドルされたレイヤ 2 ロード バランシング(spec.loadBalancer.mode: bundled
と spec.loadBalancer.type: layer2
)を使用する場合、ロードバランサ ノードにはレイヤ 2 の隣接が必要です。レイヤ 2 の隣接要件は、ロードバランサをコントロール プレーン ノードで実行するか、専用のロード バランシング ノードのセットで実行するかに関係なく適用されます。BGP にバンドルされたロード バランシングはレイヤ 3 プロトコルをサポートしているため、厳格なレイヤ 2 の隣接は必要ありません。
ロードバランサ マシンの要件は次のとおりです。
- バンドルされたレイヤ 2 ロード バランシングの場合、特定のクラスタのすべてのロードバランサは、同じレイヤ 2 ドメインにあります。コントロール プレーン ノードも同じレイヤ 2 ドメインに存在する必要があります。
- バンドルされたレイヤ 2 ロード バランシングの場合、すべての仮想 IP アドレス(VIP)がロードバランサ マシンのサブネット内にあり、サブネットのゲートウェイにルーティング可能である必要があります。
- 上り(内向き)ロードバランサのトラフィックの許可は、ユーザー側の責任となります。
Pod ネットワーク
Google Distributed Cloud では、ノードあたり最大 250 個の Pod を構成できます。Kubernetes は、各 Pod に一意の IP アドレスが指定されるように、クラスレス ドメイン間ルーティング(CIDR)ブロックを各ノードに割り当てます。CIDR ブロックのサイズは、ノードあたりの最大 Pod 数に対応します。ノードあたりの構成済み最大 Pod 数に基づいて、Kubernetes が各ノードに割り当てる CIDR ブロックのサイズを次の表に示します。
ノードあたりの最大 Pod 数 | ノードあたりの CIDR ブロック | IP アドレスの数 |
---|---|---|
32 | /26 | 64 |
33~64 | /25 | 128 |
65~128 | /24 | 256 |
129~250 | /23 | 512 |
ノードあたり 250 個の Pod を実行するには、Kubernetes がノードごとに /23
CIDR ブロックを予約する必要があります。クラスタで clusterNetwork.pods.cidrBlocks
フィールドにデフォルト値の /16
が使用されている場合、クラスタの上限は、(2(23-16)) = 128 ノードです。この上限を超えてクラスタを拡張する場合は、clusterNetwork.pods.cidrBlocks
の値を増やすか、nodeConfig.podDensity.maxPodsPerNode
の値を減らします。この方法にはいくつかのデメリットがありました。
高可用性を備えた単一ユーザー クラスタのデプロイ
次の図は、一般的なネットワーク構成における Google Distributed Cloud の主要なネットワーキングのコンセプトを示しています。
ネットワーク要件を満たすために、次のことを検討してください。
- コントロール プレーン ノードがロードバランサを実行し、それらはすべてレイヤ 2 接続を使用します。ワーカーノードなどの他の接続ではレイヤ 3 接続のみが必要です。
- 構成ファイルでは、ワーカー ノードプールの IP アドレスが定義されます。構成ファイルでは、次の目的のために VIP も定義されます。
- Service
- Ingress
- Kubernetes API を介したコントロール プレーンのアクセス
- Google Cloud への接続が必要です。
ポートの使用状況
このセクションでは、Google Distributed Cloud クラスタのポート要件について説明します。次の表は、クラスタノードとロードバランサ ノード上の Kubernetes コンポーネントで UDP ポートと TCP ポートがどのように使用されるかを示しています。
コントロール プレーン ノード
バージョン 1.28
プロトコル | 方向 | ポート範囲 | 目的 | 使用者 |
---|---|---|---|---|
TCP | インバウンド | 22 | 管理クラスタノードのプロビジョニングと更新 | 管理ワークステーション |
TCP | インバウンド | 2379~2381 | etcd サーバー クライアント API、指標、健全性 | kube-apiserver と etcd |
TCP | インバウンド | 2382~2384 | etcd イベント サーバー クライアント API、指標、健全性 | kube-apiserver と etcd-events |
TCP | 両方 | 4240 | CNI ヘルスチェック | すべて |
UDP | インバウンド | 6081 | GENEVE カプセル化 | セルフ |
TCP | インバウンド | 6444 | Kubernetes API サーバー | すべて |
TCP | インバウンド | 8443 と 8444 | GKE Identity Service v2 | anthos-identity-service Namespace で実行される ais Deployment |
TCP | インバウンド | 9100 | auth-proxy | node-exporter |
TCP | インバウンド | 9101 | ローカルホストでのみノード指標を提供 (バージョン 1.28 以降で追加されたポートの要件) |
node-exporter |
TCP | インバウンド | 9977 | API サーバーから監査イベントを受信 | audit-proxy |
TCP | インバウンド | 10250 | kubelet API |
セルフとコントロール プレーン |
TCP | インバウンド | 10256 | ノードのヘルスチェック | すべて |
TCP | インバウンド | 10257 | kube-controller-manager (ポート番号はバージョン 1.28 以降で変更されました) |
セルフ |
TCP | インバウンド | 10259 | kube-scheduler (ポート番号はバージョン 1.28 以降で変更されました) |
セルフ |
TCP | インバウンド | 14443 | ANG Webhook サービス | kube-apiserver と ang-controller-manager |
バージョン 1.16
プロトコル | 方向 | ポート範囲 | 目的 | 使用者 |
---|---|---|---|---|
TCP | インバウンド | 22 | 管理クラスタノードのプロビジョニングと更新 | 管理ワークステーション |
TCP | インバウンド | 2379~2381 | etcd サーバー クライアント API、指標、健全性 | kube-apiserver と etcd |
TCP | インバウンド | 2382~2384 | etcd イベント サーバー クライアント API、指標、健全性 (バージョン 1.16 以降で追加されたポートの要件) |
kube-apiserver と etcd-events |
TCP | 両方 | 4240 | CNI ヘルスチェック | すべて |
UDP | インバウンド | 6081 | GENEVE カプセル化 | セルフ |
TCP | インバウンド | 6444 | Kubernetes API サーバー | すべて |
TCP | インバウンド | 9100 | 指標を提供 | node-exporter |
TCP | インバウンド | 9443 | コントロール プレーン コンポーネントの提供 / プロキシ指標(このポート要件はクラスタ バージョン 1.16 以前用です) | kube-control-plane-metrics-proxy |
TCP | インバウンド | 9977 | API サーバーから監査イベントを受信 | audit-proxy |
TCP | インバウンド | 10250 | kubelet API |
セルフとコントロール プレーン |
TCP | インバウンド | 10251 | kube-scheduler |
セルフ |
TCP | インバウンド | 10252 | kube-controller-manager |
セルフ |
TCP | インバウンド | 10256 | ノードのヘルスチェック | すべて |
TCP | インバウンド | 14443 | ANG Webhook サービス | kube-apiserver と ang-controller-manager |
バージョン 1.15 以前
プロトコル | 方向 | ポート範囲 | 目的 | 使用者 |
---|---|---|---|---|
TCP | インバウンド | 22 | 管理クラスタノードのプロビジョニングと更新 | 管理ワークステーション |
TCP | インバウンド | 2379~2381 | etcd サーバー クライアント API、指標、健全性 | kube-apiserver と etcd |
TCP | 両方 | 4240 | CNI ヘルスチェック | すべて |
UDP | インバウンド | 6081 | GENEVE カプセル化 | セルフ |
TCP | インバウンド | 6444 | Kubernetes API サーバー | すべて |
TCP | インバウンド | 9100 | 指標を提供 | node-exporter |
TCP | インバウンド | 9443 | コントロール プレーン コンポーネントの提供 / プロキシ指標(このポート要件はクラスタ バージョン 1.16 以前用です) | kube-control-plane-metrics-proxy |
TCP | インバウンド | 9977 | API サーバーから監査イベントを受信 | audit-proxy |
TCP | インバウンド | 10250 | kubelet API |
セルフとコントロール プレーン |
TCP | インバウンド | 10251 | kube-scheduler |
セルフ |
TCP | インバウンド | 10252 | kube-controller-manager |
セルフ |
TCP | インバウンド | 10256 | ノードのヘルスチェック | すべて |
TCP | インバウンド | 14443 | ANG Webhook サービス | kube-apiserver と ang-controller-manager |
ワーカーノード
バージョン 1.28
プロトコル | 方向 | ポート範囲 | 目的 | 使用者 |
---|---|---|---|---|
TCP | インバウンド | 22 | ユーザー クラスタ ノードのプロビジョニングと更新 | 管理クラスタノード |
TCP | 両方 | 4240 | CNI ヘルスチェック | すべて |
UDP | インバウンド | 6081 | GENEVE カプセル化 | セルフ |
TCP | インバウンド | 9100 | auth-proxy | node-exporter |
TCP | インバウンド | 9101 | ローカルホストでのみノード指標を提供 (バージョン 1.28 以降で追加されたポートの要件) |
node-exporter |
TCP | インバウンド | 10250 | kubelet API |
セルフとコントロール プレーン |
TCP | インバウンド | 10256 | ノードのヘルスチェック | すべて |
TCP | インバウンド | 30000~32767 | NodePort サービス |
セルフ |
バージョン 1.16
プロトコル | 方向 | ポート範囲 | 目的 | 使用者 |
---|---|---|---|---|
TCP | インバウンド | 22 | ユーザー クラスタ ノードのプロビジョニングと更新 | 管理クラスタノード |
TCP | 両方 | 4240 | CNI ヘルスチェック | すべて |
UDP | インバウンド | 6081 | GENEVE カプセル化 | セルフ |
TCP | インバウンド | 9100 | 指標を提供 | node-exporter |
TCP | インバウンド | 10250 | kubelet API |
セルフとコントロール プレーン |
TCP | インバウンド | 10256 | ノードのヘルスチェック | すべて |
TCP | インバウンド | 30000~32767 | NodePort サービス |
セルフ |
バージョン 1.15 以前
プロトコル | 方向 | ポート範囲 | 目的 | 使用者 |
---|---|---|---|---|
TCP | インバウンド | 22 | ユーザー クラスタ ノードのプロビジョニングと更新 | 管理クラスタノード |
TCP | 両方 | 4240 | CNI ヘルスチェック | すべて |
UDP | インバウンド | 6081 | GENEVE カプセル化 | セルフ |
TCP | インバウンド | 10250 | kubelet API |
セルフとコントロール プレーン |
TCP | インバウンド | 10256 | ノードのヘルスチェック | すべて |
TCP | インバウンド | 30000~32767 | NodePort サービス |
セルフ |
ロードバランサ ノード
バージョン 1.28
プロトコル | 方向 | ポート範囲 | 目的 | 使用者 |
---|---|---|---|---|
TCP | インバウンド | 22 | ユーザー クラスタ ノードのプロビジョニングと更新 | 管理クラスタノード |
TCP | インバウンド | 443 | クラスタ管理 このポートは、クラスタ構成ファイルで |
すべて |
TCP | 両方 | 4240 | CNI ヘルスチェック | すべて |
UDP | インバウンド | 6081 | GENEVE カプセル化 | セルフ |
TCP と UDP | インバウンド | 7946 | MetalLB ヘルスチェック | ロードバランサ ノード |
TCP | インバウンド | 10256 | ノードのヘルスチェック | すべて |
バージョン 1.16
プロトコル | 方向 | ポート範囲 | 目的 | 使用者 |
---|---|---|---|---|
TCP | インバウンド | 22 | ユーザー クラスタ ノードのプロビジョニングと更新 | 管理クラスタノード |
TCP | インバウンド | 443 | クラスタ管理 このポートは、クラスタ構成ファイルで |
すべて |
TCP | 両方 | 4240 | CNI ヘルスチェック | すべて |
UDP | インバウンド | 6081 | GENEVE カプセル化 | セルフ |
TCP | インバウンド | 7946 | MetalLB ヘルスチェック | ロードバランサ ノード |
TCP | インバウンド | 10256 | ノードのヘルスチェック | すべて |
バージョン 1.15 以前
プロトコル | 方向 | ポート範囲 | 目的 | 使用者 |
---|---|---|---|---|
TCP | インバウンド | 22 | ユーザー クラスタ ノードのプロビジョニングと更新 | 管理クラスタノード |
TCP | インバウンド | 443 | クラスタ管理 このポートは、クラスタ構成ファイルで |
すべて |
TCP | 両方 | 4240 | CNI ヘルスチェック | すべて |
UDP | インバウンド | 6081 | GENEVE カプセル化 | セルフ |
TCP | インバウンド | 7946 | MetalLB ヘルスチェック | ロードバランサ ノード |
TCP | インバウンド | 10256 | ノードのヘルスチェック | すべて |
マルチクラスタ ポートの要件
マルチクラスタ構成では、追加クラスタが管理クラスタと通信するため、次のポートを含める必要があります。
プロトコル | 方向 | ポート範囲 | 目的 | 使用者 |
---|---|---|---|---|
TCP | インバウンド | 22 | クラスタノードのプロビジョニングと更新 | すべてのノード |
TCP | インバウンド | 443 | 追加クラスタ用の Kubernetes API サーバー このポートは、クラスタ構成ファイルで |
コントロール プレーンとロードバランサのノード |
ファイアウォール ポートを構成する
Red Hat Enterprise Linux(RHEL)で Google Distributed Cloud を実行するために、firewalld を無効にする必要はありません。firewalld を使用するには、このページのポートの使用状況に記載されているように、コントロール プレーン ノード、ワーカー ノード、ロードバランサ ノードが使用する UDP ポートと TCP ポートを開く必要があります。次の構成例では、firewall-cmd
(firewalld コマンドライン ユーティリティ)を使用してポートを開く方法を示します。これらのコマンドは、root ユーザーとして実行する必要があります。
コントロール プレーン ノードの構成例
次のコマンド ブロックでは、コントロール プレーン ノードを実行しているサーバーで必要なポートを開く方法を示します。
firewall-cmd --permanent --zone=public --add-port=22/tcp
firewall-cmd --permanent --zone=public --add-port=4240/tcp
firewall-cmd --permanent --zone=public --add-port=6444/tcp
firewall-cmd --permanent --zone=public --add-port=6081/udp
firewall-cmd --permanent --zone=public --add-port=10250-10252/tcp
firewall-cmd --permanent --zone=public --add-port=10256/tcp
firewall-cmd --permanent --zone=public --add-port=2379-2380/tcp
firewall-cmd --permanent --zone=public --add-port=443/tcp
firewall-cmd --permanent --zone=public --add-port=30000-32767/tcp
firewall-cmd --permanent --new-zone=k8s-pods
firewall-cmd --permanent --zone=k8s-pods --add-source PODS_CIDR
firewall-cmd --permanent --zone=k8s-pods --set-target=ACCEPT
firewall-cmd --reload
PODS_CIDR
は、clusterNetwork.pods.cidrBlocks
フィールドで構成されている Pod 用に予約された CIDR ブロックに置き換えます。Pod 用のデフォルトの CIDR ブロックは 192.168.0.0/16
です。
ワーカーノードの構成例
次のコマンド ブロックでは、ワーカーノードを実行しているサーバーで必要なポートを開く方法の例を示します。
firewall-cmd --permanent --zone=public --add-port=22/tcp
firewall-cmd --permanent --zone=public --add-port=4240/tcp
firewall-cmd --permanent --zone=public --add-port=6444/tcp
firewall-cmd --permanent --zone=public --add-port=6081/udp
firewall-cmd --permanent --zone=public --add-port=10250/tcp
firewall-cmd --permanent --zone=public --add-port=10256/tcp
firewall-cmd --permanent --zone=public --add-port=443/tcp
firewall-cmd --permanent --zone=public --add-port=30000-32767/tcp
firewall-cmd --permanent --new-zone=k8s-pods
firewall-cmd --permanent --zone=k8s-pods --add-source PODS_CIDR
firewall-cmd --permanent --zone=k8s-pods --set-target=ACCEPT
firewall-cmd --reload
PODS_CIDR
は、clusterNetwork.pods.cidrBlocks
フィールドで構成されている Pod 用に予約された CIDR ブロックに置き換えます。Pod 用のデフォルトの CIDR ブロックは 192.168.0.0/16
です。
ロードバランサ ノードの構成例
次のコマンド ブロックでは、ロードバランサ ノードを実行しているサーバーで必要なポートを開く方法の例を示します。
firewall-cmd --permanent --zone=public --add-port=22/tcp
firewall-cmd --permanent --zone=public --add-port=4240/tcp
firewall-cmd --permanent --zone=public --add-port=6444/tcp
firewall-cmd --permanent --zone=public --add-port=7946/tcp
firewall-cmd --permanent --zone=public --add-port=7946/udp
firewall-cmd --permanent --zone=public --add-port=6081/udp
firewall-cmd --permanent --zone=public --add-port=10250/tcp
firewall-cmd --permanent --zone=public --add-port=10256/tcp
firewall-cmd --permanent --zone=public --add-port=443/tcp
firewall-cmd --permanent --zone=public --add-port=30000-32767/tcp
firewall-cmd --permanent --new-zone=k8s-pods
firewall-cmd --permanent --zone=k8s-pods --add-source PODS_CIDR
firewall-cmd --permanent --zone=k8s-pods --set-target=ACCEPT
firewall-cmd --reload
PODS_CIDR
は、clusterNetwork.pods.cidrBlocks
フィールドで構成されている Pod 用に予約された CIDR ブロックに置き換えます。Pod 用のデフォルトの CIDR ブロックは 192.168.0.0/16
です。
ポート構成を確認する
ポート構成を確認するには、コントロール プレーン ノード、ワーカーノード、ロードバランサ ノードで次の操作を行います。
次の Network Mapper コマンドを実行して、開いているポートを確認します。
nmap localhost
次のコマンドを実行して、firewalld 構成設定を取得します。
firewall-cmd --zone=public --list-all-policies firewall-cmd --zone=public --list-ports firewall-cmd --zone=public --list-services firewall-cmd --zone=k8s-pods --list-all-policies firewall-cmd --zone=k8s-pods --list-ports firewall-cmd --zone=k8s-pods --list-services
必要に応じて、前のセクションのコマンドを再実行してノードを適切に構成します。root ユーザーとしてコマンドを実行することが必要な場合があります。
firewalld の既知の問題
Red Hat Enterprise Linux(RHEL)で firewalld
を有効にして Google Distributed Cloud を実行している場合は、firewalld
を変更すると、ホスト ネットワーク上の Cilium iptables
が削除される場合があります。この iptables
チェーンは、起動時に anetd
Pod によって追加されます。Cilium の iptables
チェーンが失なわれると、Node 上の Pod は、ノード外部のネットワーク接続を失います。
iptables
チェーンが削除される firewalld
の変更には、次に挙げるものがありますが、これに限定されません。
systemctl
を使用したfirewalld
の再起動コマンドライン クライアント(
firewall-cmd --reload
)を使用したfirewalld
の再読み込み
iptables
チェーンを削除せずに firewalld
の変更を適用するには、ノードで anetd
を再起動します。
次のコマンドを使用して
anetd
Pod を見つけて削除して、anetd
を再起動します。kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZ
ANETD_XYZ は、
anetd
Pod の名前で置き換えます。