このドキュメントでは、Google Distributed Cloud をインストールして運用するためのネットワーク要件について説明します。
このページは、基盤となる技術インフラストラクチャのライフサイクルを管理し、組織のネットワークを設計する管理者、アーキテクト、オペレーター、ネットワーク スペシャリストを対象としています。Google Cloud のコンテンツで参照する一般的なロールとタスク例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。
外部ネットワークの要件
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.29
| プロトコル | 方向 | ポート範囲 | 目的 | 使用者 |
|---|---|---|---|---|
| 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 | インバウンド | 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 | インバウンド | 11002 | GKE Identity Service コアコンテナは hostPort を介してポートにバインドされます（バージョン 1.29 以降に適用） |
セルフ |
| TCP | インバウンド | 14443 | ANG Webhook サービス | kube-apiserver と ang-controller-manager |
バージョン 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 | インバウンド | 8444 | GKE Identity Service コアコンテナは hostPort を介してポートにバインドされます（バージョン 1.28 のみに適用） |
すべて |
| 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.29
| プロトコル | 方向 | ポート範囲 | 目的 | 使用者 |
|---|---|---|---|---|
| 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.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 | インバウンド | 9100 | 指標を提供 | node-exporter |
| TCP | インバウンド | 10250 | kubelet API |
セルフとコントロール プレーン |
| TCP | インバウンド | 10256 | ノードのヘルスチェック | すべて |
| TCP | インバウンド | 30000～32767 | NodePort サービス |
セルフ |
ロードバランサ ノード
バージョン 1.29
| プロトコル | 方向 | ポート範囲 | 目的 | 使用者 |
|---|---|---|---|---|
| TCP | インバウンド | 22 | ユーザー クラスタ ノードのプロビジョニングと更新 | 管理クラスタノード |
| TCP | インバウンド | 443 | クラスタ管理 このポートは、クラスタ構成ファイルで |
すべて |
| TCP | 両方 | 4240 | CNI ヘルスチェック | すべて |
| UDP | インバウンド | 6081 | GENEVE カプセル化 | セルフ |
| TCP と UDP | インバウンド | 7946 | MetalLB ヘルスチェック | ロードバランサ ノード |
| TCP | インバウンド | 10256 | ノードのヘルスチェック | すべて |
| TCP | インバウンド | 11000 | HAProxy 指標のリッスン ポート（不変） （バージョン 1.29 以降に適用） |
すべて |
| TCP | インバウンド | 11001 | GKE Identity Service のリッスン ポート（不変） （バージョン 1.29 以降に適用） |
すべて |
バージョン 1.28
| プロトコル | 方向 | ポート範囲 | 目的 | 使用者 |
|---|---|---|---|---|
| TCP | インバウンド | 22 | ユーザー クラスタ ノードのプロビジョニングと更新 | 管理クラスタノード |
| TCP | インバウンド | 443 | クラスタ管理 このポートは、クラスタ構成ファイルで |
すべて |
| TCP | 両方 | 4240 | CNI ヘルスチェック | すべて |
| UDP | インバウンド | 6081 | GENEVE カプセル化 | セルフ |
| TCP と UDP | インバウンド | 7946 | MetalLB ヘルスチェック | ロードバランサ ノード |
| TCP | インバウンド | 8443 | GKE Identity Service のリッスン ポート（不変） （バージョン 1.28 のみに適用） |
すべて |
| 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=10256/tcp
firewall-cmd --permanent --zone=public --add-port=10257/tcp
firewall-cmd --permanent --zone=public --add-port=10259/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 です。
RHEL 9.2 と 9.4 の補足構成
Red Hat Enterprise Linux（RHEL）バージョン 9.2 と 9.4 は、バージョン 1.29.400 以降で一般提供としてサポートされます。RHEL バージョン 9.2 と 9.4 では、Service と Pod が正しく機能するように、ノードで追加の firewalld 構成を行う必要があります。
ノードのアクティブなインターフェースを一覧表示して、メインノードのインターフェースを見つけます。
firewall-cmd --list-interfacesLinux マシン インターフェースの命名規則に基づいて、メイン インターフェース名は
eth0、eno1、ens1、enp2s0のいずれかのようになります。ノードのゾーンを一覧表示して、メイン インターフェースが使用するゾーンを確認します。
firewall-cmd --list-all-zonesたとえば、メイン インターフェースが
eno1の場合、レスポンスの次のセクションで、メイン インターフェースがpublicゾーンにあることが示されます。... public (active) target: default icmp-block-inversion: no interfaces: eno1 sources: ...次の firewalld コマンドを実行して、RHEL 9.2 または 9.4 のカスタムゾーンとポリシーの詳細を設定します。
firewall-cmd --permanent --new-zone=cilium firewall-cmd --permanent --zone=cilium --add-interface=cilium_host firewall-cmd --permanent --zone=cilium --set-target ACCEPT firewall-cmd --permanent --zone=cilium --add-masquerade firewall-cmd --permanent --zone=cilium --add-forward firewall-cmd --permanent --new-policy cilium-host-port-forwarding firewall-cmd --permanent --policy cilium-host-port-forwarding --add-ingress-zone IN_ZONE firewall-cmd --permanent --policy cilium-host-port-forwarding --add-egress-zone cilium firewall-cmd --permanent --policy cilium-host-port-forwarding --set-target ACCEPT firewall-cmd --reload前の手順で確認した内容に基づいて、
IN_ZONEを次のいずれかの値に置き換えます。public: 選択した受信接続のみが許可される、公共エリアで使用するための事前定義されたゾーン。trusted: すべてのネットワーク接続が許可される、制御された環境内の事前定義されたゾーン。- 定義したカスタムゾーンの名前。
ベンダーのドキュメントに沿って、ストレージ ソリューションを構成します。
たとえば、Portworx を使用してステートフル ワークロードを管理している場合、Portworx network requirements に、開いたままにする必要があるポートが記載されています。
ベンダーのドキュメントに記載されているポートごとに、次のコマンドを実行します。
firewall-cmd --permanent --zone=public --add-port=PORT_INFOPORT_INFOは、ポート番号またはポート番号の範囲と、プロトコルに置き換えます。たとえば、10250-10252/tcpです。
ポート構成を確認する
ポート構成を確認するには、コントロール プレーン ノード、ワーカーノード、ロードバランサ ノードで次の操作を行います。
次の Network Mapper コマンドを実行して、開いているポートを確認します。
nmap localhost次のコマンドを実行して、firewalld 構成設定を取得します。
firewall-cmd --info-zone=public firewall-cmd --info-zone=k8s-pods firewall-cmd --list-all-policies必要に応じて、前のセクションのコマンドを再実行してノードを適切に構成します。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 を再起動します。
次のコマンドを使用して
anetdPod を見つけて削除して、anetdを再起動します。kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZANETD_XYZ は、
anetdPod の名前で置き換えます。