このドキュメントでは、GKE on VMware のインストール用に IP アドレスを計画する方法について説明します。
準備
GKE on VMware の概要とインストールの概要を確認します。
IP アドレス割り当ての例
このセクションでは、次の要素を含むインストールで静的 IP アドレスを割り振る方法の例を示します。
管理ワークステーション。
管理クラスタ。
5 つのワーカーノードを持つ 1 つの高可用性（HA）ユーザー クラスタ
4 つのワーカーノードを持つ 1 つの非 HA ユーザー クラスタ
この例では、ユーザー クラスタで Controlplane V2 が有効になっています。Controlplane V2 では、ユーザー クラスタのコントロール プレーン ノードはユーザー クラスタ自体にあります。
管理クラスタノード
管理クラスタには 3 つのノードがあります。
- 管理クラスタのコントロール プレーンを実行する 1 つのノード
- 管理クラスタのアドオンを実行する 2 つのノード
ロード バランシング
この例では、クラスタが 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 をアナウンスできます。
IP アドレスの例: 管理ワークステーション
この例で、管理ワークステーションは、管理クラスタと同じサブネット（172.16.20.0/24）にあります。管理ワークステーションには、ノードアドレスに近いアドレスが適しています。たとえば、172.16.20.20 です。
IP アドレスの例: 管理クラスタノード
3 つのノードがある管理クラスタの場合は、4 つの IP アドレスを確保する必要があります。クラスタのアップグレード、更新、自動修復時に必要になるため追加のアドレスが必要です。たとえば、管理クラスタ内のノードには、次の IP アドレスを確保できます。
| 管理クラスタ内のノードの IP アドレス |
|---|
| 172.16.20.2 - 172.16.20.5 |
IP アドレスの例: 管理クラスタの VIP
次の表では、管理クラスタのロードバランサに構成される VIP の指定例を示します。なお、クラスタ構成ファイルで Kubernetes API サーバーの VIP を指定するフィールドは、controlPlaneVIP と呼ばれます。
| VIP | IP アドレス |
|---|---|
| 管理クラスタの Kubernetes API サーバーの VIP。 | 172.16.20.30 |
| 管理クラスタ アドオン VIP | 172.16.20.31 |
IP アドレスの例: ユーザー クラスタ 1 ノード
8 つのノードがあるユーザー クラスタでは、9 つの IP アドレスを確保する必要があります。クラスタのアップグレード、更新、自動修復時に必要になるため追加のアドレスが必要です。たとえば、ユーザー クラスタ 1 のノード用に次の IP アドレスを確保できます。
| ユーザー クラスタ 1 のノードの IP アドレス |
|---|
| 172.16.21.2 - 172.16.21.10 |
IP アドレスの例: ユーザー クラスタ 1 の VIP
次の表に、ユーザー クラスタ 1 のロードバランサに構成する VIP を指定する方法に関する例を示します。
| VIP | Description | IP アドレス |
|---|---|---|
| ユーザー クラスタ 1 の Kubernetes API サーバーの VIP | ユーザー クラスタ 1 のロードバランサで構成 | 172.16.21.30 |
| ユーザー クラスタ 1 の上り（内向き）VIP | ユーザー クラスタ 1 のロードバランサで構成 | 172.16.21.31 |
| ユーザー クラスタ 1 の Service VIP | LoadBalancer タイプの Service 用の 10 個のアドレス。必要に応じてユーザー クラスタ 1 のロードバランサで構成。 この範囲には上り（内向き）VIP が含まれます。 これは MetalLB ロードバランサの要件です。 |
172.16.21.31 - 172.16.21.40 |
IP アドレスの例: ユーザー クラスタ 2 ノード
5 つのノードがあるユーザー クラスタでは、6 つの IP アドレスを確保する必要があります。クラスタのアップグレード、更新、自動修復時に必要になるため追加のアドレスが必要です。たとえば、ユーザー クラスタ 2 のノード用に次の IP アドレスを確保できます。
| ユーザー クラスタ 2 のノードの IP アドレス |
|---|
| 172.16.22.2 - 172.16.22.7 |
IP アドレスの例: ユーザー クラスタ 2 の VIP
次の表に、ユーザー クラスタ 2 のロードバランサに構成する VIP を指定する方法に関する例を示します。
| VIP | Description | IP アドレス |
|---|---|---|
| ユーザー クラスタ 2 の Kubernetes API サーバーの VIP | ユーザー クラスタ 2 のロードバランサで構成 | 172.16.22.30 |
| ユーザー クラスタ 2 の上り（内向き）VIP | ユーザー クラスタ 2 のロードバランサで構成 | 172.16.22.31 |
| ユーザー クラスタ 2 の Service VIP | LoadBalancer タイプの Service 用の 10 個のアドレス。必要に応じてユーザー クラスタ 2 のロードバランサで構成。 この範囲には上り（内向き）VIP が含まれます。 これは MetalLB ロードバランサの要件です。 |
172.16.22.31 - 172.16.22.40 |
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.232.0/24 |
| ユーザー クラスタ 1 内の Service | 10.96.0.0/20 |
| ユーザー クラスタ 2 内の Service | 10.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 アドレスを使用することが推奨される理由の 1 つは次のとおりです。Pod または Service の範囲に外部 IP アドレスが含まれているとします。Pod からそれらの外部アドレスのいずれかに送信されたトラフィックは、クラスタ内トラフィックとして扱われ、外部の宛先に到達しません。
DNS サーバーとデフォルト ゲートウェイ
構成ファイルに入力する前に、管理ワークステーションとクラスタノードで使用できる DNS サーバーの IP アドレスを把握する必要があります。
また、各サブネットのデフォルト ゲートウェイの IP アドレスも把握している必要があります。上記の例では、各サブネットのデフォルト ゲートウェイが範囲内にある最初のアドレスになります。たとえば、管理クラスタのサブネットにあるデフォルト ゲートウェイは、172.16.20.1 と示されます。