このドキュメントでは、Anthos clusters on VMware(GKE On-Prem)のインストール用に IP アドレスを計画する方法について説明します。
始める前に
Anthos clusters on VMware の概要とインストールの概要を確認してください。
IP アドレス割り当ての例
このセクションでは、次の要素を含むインストールで静的 IP アドレスを割り振る方法の例を示します。
管理ワークステーション。
管理クラスタ。
5 つのワーカーノードを持つ 1 つの高可用性(HA)ユーザー クラスタ
4 つのワーカーノードを持つ 1 つの非 HA ユーザー クラスタ
管理クラスタノード
7 つのノードがある管理クラスタでは、8 つの IP アドレスを確保する必要があります。クラスタのアップグレード、更新、自動修復時に必要になるため追加のアドレスが必要です。たとえば、管理クラスタ内のノード用に次の IP アドレスを確保できます。
- 管理クラスタのコントロール プレーンを実行する 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 を通知できます。
IP アドレスの例: 管理ワークステーション
この例で、管理ワークステーションは、管理クラスタと同じサブネット(172.16.20.0/24)にあります。管理ワークステーションには、ノードアドレスに近いアドレスが適しています。たとえば、172.16.20.20 です。
IP アドレスの例: 管理クラスタノード
次の表では、管理クラスタ内でノードに IP アドレスを使用する例を示します。このテーブルでは、admin-vm-8 という追加のノードが示されます。その追加ノードは、クラスタのアップグレード時に必要です。詳細については、ノード IP アドレスの管理をご覧ください。
VM ホスト名 | Description | IP アドレス |
---|---|---|
admin-vm-1 | 管理クラスタのコントロールプレーン ノード | 172.16.20.2 |
admin-vm-2 | 管理クラスタのアドオンノード | 172.16.20.3 |
admin-vm-3 | 管理クラスタのアドオンノード | 172.16.20.4 |
admin-vm-4 | ユーザー クラスタ 1 のコントロール プレーン ノード このノードは管理クラスタに配置されています。 |
172.16.20.5 |
admin-vm-5 | ユーザー クラスタ 1 のコントロール プレーン ノード このノードは管理クラスタに配置されています。 |
172.16.20.6 |
admin-vm-6 | ユーザー クラスタ 1 のコントロール プレーン ノード このノードは管理クラスタに配置されています。 |
172.16.20.7 |
admin-vm-7 | ユーザー クラスタ 2 のコントロール プレーン ノード このノードは管理クラスタに配置されています。 |
172.16.20.8 |
admin-vm-8 | 172.16.20.9 |
IP アドレスの例: 管理クラスタ サブネット内の VIP
次の表では、管理クラスタのロードバランサに構成される VIP の指定例を示します。ユーザー クラスタにある Kubernetes API サーバーの VIP は、管理クラスタ サブネット上になければなりません。ユーザー クラスタの Kubernetes API サーバーは、管理クラスタ内のノードで実行されるためです。なお、クラスタ構成ファイルで Kubernetes API サーバーの VIP を指定するフィールドは、controlPlaneVIP
と呼ばれます。
VIP | IP アドレス |
---|---|
管理クラスタの Kubernetes API サーバーの VIP。 | 172.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 ノード
次の表では、ユーザー クラスタ 1 のノードに使用される IP アドレスの例を示します。このテーブルには、予備のノード(user-1-vm-6)が示されています。この追加は、クラスタのアップグレード、更新、自動修復中に必要です。詳細については、ノード IP アドレスの管理をご覧ください。
VM ホスト名 | Description | IP アドレス |
---|---|---|
user-1-vm-1 | usercluster.workernode | 172.16.21.2 |
user-1-vm-2 | usercluster.workernode | 172.16.21.3 |
user-1-vm-3 | usercluster.workernode | 172.16.21.4 |
user-1-vm-4 | usercluster.workernode | 172.16.21.5 |
user-1-vm-5 | usercluster.workernode | 172.16.21.6 |
user-1-vm-6 | 172.16.21.7 |
IP アドレスの例: ユーザー クラスタ 1 サブネットの VIP
次の表に、ユーザー クラスタ 1 のロードバランサに構成する VIP を指定する方法に関する例を示します。
VIP | Description | IP アドレス |
---|---|---|
ユーザー クラスタ 1 の上り(内向き)VIP | ユーザー クラスタ 1 のロードバランサで構成 | 172.16.21.30 |
ユーザー クラスタ 1 の Service VIP | LoadBalancer タイプの Service 用の 10 個のアドレス。必要に応じてユーザー クラスタ 1 のロードバランサで構成。 この範囲には上り(内向き)VIP が含まれます。 これは MetalLB ロードバランサの要件です。 |
172.16.21.30 - 172.16.21.39 |
IP アドレスの例: ユーザー クラスタ 2 ノード
次の表では、user-cluster-2 のノードに IP アドレスを使用する例を示します。このテーブルには、予備のノード(user-2-vm-5)が示されています。この追加は、クラスタのアップグレード、更新、自動修復中に必要です。詳細については、ノード IP アドレスの管理をご覧ください。
VM ホスト名 | Description | IP アドレス |
---|---|---|
user-2-vm-1 | usercluster.workernode | 172.16.22.2 |
user-2-vm-2 | usercluster.workernode | 172.16.22.3 |
user-2-vm-3 | usercluster.workernode | 172.16.22.4 |
user-2-vm-4 | usercluster.workernode | 172.16.22.5 |
user-2-vm-5 | 172.16.22.6 |
IP アドレスの例: ユーザー クラスタ 2 サブネットの VIP
次の表に、ユーザー クラスタ 2 のロードバランサに構成する VIP を指定する方法に関する例を示します。
VIP | Description | IP アドレス |
---|---|---|
ユーザー クラスタ 2 の上り(内向き)VIP | ユーザー クラスタ 2 のロードバランサで構成 | 172.16.22.30 |
ユーザー クラスタ 2 の Service VIP | LoadBalancer タイプの Service 用の 10 個のアドレス。必要に応じてユーザー クラスタ 2 のロードバランサで構成。 この範囲には上り(内向き)VIP が含まれます。 これは MetalLB ロードバランサの要件です。 |
172.16.22.30 - 172.16.22.39 |
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 | TODO |
上の例は、以下の点を示しています。
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 と示されます。