ネットワークの要件

このドキュメントでは、ベアメタルに Google Distributed Cloud（ソフトウェアのみ）をインストールして運用するためのネットワーク要件について説明します。

このページは、基盤となる技術インフラストラクチャのライフサイクルを管理し、組織のネットワークを設計する管理者、アーキテクト、オペレーター、ネットワーク スペシャリストを対象としています。Google Cloud のコンテンツで参照する一般的なロールとタスク例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。

外部ネットワークの要件

Google Distributed Cloud の操作にはインターネット接続が必要です。Google Distributed Cloud は Artifact Registry からクラスタ コンポーネントを取得し、クラスタは Connect Agent に登録されます。

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 と 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 アドレスを使用します。クラスタ構成ファイルには、次の表に示す制限内に収まる値が事前入力されています。

ネットワークで到達可能な 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、クラスタあたりのノードの推奨最大数については、上限をご覧ください。

ノードあたりの最大 Pod 数

ベアメタルでは、Google Distributed Cloud でノードあたり最大 250 個の Pod を構成できます。Kubernetes は、各 Pod に一意の IP アドレスを割り当てることができるように、CIDR ブロックを各ノードに割り当てます。CIDR ブロックのサイズは、ノードあたりの最大 Pod 数に対応します。

ノードあたりの構成済み最大 Pod 数に基づいて、Kubernetes が各ノードに割り当てる CIDR ブロックのサイズを次の表に示します。

ノードあたり 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 も定義されます。
  • Service
  • Ingress
  • Kubernetes API を介したコントロール プレーンのアクセス
• Google Cloudへの接続が必要です。

ポートの使用状況

このセクションでは、Google Distributed Cloud クラスタのポート要件について説明します。次の表は、クラスタノードとロードバランサ ノード上の Kubernetes コンポーネントで UDP ポートと TCP ポートがどのように使用されるかを示しています。

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

ワーカーノード

ロードバランサ ノード

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

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

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

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 構成を行う必要があります。

1. ノードのアクティブなインターフェースを一覧表示して、メインノードのインターフェースを見つけます。

   firewall-cmd --list-interfaces
   

   Linux マシン インターフェースの命名規則に基づいて、メイン インターフェース名は eth0、eno1、ens1、enp2s0 のいずれかのようになります。

2. ノードのゾーンを一覧表示して、メイン インターフェースが使用するゾーンを確認します。

   firewall-cmd --list-all-zones
   

   たとえば、メイン インターフェースが eno1 の場合、レスポンスの次のセクションで、メイン インターフェースが public ゾーンにあることが示されます。

   ...
   public (active)
     target: default
     icmp-block-inversion: no
     interfaces: eno1
     sources:
     ...
   

3. 次の 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: すべてのネットワーク接続が許可される、制御された環境内の事前定義されたゾーン。
   • 定義したカスタムゾーンの名前。

4. ベンダーのドキュメントに沿って、ストレージ ソリューションを構成します。

   たとえば、Portworx を使用してステートフル ワークロードを管理している場合、Portworx network requirements に、開いたままにする必要があるポートが記載されています。

   ベンダーのドキュメントに記載されているポートごとに、次のコマンドを実行します。

   firewall-cmd --permanent --zone=public --add-port=PORT_INFO
   

   PORT_INFO は、ポート番号またはポート番号の範囲と、プロトコルに置き換えます。たとえば、10250-10252/tcp です。

ポート構成を確認する

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

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

   nmap localhost
   

2. 次のコマンドを実行して、firewalld 構成設定を取得します。

   firewall-cmd --info-zone=public
   firewall-cmd --info-zone=k8s-pods
   firewall-cmd --list-all-policies
   

3. 必要に応じて、前のセクションのコマンドを再実行してノードを適切に構成します。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 を再起動します。

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

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

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