ネットワークの要件
外部ネットワークの要件
ベアメタル版 Anthos クラスタの操作にはインターネット接続が必要です。ベアメタル版 Anthos クラスタは、Container Registry からクラスタ コンポーネントを取得し、クラスタは Connect に登録されます。
公共のインターネット（HTTPS 経由）、バーチャル プライベート ネットワーク（VPN）、または Dedicated Interconnect を介して Google に接続できます。
内部ネットワークの要件
ベアメタル版 Anthos クラスタは、クラスタノード間のレイヤ 2 またはレイヤ 3 接続で動作できます。ロードバランサ ノードは同じレイヤ 2 ドメイン内にある必要があります。ロードバランサ ノードは、コントロール プレーン ノードまたは専用ノードのセットです。構成情報については、ロードバランサの選択と構成をご覧ください。
レイヤ 2 ネットワーク要件は、コントロール プレーン ノードプールで、または専用ノードのセットのどちらでロードバランサを実行しても適用されます。
ロードバランサ マシンの要件は次のとおりです。
- 指定されたクラスタのすべてのロードバランサが、同じレイヤ 2 ドメインにある。
- すべての VIP は、ロードバランサ マシンのサブネットにあり、サブネットのゲートウェイにルーティング可能である必要がある。
- 上り（内向き）ロードバランサのトラフィックを許可することは、ユーザーの責任で行います。
ポッド ネットワーク
ベアメタル版 Anthos クラスタ 1.7.0 以降のバージョンでは、ノードあたり最大 250 個の Pod を構成できます。Kubernetes は、各ノードに一意の 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 の値を減らします。
高可用性を備えた単一ユーザー クラスタのデプロイメント
次の図は、ある 1 つのネットワーク構成におけるベアメタル版 Anthos クラスタの主要なネットワーキング コンセプトを示しています。
- コントロール プレーン ノードはロードバランサを実行し、すべて同じレイヤ 2 ネットワーク上に存在します。一方、ワーカーノードを含むその他の接続には、レイヤ 3 接続のみが必要です。
- 構成ファイルでは、ワーカー ノードプールの IP アドレスが定義される。構成ファイルでは、次の目的のために VIP も定義される。
- サービス
- Ingress
- Kubernetes API を介したコントロール プレーンのアクセス
- Google Cloud への接続も必要です。
ポートの使用状況
このセクションでは、クラスタノードとロードバランサ ノードで UDP ポートと TCP ポートを使用する方法について説明します。
マスターノード
| プロトコル | 送信 / 受信 | ポート範囲 | 目的 | 使用者 |
|---|---|---|---|---|
| UDP | 受信 | 6081 | GENEVE カプセル化 | 自身 |
| TCP | 受信 | 22 | 管理クラスタ ノードのプロビジョニングと更新 | 管理ワークステーション |
| TCP | 受信 | 6444 | Kubernetes API サーバー | すべて |
| TCP | 受信 | 2379 - 2380 | etcd サーバー クライアント API | kube-apiserver, etcd |
| TCP | 受信 | 10250 | kubelet API | 自身、コントロール プレーン |
| TCP | 受信 | 10251 | kube-scheduler | 自身 |
| TCP | 受信 | 10252 | kube-controller-manager | 自身 |
| TCP | 両方 | 4240 | CNI ヘルスチェック | すべて |
ワーカーノード
| プロトコル | 送信 / 受信 | ポート範囲 | 目的 | 使用者 |
|---|---|---|---|---|
| TCP | 受信 | 22 | ユーザー クラスタ ノードのプロビジョニングと更新 | 管理クラスタノード |
| UDP | 受信 | 6081 | GENEVE カプセル化 | 自身 |
| TCP | 受信 | 10250 | kubelet API | 自身、コントロール プレーン |
| TCP | 受信 | 30000～32767 | NodePort Service | 自身 |
| TCP | 両方 | 4240 | CNI ヘルスチェック | すべて |
ロードバランサ ノード
| プロトコル | 送信 / 受信 | ポート範囲 | 目的 | 使用者 |
|---|---|---|---|---|
| TCP | 受信 | 22 | ユーザー クラスタ ノードのプロビジョニングと更新 | 管理クラスタノード |
| UDP | 受信 | 6081 | GENEVE カプセル化 | 自身 |
| TCP | 受信 | 443* | クラスタ管理 | すべて |
| TCP | 両方 | 4240 | CNI ヘルスチェック | すべて |
| TCP | 受信 | 7946 | Metal LB ヘルスチェック | LB ノード |
| UDP | 受信 | 7946 | Metal LB ヘルスチェック | LB ノード |
* このポートは、クラスタ構成ファイルで controlPlaneLBPort フィールドを使用して構成できます。
マルチクラスタ ポートの要件
マルチクラスタ構成では、追加クラスタが管理クラスタと通信するため、次のポートを含める必要があります。
| プロトコル | 送信 / 受信 | ポート範囲 | 目的 | 使用者 |
|---|---|---|---|---|
| TCP | 受信 | 22 | クラスタノードのプロビジョニングと更新 | すべてのノード |
| TCP | 受信 | 443* | 追加クラスタ用の Kubernetes API サーバー | コントロール プレーン、LB ノード |
* このポートは、クラスタ構成ファイルで controlPlaneLBPort フィールドを使用して構成できます。
firewalld ポートの構成
ベアメタル版 Anthos クラスタ 1.7.0 より、Red Hat Enterprise Linux（RHEL）または CentOS でベアメタル版 Anthos クラスタを実行するために firewalld を無効にする必要はありません。firewalld を使用するには、このページのポートの使用状況で説明されているように、マスター、ワーカー、ロードバランサのノードが使用する UDP ポートと TCP ポートを開く必要があります。次の構成例では、firewalld コマンドライン クライアントの firewall-cmd を使用してポートを開く方法を示しています。
マスターノードの構成例
次のコマンド ブロックの例は、マスターノードを実行するサーバーで必要なポートを開く方法を示しています。
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=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=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=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 --reloadfirewall-cmd --reload
PODS_CIDR を、ポッド clusterNetwork.pods.cidrBlocks 用に予約された CIDR ブロックに置き換えます。Pod 用のデフォルトの CIDR ブロックは 192.168.0.0/16 です。