IP アドレスを計画する（kubeception）

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

kubeception とは

kubeception という用語は、Kubernetes クラスタを使用して他の Kubernetes クラスタを作成および管理するというコンセプトを表すために使用されます。Google Distributed Cloud のコンテキストでは、kubeception はユーザー クラスタのコントロール プレーンが管理クラスタ内の 1 つ以上のノードで実行される場合を指します。

Google では kubeception の使用を推奨していません。代わりに、Controlplane V2 を使用することをおすすめします。Controlplane V2 では、ユーザー クラスタのコントロール プレーン ノードはユーザー クラスタ自体にあります。

始める前に

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

IP アドレス割り振りの例

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

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

  • 管理クラスタ。

  • 5 つのワーカーノードを持つ 1 つの高可用性（HA）ユーザー クラスタ

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

管理クラスタノード

管理クラスタには次の 7 つのノードがあります。

  • 管理クラスタのコントロール プレーンを実行する 1 つのノード
  • 管理クラスタのアドオンを実行する 2 つのノード
  • HA ユーザー クラスタのコントロール プレーンを実行する 3 つのノード
  • 非 HA ユーザー クラスタのコントロール プレーンを実行する 1 つのノード

ロード バランシング

この例では、クラスタが 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 アドレスの例: 管理クラスタノード

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

管理クラスタ内のノードの IP アドレス
172.16.20.2～172.16.20.9

IP アドレスの例: 管理クラスタ サブネット内の VIP

次の表では、管理クラスタのロードバランサに構成される VIP の指定例を示します。ユーザー クラスタにある Kubernetes API サーバーの VIP は、管理クラスタ サブネット上にあります。この例では、ユーザー クラスタの Kubernetes API サーバーは管理クラスタ内のノードで実行されるためです。なお、クラスタ構成ファイルで Kubernetes API サーバーの VIP を指定するフィールドは、controlPlaneVIP と呼ばれます。

VIP IP アドレス
管理クラスタの Kubernetes API サーバーの VIP172.16.20.30
管理クラスタ アドオン VIP 172.16.20.31
ユーザー クラスタ 1 の Kubernetes API サーバーの VIP 172.16.20.32
ユーザー クラスタ 2 の Kubernetes API サーバーの VIP 172.16.20.33

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

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

ユーザー クラスタ 1 のノードの IP アドレス
172.16.21.2～172.16.21.7

IP アドレスの例: ユーザー クラスタ 1 サブネットの VIP

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

VIP 説明 IP アドレス
ユーザー クラスタ 1 の Ingress VIP ユーザー クラスタ 1 のロードバランサで構成 172.16.21.30
ユーザー クラスタ 1 の Service VIP LoadBalancer タイプの Service 用の 10 個のアドレス。
必要に応じてユーザー クラスタ 1 のロードバランサで構成。
この範囲には Ingress VIP が含まれます。
これは MetalLB ロードバランサの要件です。		 172.16.21.30～172.16.21.39

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

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

ユーザー クラスタ 2 のノードの IP アドレス
172.16.22.2～172.16.22.6

IP アドレスの例: ユーザー クラスタ 2 サブネットの VIP

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

VIP 説明 IP アドレス
ユーザー クラスタ 2 の Ingress VIP ユーザー クラスタ 2 のロードバランサで構成 172.16.22.30
ユーザー クラスタ 2 の Service VIP LoadBalancer タイプの Service 用の 10 個のアドレス。
必要に応じてユーザー クラスタ 2 のロードバランサで構成。
この範囲には Ingress VIP が含まれます。
これは MetalLB ロードバランサの要件です。		 172.16.22.30～172.16.22.39

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 アドレスを管理する