ネットワークの要件

ネットワークの要件

外部ネットワークの要件

ベアメタル版 Anthos クラスタの操作にはインターネット接続が必要です。ベアメタル版 Anthos クラスタは、Container Registry からクラスタ コンポーネントを取得し、クラスタは Connect に登録されます。

HTTPS、バーチャル プライベート ネットワーク(VPN)、または Dedicated Interconnect 接続を介して公共のインターネットを使用し、Google に接続できます。

内部ネットワークの要件

ベアメタル版 Anthos クラスタは、クラスタノード間のレイヤ 2 またはレイヤ 3 接続で機能しますが、ロードバランサ ノードの場合はレイヤ 2 接続が必要です。ロードバランサ ノードは、コントロール プレーン ノードまたは専用ノードのセットです。詳細については、ロードバランサの選択と構成をご覧ください。

レイヤ 2 接続の要件は、ロードバランサをコントロール プレーン ノードプールで実行するか、専用のノードセットで実行するかに関係なく適用されます。

ロードバランサ マシンの要件は次のとおりです。

  • 指定されたクラスタのすべてのロードバランサが、同じレイヤ 2 ドメインにある。
  • すべての仮想 IP アドレス(VIP)がロードバランサ マシンのサブネット内にあり、サブネットのゲートウェイにルーティング可能である。
  • 上り(内向き)ロードバランサのトラフィックを許可することは、ユーザーの責任で行います。

ポッド ネットワーク

ベアメタル版 Anthos クラスタ 1.7.0 以降のバージョンでは、ノードあたり最大 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 の値を減らします。

高可用性を備えた単一ユーザー クラスタのデプロイメント

次の図は、ある 1 つのネットワーク構成におけるベアメタル版 Anthos クラスタの主要なネットワーキング コンセプトを示しています。

ベアメタル版 Anthos クラスタの一般的なネットワーク構成

ネットワーク要件を満たすために、次のことを検討してください。

  • コントロール プレーン ノードがロードバランサを実行し、それらはすべてレイヤ 2 接続を有する一方で、ワーカーノードなどの他の接続ではレイヤ 3 接続のみが必要です。
  • 構成ファイルでは、ワーカー ノードプールの IP アドレスが定義される。構成ファイルでは、次の目的のために VIP も定義される。
    • サービス
    • Ingress
    • Kubernetes API を介したコントロール プレーンのアクセス
  • Google Cloud への接続が必要。

ポートの使用状況

このセクションでは、クラスタノードとロードバランサ ノードで UDP ポートと TCP ポートを使用する方法について説明します。

コントロール プレーン ノード

プロトコル送信 / 受信ポート範囲目的使用者
UDP受信6081GENEVE カプセル化自身
TCP受信22管理クラスタ ノードのプロビジョニングと更新管理ワークステーション
TCP受信6444Kubernetes API サーバーすべて
TCP受信2379 - 2380etcd サーバー クライアント APIkube-apiserveretcd
TCP受信10250kubelet個のAPIセルフプレーンとコントロール プレーン
TCP受信10251kube-scheduler自身
TCP受信10252kube-controller-manager自身
TCP受信10256ノードのヘルスチェックAll
TCP両方4240CNI ヘルスチェックすべて

ワーカーノード

プロトコル送信 / 受信ポート範囲目的使用者
TCP受信22ユーザー クラスタ ノードのプロビジョニングと更新管理クラスタノード
UDP受信6081GENEVE カプセル化自身
TCP受信10250kubelet個のAPIセルフプレーンとコントロール プレーン
TCP受信10256ノードのヘルスチェックAll
TCP受信30000~32767NodePort 個のサービス自身
TCP両方4240CNI ヘルスチェックすべて

ロードバランサ ノード

プロトコル送信 / 受信ポート範囲目的使用者
TCP受信22ユーザー クラスタ ノードのプロビジョニングと更新管理クラスタノード
UDP受信6081GENEVE カプセル化自身
TCP受信443*クラスタ管理すべて
TCP両方4240CNI ヘルスチェックすべて
TCP受信7946Metal LB ヘルスチェックロードバランサ ノード
UDP受信7946Metal LB ヘルスチェックロードバランサ ノード
TCP受信10256ノードのヘルスチェックAll

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

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

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

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

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

firewalld ポートの構成

Red Hat Enterprise Linux(RHEL)または CentOS でベアメタル版 Anthos クラスタを実行するために、firewalld を無効にする必要はありません。firewalld を使用するには、このページのポートの使用状況に記載されているように、コントロール プレーン ノード、ワーカー ノード、ロードバランサ ノードが使用する UDP ポートと TCP ポートを開く必要があります。次の構成例では、firewall-cmd(firewalld コマンドライン ユーティリティ)を使用してポートを開く方法を示します。

コントロール プレーン ノードの構成例

次のコマンド ブロックでは、コントロール プレーン ノードを実行しているサーバーで必要なポートを開く方法を示します。

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