ネットワークの要件

このドキュメントでは、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: bundledspec.loadBalancer.type: layer2)使用する場合、ロードバランサ ノードにはレイヤ 2 の隣接が必要です。レイヤ 2 の隣接要件は、ロードバランサをコントロール プレーン ノードで実行するか、専用のロード バランシング ノードのセットで実行するかに関係なく適用されます。BGP でバンドルされたロード バランシングはレイヤ 3 プロトコルをサポートしているため、厳格なレイヤ 2 の隣接は必要ありません。

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

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

Pod ネットワーク

GKE on Bare Metal 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 の値を減らします。 この方法にはいくつかのデメリットがあります。

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

次の図は、可能性のあるネットワーク構成における GDCV for Bare Metal の主要なネットワーキングのいくつかのコンセプトを示しています。

GKE on Bare Metal の一般的なネットワーク構成

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

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

ポートの使用状況

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

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

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

ワーカーノード

プロトコル送信 / 受信ポート範囲目的使用者
TCP受信22ユーザー クラスタ ノードのプロビジョニングと更新管理クラスタノード
UDP受信6081GENEVE カプセル化自身
TCP受信10250kubelet個のAPIセルフプレーンとコントロール プレーン
TCP受信10256ノードのヘルスチェックすべて
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 フィールドを使用して構成できます。

ファイアウォール ポートを構成する

Red Hat Enterprise Linux(RHEL)または CentOS で 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 です。

ポート構成を確認する

ポート構成を確認するには、コントロール プレーン ノード、ワーカーノード、ロードバランサ ノードで次の手順を行います。

  1. 次の Network Mapper コマンドを実行して、開いているポートを確認します。

    nmap localhost
    
  2. 次のコマンドを実行して、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
    
  3. 必要に応じて、前のセクションのコマンドを再実行してノードを適切に構成します。root ユーザーとしてコマンドを実行することが必要な場合があります。

firewalld の既知の問題

CentOS または 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 を再起動します。

  1. anetd は、次のコマンドを使用して anetd Pod を見つけて削除することで再起動します。

    kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZ
    

    ANETD_XYZ は、anetd Pod の名前で置き換えます。