IP アドレスを計画する

このドキュメントでは、Google Distributed Cloud のインストール用に IP アドレスを計画する方法について説明します。

始める前に

Google Distributed Cloud の概要とインストールの概要を確認してください。

IP アドレス割り振りの例

このセクションでは、次の要素を含むインストールで静的 IP アドレスを割り振る方法の例を示します。

  • 管理ワークステーション。

  • 高可用性（HA）管理クラスタ

  • 5 つのワーカーノードを持つ 1 つの HA ユーザー クラスタ

  • 4 つのワーカーノードを持つ 1 つの非 HA ユーザー クラスタ

この例では、ユーザー クラスタで Controlplane V2 が有効になっています。Controlplane V2 では、ユーザー クラスタのコントロール プレーン ノードはユーザー クラスタ自体にあります。

ユーザー クラスタに対して Controlplane V2 を有効にしない場合は、IP アドレスを計画する（kubeception）をご覧ください。kubeception という用語は、ユーザー クラスタのコントロール プレーンが管理クラスタ内の 1 つ以上のノードで実行される場合を指します。Google では kubeception の使用を推奨していません。Controlplane V2 を有効にすることをおすすめします。

管理クラスタノード

管理クラスタには 3 つのノードがあり、それぞれがコントロール プレーン コンポーネントを実行します。

ロード バランシング

この例では、クラスタが MetalLB ロードバランサを使用していると想定しています。このロードバランサはクラスタノード上で実行されるため、ロード バランシング用の追加の VM は必要ありません。

サブネット

この例では、各クラスタが独自の VLAN にあり、クラスタがこれらのサブネットにあると想定しています。

VM サブネット デフォルト ゲートウェイ
管理ワークステーションと管理クラスタ 172.16.20.0/24 172.16.20.1
ユーザー クラスタ 1 172.16.21.0/24 172.16.21.1
ユーザー クラスタ 2 172.16.22.0/24 172.16.22.1

次の図では、3 つの VLAN とサブネットを示します。VIP は、クラスタ内の特定のノードに関連付けられてはいません。これは、MetalLB のロードバランサが個々の Service の VIP を通知するノードを選択できるためです。たとえば、ユーザー クラスタ 1 では、1 つのワーカーノードが 172.16.21.31 をアナウンスし、別のワーカーノードが 172.16.21.32 をアナウンスできます。

管理クラスタと 2 つのユーザー クラスタの IP アドレス。
管理クラスタと 2 つのユーザー クラスタの IP アドレス（クリックして拡大）

IP アドレスの例: 管理ワークステーション

この例で、管理ワークステーションは、管理クラスタと同じサブネット（172.16.20.0/24）にあります。管理ワークステーションには、ノードアドレスに近いアドレスが適しています。例: 172.16.20.20。

IP アドレスの例: 管理クラスタノード

この例の管理クラスタには 3 つのノードがあるため、3 つの IP アドレスを設定する必要があります。たとえば、管理クラスタ内のノード用に次の IP アドレスを確保できます。

管理クラスタ IP アドレス
HA 管理クラスタ172.16.20.2 - 172.16.20.4

IP アドレスの例: 管理クラスタの VIP

管理クラスタの Kubernetes API サーバー用に VIP を確保する必要があります。クラスタ構成ファイルでは、この VIP のフィールドは controlPlaneVIP と呼ばれます。たとえば、管理クラスタの Kubernetes API サーバー用に次の VIP を確保できます。

VIP IP アドレス
管理クラスタの Kubernetes API サーバーの VIP172.16.20.30

HA 管理クラスタの場合、controlPlaneVIP は network.controlPlaneIPBlock で指定されたコントロール プレーン ノード IP と同じ VLAN に存在する必要があります。

IP アドレスの例: ユーザー クラスタ 1 ノード

8 つのノードがあるユーザー クラスタでは、9 つの IP アドレスを確保する必要があります。クラスタのアップグレード、更新、自動修復時に必要になるため追加のアドレスが必要です。たとえば、ユーザー クラスタ 1 のノード用に次の IP アドレスを確保できます。

ユーザー クラスタ 1 のノードの IP アドレス
172.16.21.2 - 172.16.21.10

IP アドレスの例: ユーザー クラスタ 1 の VIP

次の表に、ユーザー クラスタ 1 のロードバランサに構成する VIP を指定する方法に関する例を示します。

VIP 説明 IP アドレス
ユーザー クラスタ 1 の Kubernetes API サーバーの VIP ユーザー クラスタ 1 のロードバランサで構成 172.16.21.30
ユーザー クラスタ 1 の上り（内向き）VIP ユーザー クラスタ 1 のロードバランサで構成 172.16.21.31
ユーザー クラスタ 1 の Service VIP LoadBalancer タイプの Service 用の 10 個のアドレス。
必要に応じてユーザー クラスタ 1 のロードバランサで構成。
この範囲には Ingress VIP が含まれます。
これは MetalLB ロードバランサの要件です。		 172.16.21.31 - 172.16.21.40

Kubernetes API サーバーの VIP は、クラスタ構成ファイルの loadBalancer.vips.controlPlaneVIP で指定されます。ControlPlane V2 が有効になっている場合、controlPlaneVIP は network.controlPlaneIPBlock で指定されたコントロール プレーン ノードの IP と同じ VLAN に存在する必要があります。

IP アドレスの例: ユーザー クラスタ 2 ノード

5 つのノードがあるユーザー クラスタでは、6 つの IP アドレスを確保する必要があります。クラスタのアップグレード、更新、自動修復時に必要になるため追加のアドレスが必要です。たとえば、ユーザー クラスタ 2 のノード用に次の IP アドレスを確保できます。

ユーザー クラスタ 2 のノードの IP アドレス
172.16.22.2 - 172.16.22.7

IP アドレスの例: ユーザー クラスタ 2 の VIP

次の表に、ユーザー クラスタ 2 のロードバランサに構成する VIP を指定する方法に関する例を示します。

VIP 説明 IP アドレス
ユーザー クラスタ 2 の Kubernetes API サーバーの VIP ユーザー クラスタ 2 のロードバランサで構成 172.16.22.30
ユーザー クラスタ 2 の上り（内向き）VIP ユーザー クラスタ 2 のロードバランサで構成 172.16.22.31
ユーザー クラスタ 2 の Service VIP LoadBalancer タイプの Service 用の 10 個のアドレス。
必要に応じてユーザー クラスタ 2 のロードバランサで構成。
この範囲には Ingress VIP が含まれます。
これは MetalLB ロードバランサの要件です。		 172.16.22.31 - 172.16.22.40

Kubernetes API サーバーの VIP は、クラスタ構成ファイルの loadBalancer.vips.controlPlaneVIP で指定されます。ControlPlane V2 が有効になっている場合、controlPlaneVIP は network.controlPlaneIPBlock で指定されたコントロール プレーン ノードの IP と同じ VLAN に存在する必要があります。

IP アドレスの例: Pod とサービス

クラスタを作成する前に、Pod の IP アドレス用に CIDR 範囲を、また Kubernetes Services の ClusterIP アドレス用に別の CIDR 範囲を指定する必要があります。

Pod と Service に使用する CIDR 範囲を決定します。例:

目的CIDR 範囲
管理クラスタ内の Pod192.168.0.0/16
ユーザー クラスタ 1 内の Pod192.168.0.0/16
ユーザー クラスタ 2 内の Pod192.168.0.0/16
管理クラスタ内の Service10.96.232.0/24
ユーザー クラスタ 1 内の Service10.96.0.0/20
ユーザー クラスタ 2 内の Service10.96.128.0/20

上の例は、以下の点を示しています。

  • Pod CIDR 範囲は、複数のクラスタで同じにできます。

  • 通常、Service よりも多くの Pod が必要であるため、特定のクラスタでは Service CIDR 範囲よりも広い Pod CIDR 範囲が必要になる場合があります。ユーザー クラスタの Pod 範囲の例は、192.168.0.0/16 であり、2^(32-16) = 2^16 個のアドレスが存在します。ただし、ユーザー クラスタの Service 範囲の例は 10.96.0.0/20 であり、2^(32-20) = 2^12 個のアドレスのみが存在します。

重複を回避する

ネットワークで到達可能な IP アドレスと重複しないように、デフォルト以外の CIDR 範囲の使用が必要になる場合があります。Service と Pod の範囲は、クラスタ内から到達可能にする必要があるクラスタ外のアドレスと重複しないようにしてください。

たとえば、Service の範囲が 10.96.232.0/24、Pod の範囲が 192.168.0.0/16（192.168.0.1～192.168.255.254）であるとします。Pod からいずれかの範囲のアドレスに送信されたトラフィックは、クラスタ内トラフィックとして扱われ、クラスタ外の宛先に到達しません。

特に、Service と Pod の範囲が次の対象と重複しないようにする必要があります。

  • 任意のクラスタ内に存在するノードの IP アドレス

  • ロードバランサ マシンで使用される IP アドレス

  • コントロール プレーン ノードとロードバランサで使用される VIP

  • vCenter Server、DNS サーバー、NTP サーバーの IP アドレス

Service と Pod の範囲は RFC 1918 アドレス空間にすることをおすすめします。

RFC 1918 アドレスを使用することが推奨される理由の一つは次のとおりです。Pod または Service の範囲に外部 IP アドレスが含まれているとします。Pod からそれらの外部アドレスのいずれかに送信されたトラフィックは、クラスタ内トラフィックとして扱われ、外部の宛先に到達しません。

DNS サーバーとデフォルト ゲートウェイ

構成ファイルに入力する前に、管理ワークステーションとクラスタノードで使用できる DNS サーバーの IP アドレスを把握する必要があります。

また、各サブネットのデフォルト ゲートウェイの IP アドレスも把握している必要があります。上記の例では、各サブネットのデフォルト ゲートウェイが範囲内にある最初のアドレスになります。たとえば、管理クラスタのサブネットにあるデフォルト ゲートウェイは、172.16.20.1 と示されます。

詳細

ノード IP アドレスを管理する