このドキュメントでは、高可用性（HA）管理クラスタと 2 つの HA ユーザー クラスタに IP アドレスを割り振る方法の例を示します。
準備
管理クラスタ、ユーザー クラスタ、高可用性については、デプロイモデルの選択をご覧ください。
IP アドレス割り当ての例
このセクションでは、次の要素を含むインストールで IP アドレスを割り振る方法の例を示します。
クラスタノードの IP アドレス
Pod の IP アドレス
Service のクラスタ IP アドレス
コントロール プレーンと Ingress プロキシの仮想 IP アドレス（VIP）
Service の外部 IP アドレスとして使用する VIP
管理クラスタノード
この例の管理クラスタには 3 つのノードがあります。各ノードでは、コントロール プレーン コンポーネントが実行されます。
ユーザー クラスタノード
この例では、各ユーザー クラスタに 6 つのノード（3 つのコントロール プレーン ノードと 3 つのワーカーノード）があります。
ロード バランシング
この例では、クラスタがバンドル型 MetalLB ロードバランサを使用していると想定しています。ロードバランサはクラスタノード上で実行されるため、ロード バランシング用の追加のマシンは必要ありません。
サブネット
この例では、各クラスタが独自のレイヤ 2 ドメインにあり、クラスタが次のサブネットにあると想定しています。
| クラスタ | サブネット | デフォルト ゲートウェイ |
|---|---|---|
| 管理クラスタ | 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 つのサブネットを示しています。VIP は、クラスタ内の特定のノードに関連付けられてはいません。これは、MetalLB のロードバランサが個々の Service の VIP を通知するノードを選択できるためです。たとえば、ユーザー クラスタ 1 では、1 つのノードが 172.16.21.52 をアナウンスし、異なるノードが 172.16.21.53 をアナウンスできます。
IP アドレスの例: 管理クラスタノード
管理クラスタノード用に 3 つの IP アドレスが必要で、これらのすべてがコントロール プレーン コンポーネントを実行します。たとえば、管理クラスタ内のノードには、次の IP アドレスを使用できます。この例のアドレスは連続していますが、それは要件ではありません。
| 管理クラスタ内のノードの IP アドレス |
|---|
| 172.16.20.2 - 172.16.20.4 |
IP アドレスの例: 管理クラスタのコントロール プレーン VIP
管理クラスタの Kubernetes API サーバー用に VIP を確保する必要があります。クラスタの構成ファイルでは、これを controlPlaneVIP とします。たとえば、管理クラスタのコントロール プレーン VIP として使用する次の IP アドレスを確保できます。
| 管理クラスタのコントロール プレーン VIP |
|---|
| 172.16.20.50 |
IP アドレスの例: ユーザー クラスタ 1 ノード
例: ユーザー クラスタ 1 の 3 つのコントロール プレーン ノードと 3 つのワーカーノードには、次の IP アドレスを使用できます。この例のアドレスは連続していますが、それは要件ではありません。
| ユーザー クラスタ 1 のノードの IP アドレス |
|---|
| 172.16.21.2 - 172.16.21.7 |
IP アドレスの例: ユーザー クラスタ 1 の VIP
次の表に、ユーザー クラスタ 1 のロードバランサに構成する VIP を指定する方法に関する例を示します。この例の VIP は連続していますが、それは要件ではありません。
| VIP | Description | IP アドレス |
|---|---|---|
| ユーザー クラスタ 1 のコントロール プレーン VIP | ユーザー クラスタ 1 のロードバランサで構成 | 172.16.21.50 |
| ユーザー クラスタ 1 の上り（内向き）VIP | ユーザー クラスタ 1 のロードバランサで構成 | 172.16.21.51 |
| ユーザー クラスタ 1 の Service VIP | LoadBalancer タイプの Service 用の 10 個のアドレス。必要に応じてユーザー クラスタ 1 のロードバランサで構成。 この範囲には上り（内向き）VIP が含まれます。 これは MetalLB バランサの要件です。 |
172.16.21.51 - 172.16.21.60 |
IP アドレスの例: ユーザー クラスタ 2 ノード
例: ユーザー クラスタ 2 のノードには、次の IP アドレスを使用できます。この例のアドレスは連続していますが、それは要件ではありません。
| ユーザー クラスタ 2 のノードの IP アドレス |
|---|
| 172.16.22.2 - 172.16.22.7 |
IP アドレスの例: ユーザー クラスタ 2 の VIP
次の表に、ユーザー クラスタ 2 のロードバランサに構成する VIP を指定する方法に関する例を示します。この例の VIP は連続していますが、それは必須ではありません。
| VIP | Description | IP アドレス |
|---|---|---|
| ユーザー クラスタ 2 向けのコントロール プレーン VIP | ユーザー クラスタ 2 のロードバランサで構成 | 172.16.22.50 |
| ユーザー クラスタ 2 の上り（内向き）VIP | ユーザー クラスタ 2 のロードバランサで構成 | 172.16.22.51 |
| ユーザー クラスタ 2 の Service VIP | LoadBalancer タイプの Service 用の 10 個のアドレス。必要に応じてユーザー クラスタ 2 のロードバランサで構成。 この範囲には上り（内向き）VIP が含まれます。 これは MetalLB ロードバランサの要件です。 |
172.16.22.51 - 172.16.22.60 |
IP アドレスの例: Pod とサービス
クラスタを作成する前に、Pod の IP アドレス用に CIDR 範囲を、また Kubernetes Services の ClusterIP アドレス用に別の CIDR 範囲を指定する必要があります。
Pod と Service に使用する CIDR 範囲を決定します。次に例を示します。
| 目的 | CIDR 範囲 |
|---|---|
| 管理クラスタ内の Pod | 192.168.0.0/16 |
| ユーザー クラスタ 1 内の Pod | 192.168.0.0/16 |
| ユーザー クラスタ 2 内の Pod | 192.168.0.0/16 |
| 管理クラスタ内の Service | 10.96.0.0/20 |
| ユーザー クラスタ 1 内の Service | 10.96.0.0/20 |
| ユーザー クラスタ 2 内の Service | 10.96.0.0/20 |
上の例は、以下の点を示しています。
Pod の CIDR 範囲は、デフォルトのアイランド モードのネットワーク モデルの複数のクラスタで同じになります。フラットモード ネットワークでは、Pod がすべてのクラスタで一意の IP アドレスを持っている必要があります。Pod に影響するネットワーク モデルの詳細については、フラットモードとアイランド モードのネットワーク モデルをご覧ください。
Service の 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 個のアドレスのみが存在します。
重複を回避する
CIDR 範囲が、ネットワーク内で到達可能な IP アドレスと重複しないように注意してください。Service と Pod の範囲は、クラスタ内から到達可能にする必要があるクラスタ外のアドレスと重複しないようにしてください。
たとえば、Service の範囲が 10.96.0.0/20、Pod の範囲が 192.168.0.0/16 であるとします。Pod からいずれかの範囲のアドレスに送信されたトラフィックは、クラスタ内トラフィックとして扱われ、クラスタ外の宛先に到達しません。
特に、Service と Pod の範囲が次の対象と重複しないようにする必要があります。
任意のクラスタ内に存在するノードの IP アドレス
ロードバランサ マシンで使用される IP アドレス
コントロール プレーン ノードとロードバランサで使用される VIP
DNS サーバーと NTP サーバーの IP アドレス
Service と Pod の範囲は RFC 1918 アドレス空間にすることをおすすめします。
RFC 1918 アドレスを使用することが推奨される理由の 1 つは次のとおりです。Pod または Service の範囲に外部 IP アドレスが含まれているとします。Pod からそれらの外部アドレスのいずれかに送信されたトラフィックは、クラスタ内トラフィックとして扱われ、外部の宛先に到達しません。
IP アドレスの割り振りのバリエーション
このドキュメントの例では、特定の種類のインストールに IP アドレスを割り振る方法の一つを示しています。ただし、GKE on Bare Metal はさまざまな方法でインストールできます。また、選択したバリエーションは、IP アドレスの計画方法に影響します。
たとえば、非 HA クラスタを使用する場合や、クラスタノードを複数のレイヤ 2 ドメインに分散することを決定する場合です。アイランド モード ネットワークではなく、フラットモード ネットワークを使用することを決定する場合もあります。
さまざまなインストールの種類に対するクラスタ構成ファイルで IP アドレスを指定する方法の例については、クラスタ構成サンプルをご覧ください。
異なるインストールの種類に対する IP アドレスを計画する方法については、次のドキュメントをご覧ください。
-
フラットモードでは、Pod には複数のクラスタにわたって一意のアドレスがあります。これに合わせて、Pod の CIDR 範囲を調整します。
-
ノード、Pod、Service には、IPv4 アドレスと IPv6 アドレスの両方があります。IPv6 ネットワークはフラットモードですが、IPv4 ネットワークはアイランド モードまたはフラットモードのいずれかにできます。フラットモード ネットワークの場合は、Pod のネットワーク到達性を調整する必要があります。
-
Pod のネットワーク到達性を調整する必要があります。Pod 範囲とノード範囲のサブセットをより広い範囲にします。
BGP をサポートするフラットモード ネットワーク モデルを実装する
クラスタ内の BGP スピーカーにはフローティング IP アドレスが必要であり、ピアルーターの IP アドレスを指定する必要があります。
-
クラスタ内の BGP スピーカーにはフローティング IP アドレスが必要であり、ピアルーターの IP アドレスを指定する必要があります。
Network Connectivity Gateway を構成する
ピア IP アドレスとローカル トンネル IP アドレスを指定する必要があります。