このドキュメントでは、ベアメタルに Google Distributed Cloud（ソフトウェアのみ）をインストールして運用するためのネットワーク要件について説明します。
このページは、基盤となる技術インフラストラクチャのライフサイクルを管理し、組織のネットワークを設計する管理者、アーキテクト、オペレーター、ネットワーク スペシャリストを対象としています。Google Cloud のコンテンツで参照する一般的なロールとタスク例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。
外部ネットワークの要件
Google Distributed Cloud の操作にはインターネット接続が必要です。Google Distributed Cloud は Container Registry からクラスタ コンポーネントを取得し、クラスタは Connect Agent に登録されます。
HTTPS、バーチャル プライベート ネットワーク（VPN）、または Dedicated Interconnect 接続を介して公共のインターネットを使用し、Google に接続できます。
管理ワークステーションとクラスタノードに使用しているマシンがプロキシ サーバーを使用してインターネットにアクセスする場合、プロキシ サーバーで特定の接続を許可する必要があります。詳細については、プロキシの背後でインストールするの前提条件のセクションをご覧ください。
内部ネットワークの要件
Google Distributed Cloud は、クラスタノード間のレイヤ 2 またはレイヤ 3 接続で動作します。ロードバランサ ノードは、コントロール プレーン ノードまたは専用ノードのセットです。詳細については、ロードバランサの選択と構成をご覧ください。
バンドルされたレイヤ 2 ロード バランシングを MetalLB とともに（spec.loadBalancer.mode: bundled と spec.loadBalancer.type: layer2）使用する場合、ロードバランサ ノードにはレイヤ 2 の隣接が必要です。レイヤ 2 の隣接要件は、ロードバランサをコントロール プレーン ノードで実行するか、専用のロード バランシング ノードのセットで実行するかに関係なく適用されます。BGP でバンドルされたロード バランシングはレイヤ 3 プロトコルをサポートしているため、厳格なレイヤ 2 の隣接は必要ありません。
ロードバランサ マシンの要件は次のとおりです。
- バンドルされたレイヤ 2 ロード バランシングの場合、特定のクラスタのすべてのロードバランサは、同じレイヤ 2 ドメインにあります。コントロール プレーン ノードも同じレイヤ 2 ドメインに存在する必要があります。
- バンドルされたレイヤ 2 ロード バランシングの場合、すべての仮想 IP アドレス（VIP）がロードバランサ マシンのサブネット内にあり、サブネットのゲートウェイにルーティング可能である必要があります。
- 上り（内向き）ロードバランサのトラフィックを許可することは、ユーザーの責任で行います。
Pod と Service のネットワーキング
Service と Pod で使用できる IP アドレスの範囲は、クラスタ構成ファイルで指定します。以降のセクションでは、アドレス範囲の最小制約と最大制約、クラスタのインストールを計画する際に考慮する必要がある関連する要素について説明します。
クラスタに配置できる Pod と Service の数は、次の設定によって制御されます。
clusterNetwork.pods.cidrBlocksは、クラスタで許可される Pod の数を指定します。clusterNetwork.services.cidrBlocksは、クラスタで許可される Service の数を指定します。nodeConfig.podDensity.maxPodsPerNodeは、単一ノードで実行できる Pod の最大数を指定します。
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: admin-basic
namespace: cluster-admin-basic
spec:
type: admin
profile: default
...
clusterNetwork:
pods:
cidrBlocks:
- 192.168.0.0/16
services:
cidrBlocks:
- 10.96.0.0/20
...
nodeConfig:
podDensity:
maxPodsPerNode: 250
Pod と Service の IP アドレス範囲
Pod に使用する クラスレス ドメイン間ルーティング（CIDR）ブロックとして IP アドレスの範囲を指定し、Kubernetes Services の ClusterIP アドレスに使用する別の CIDR ブロックを指定します。RFC 1918 で説明されているように、プライベート アドレス空間内の IP アドレスを使用します。クラスタ構成ファイルには、次の表に示す上限内に収まる値が事前入力されています。
| 上限 | Pod | サービス |
|---|---|---|
| 最小範囲 | /18 のマスク値（16,384 アドレス） |
/24 のマスク値（256 アドレス） |
| 事前入力された範囲 | /16 のマスク値（65,536 アドレス） |
マスク値 /20（4,096 アドレス） |
| 最大範囲 | /8 のマスク値（16,777,216 アドレス） |
/12 のマスク値（1,048,576 個のアドレス） |
ネットワークで到達可能な IP アドレスと重複しないように、事前入力された値とは異なる CIDR 範囲の使用が必要になる場合があります。特に、Service と Pod の範囲が次の対象と重複しないようにする必要があります。
任意のクラスタ内に存在するノードの IP アドレス
コントロール プレーン ノードとロードバランサで使用される VIP
DNS サーバーまたは NTP サーバーの IP アドレス
重複する IP アドレスが検出されると、プリフライト チェックによってクラスタの作成とアップグレードがブロックされます。
クラスタの作成後に Service ネットワーク範囲を増やす（clusterNetwork.services.cidrBlocks）ことはできますが、割り振られた IP アドレスの数を減らしたり変更したりすることはできません。変更できるのは CIDR ブロックの接尾辞のみで、マスク値を減らして IP アドレスの数を増やすことができます。
clusterNetwork.pods.cidrBlocks と nodeConfig.podDensity.maxPodsPerNode（次のセクションで説明）はどちらも不変であるため、ノード容量が不足しないように、クラスタの将来の成長について慎重に計画してください。テストに基づくクラスタあたりの Pod、ノードあたりの Pod、クラスタあたりのノードの推奨最大数については、上限をご覧ください。
ノードあたりの最大ポッド数
ベアメタルでは、Google Distributed Cloud でノードあたり最大 250 個の Pod を構成できます。Kubernetes は、各 Pod に一意の IP アドレスを割り当てることができるように、CIDR ブロックを各ノードに割り当てます。Pod の CIDR ブロックのサイズは、ノードあたりの最大 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 を、事前入力された値よりもはるかに大きい Pod CIDR ブロックに設定することを強くおすすめします。
Pod と Service の数などの要因がクラスタのスケーラビリティに与える影響の詳細については、Google Distributed Cloud クラスタをスケールアップするをご覧ください。
高可用性を備えた単一ユーザー クラスタのデプロイメント
次の図は、一般的なネットワーク構成における Google Distributed Cloud の主要なネットワーキングのコンセプトを示しています。
ネットワーク要件を満たすために、次のことを検討してください。
- コントロール プレーン ノードがロードバランサを実行し、それらはすべてレイヤ 2 接続を有する一方で、ワーカーノードなどの他の接続ではレイヤ 3 接続のみが必要です。
- 構成ファイルでは、ワーカー ノードプールの IP アドレスが定義される。構成ファイルでは、次の目的のために VIP も定義される。
- サービス
- 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-events サーバー クライアント 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 | 受信 | 11,000 個 | 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 フィールドで構成されているポッド用に予約された 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 です。
RHEL 9.2 と 9.4 の補足構成
Red Hat Enterprise Linux（RHEL）バージョン 9.2 と 9.4 は、バージョン 1.29.400 以降で一般提供としてサポートされています。RHEL バージョン 9.2 と 9.4 では、サービスと 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 --reloadIN_ZONEは、前の手順で確認した内容に基づいて、次のいずれかの値に置き換えます。public: 選択した受信接続のみが許可される公共エリアで使用するための事前定義されたゾーン。trusted: すべてのネットワーク接続が許可される制御された環境内の事前定義されたゾーン。- 定義したカスタムゾーンの名前。
ベンダーのドキュメントに沿って、ストレージ ソリューションを構成します。
たとえば、Portworx を使用してステートフル ワークロードを管理している場合、Portworx ネットワーク要件に、開いたままにする必要があるポートが一覧表示されます。
ベンダーのドキュメントに記載されているポートごとに、次のコマンドを実行します。
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 は、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 の名前で置き換えます。