このドキュメントでは、GKE on Bare Metal をインストールして操作するためのネットワーク要件について説明します。
外部ネットワークの要件
GKE on Bare Metal の操作にはインターネット接続が必要です。GKE on Bare Metal は、Container Registry からクラスタ コンポーネントを取得し、クラスタが コネクト に登録されます。
HTTPS、バーチャル プライベート ネットワーク（VPN）、または Dedicated Interconnect 接続を介して公共のインターネットを使用し、Google に接続できます。
管理ワークステーションとクラスタノードに使用しているマシンがプロキシ サーバーを使用してインターネットにアクセスする場合、プロキシ サーバーで特定の接続を許可する必要があります。詳細については、プロキシの背後でインストールするの前提条件のセクションをご覧ください。
内部ネットワークの要件
GKE on Bare Metal は、クラスタノード間のレイヤ 2 またはレイヤ 3 接続で動作します。ロードバランサ ノードは、コントロール プレーン ノードまたは専用ノードのセットです。詳細については、ロードバランサの選択と構成をご覧ください。
バンドルされたレイヤ 2 ロード バランシングを MetalLB とともに（spec.loadBalancer.mode: bundled と spec.loadBalancer.type: layer2）使用する場合、ロードバランサ ノードにはレイヤ 2 の隣接が必要です。レイヤ 2 の隣接要件は、ロードバランサをコントロール プレーン ノードで実行するか、専用のロード バランシング ノードのセットで実行するかに関係なく適用されます。BGP でバンドルされたロード バランシングはレイヤ 3 プロトコルをサポートしているため、厳格なレイヤ 2 の隣接は必要ありません。
ロードバランサ マシンの要件は次のとおりです。
- バンドルされたレイヤ 2 ロード バランシングの場合、特定のクラスタのすべてのロードバランサは、同じレイヤ 2 ドメインにあります。コントロール プレーン ノードも同じレイヤ 2 ドメインに存在する必要があります。
- バンドルされたレイヤ 2 ロード バランシングの場合、すべての仮想 IP アドレス（VIP）がロードバランサ マシンのサブネット内にあり、サブネットのゲートウェイにルーティング可能である必要があります。
- 上り（内向き）ロードバランサのトラフィックを許可することは、ユーザーの責任で行います。
Pod ネットワーク
GKE on Bare Metal では、ノードあたり最大 250 個の Pod を構成できます。Kubernetes は、各 Pod に一意の IP アドレスが指定されるように、クラスレス ドメイン間ルーティング（CIDR）ブロックを各ノードに割り当てます。CIDR ブロックのサイズは、1 ノードあたりの最大 Pod 数と対応します。ノードあたりの構成済み最大 Pod 数に基づいて、Kubernetes が各ノードに割り当てる CIDR ブロックのサイズを次の表に示します。
| ノードあたりの最大ポッド数 | ノードあたりの 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 の値を減らします。 この方法にはいくつかのデメリットがあります。
高可用性を備えた単一ユーザー クラスタのデプロイメント
次の図は、可能性のあるネットワーク構成における GKE on Bare Metal の主要なネットワーキングのいくつかのコンセプトを示しています。
ネットワーク要件を満たすために、次のことを検討してください。
- コントロール プレーン ノードがロードバランサを実行し、それらはすべてレイヤ 2 接続を有する一方で、ワーカーノードなどの他の接続ではレイヤ 3 接続のみが必要です。
- 構成ファイルでは、ワーカー ノードプールの IP アドレスが定義される。構成ファイルでは、次の目的のために VIP も定義される。
- サービス
- Ingress
- Kubernetes API を介したコントロール プレーンのアクセス
- Google Cloud への接続が必要。
ポートの使用状況
このセクションでは、GKE on Bare Metal クラスタのポート要件について説明します。次の表は、クラスタノードとロードバランサ ノード上の 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 名前空間で実行される 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）で GKE on Bare Metal を実行するために、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 フィールドで構成されているポッド用に予約された 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 フィールドで構成されているポッド用に予約された 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 フィールドで構成されているポッド用に予約された 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 を有効にして GKE on Bare Metal を実行している場合は、firewalld を変更すると、ホスト ネットワーク上の Cilium iptables が削除される場合があります。この iptables チェーンは、起動時に anetd Pod によって追加されます。Cilium の iptables チェーンが失なわれると、Node 上の Pod は、Node 外部のネットワーク接続を失います。
iptables チェーンが削除される firewalld の変更には、次に挙げるものがありますが、これに限定されません。
systemctlを使用したfirewalldの再起動コマンドライン クライアント（
firewall-cmd --reload）を使用したfirewalldの再読み込み
iptables チェーンを削除せずに firewalld の変更を適用するには、ノードで anetd を再起動します。
anetdは、次のコマンドを使用してanetdPod を見つけて削除することで再起動します。kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZANETD_XYZ は、
anetdPod の名前で置き換えます。