ネットワークの要件

このドキュメントでは、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: bundledspec.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 の主要なネットワーキングのコンセプトを示しています。

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-apiserveretcd
TCP インバウンド 2382~2384 etcd イベント サーバー クライアント API、指標、健全性 kube-apiserveretcd-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-apiserverang-controller-manager

バージョン 1.16

プロトコル 方向 ポート範囲 目的 使用者
TCP インバウンド 22 管理クラスタノードのプロビジョニングと更新 管理ワークステーション
TCP インバウンド 2379~2381 etcd サーバー クライアント API、指標、健全性 kube-apiserveretcd
TCP インバウンド 2382~2384 etcd イベント サーバー クライアント API、指標、健全性

(バージョン 1.16 以降で追加されたポートの要件)

kube-apiserveretcd-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-apiserverang-controller-manager

バージョン 1.15 以前

プロトコル 方向 ポート範囲 目的 使用者
TCP インバウンド 22 管理クラスタノードのプロビジョニングと更新 管理ワークステーション
TCP インバウンド 2379~2381 etcd サーバー クライアント API、指標、健全性 kube-apiserveretcd
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-apiserverang-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 クラスタ管理

このポートは、クラスタ構成ファイルで controlPlaneLBPort フィールドを使用して構成できます。

すべて
TCP 両方 4240 CNI ヘルスチェック すべて
UDP インバウンド 6081 GENEVE カプセル化 セルフ
TCP と UDP インバウンド 7946 MetalLB ヘルスチェック ロードバランサ ノード
TCP インバウンド 10256 ノードのヘルスチェック すべて

バージョン 1.16

プロトコル 方向 ポート範囲 目的 使用者
TCP インバウンド 22 ユーザー クラスタ ノードのプロビジョニングと更新 管理クラスタノード
TCP インバウンド 443 クラスタ管理

このポートは、クラスタ構成ファイルで controlPlaneLBPort フィールドを使用して構成できます。

すべて
TCP 両方 4240 CNI ヘルスチェック すべて
UDP インバウンド 6081 GENEVE カプセル化 セルフ
TCP インバウンド 7946 MetalLB ヘルスチェック ロードバランサ ノード
TCP インバウンド 10256 ノードのヘルスチェック すべて

バージョン 1.15 以前

プロトコル 方向 ポート範囲 目的 使用者
TCP インバウンド 22 ユーザー クラスタ ノードのプロビジョニングと更新 管理クラスタノード
TCP インバウンド 443 クラスタ管理

このポートは、クラスタ構成ファイルで controlPlaneLBPort フィールドを使用して構成できます。

すべて
TCP 両方 4240 CNI ヘルスチェック すべて
UDP インバウンド 6081 GENEVE カプセル化 セルフ
TCP インバウンド 7946 MetalLB ヘルスチェック ロードバランサ ノード
TCP インバウンド 10256 ノードのヘルスチェック すべて

マルチクラスタ ポートの要件

マルチクラスタ構成では、追加クラスタが管理クラスタと通信するため、次のポートを含める必要があります。

プロトコル 方向 ポート範囲 目的 使用者
TCP インバウンド 22 クラスタノードのプロビジョニングと更新 すべてのノード
TCP インバウンド 443 追加クラスタ用の Kubernetes API サーバー

このポートは、クラスタ構成ファイルで controlPlaneLBPort フィールドを使用して構成できます。

コントロール プレーンとロードバランサのノード

ファイアウォール ポートを構成する

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 です。

ポート構成を確認する

ポート構成を確認するには、コントロール プレーン ノード、ワーカーノード、ロードバランサ ノードで次の操作を行います。

  1. 次の Network Mapper コマンドを実行して、開いているポートを確認します。

    nmap localhost
    
  2. 次のコマンドを実行して、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
    
  3. 必要に応じて、前のセクションのコマンドを再実行してノードを適切に構成します。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 を再起動します。

  1. 次のコマンドを使用して anetd Pod を見つけて削除して、anetd を再起動します。

    kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZ
    

    ANETD_XYZ は、anetd Pod の名前で置き換えます。