このページでは、LoadBalancer Service の動作と構成を制御する Service マニフェストのパラメータについて説明します。このページを読む前に、Google Kubernetes Engine（GKE）LoadBalancer Service のコンセプトを理解しておいてください。
Service のパラメータ
GKE では、LoadBalancer Service の次のパラメータがサポートされています。
| パラメータ | Service フィールドと説明 | 内部 | 外部 | バージョン サポート |
|---|---|---|---|---|
| 内部パススルー ネットワーク ロードバランサ | networking.gke.io/load-balancer-type: "Internal"
内部パススルー ネットワーク ロードバランサを作成するように GKE に指示します。 詳細については、LoadBalancer Service のコンセプトをご覧ください。 |
サポートされているすべてのバージョン。 | ||
| バックエンド サービスベースの外部パススルー ネットワーク ロードバランサ | cloud.google.com/l4-rbs: "enabled"
バックエンド サービスベースの外部パススルー ネットワーク ロードバランサを作成するように GKE に指示します。 詳細については、LoadBalancer Service のコンセプトをご覧ください。 |
GKE 1.25.5 以降 | ||
| 内部トラフィック ポリシー | spec.internalTrafficPolicy
このパラメータは、GKE Dataplane V2 を実行しているクラスタではサポートされていません。 |
GKE 1.22 以降 | ||
| 外部トラフィック ポリシー | spec.externalTrafficPolicy
ロードバランサのヘルスチェックに合格するノード VM と、クラスタ内の準備完了のサービスを提供する Pod へのパケットのルーティング方法を制御します。また、GKE のサブセット化が有効になっている場合に、ノードを 詳細については、LoadBalancer Service のコンセプトをご覧ください。 |
GKE 1.14 以降（Windows ノードプールの場合は 1.23.4-gke.400 以降）。 | ||
| ヘルスチェック ポート | spec.healthCheckNodePort
LoadBalancer Service のロードバランサのヘルスチェックをデプロイします。このパラメータは、 |
サポートされているすべてのバージョン。 | ||
| ファイアウォール ルールと送信元 IP アドレスの許可リスト | spec.loadBalancerSourceRanges
特定のソース範囲のみを許可するように、GKE と VPC ネットワークでオプションのファイアウォール ルールを構成します。
また、 |
サポートされているすべてのバージョン。 | ||
| 静的 IP アドレス |
ロードバランサの転送ルールに割り当てられる静的 IPv4 アドレス、静的 IPv6 アドレス範囲、またはその両方を指定します。重要な構成要件と実装の詳細については、共通の IP アドレスの共有に関する考慮事項をご覧ください。 |
|
||
| Network Service Tiers | cloud.google.com/network-tier
GKE が外部転送ルールと IP アドレスに使用する Network Service Tiers を指定します。アノテーションの有効な値は |
GKE 1.19 以降。 | ||
| カスタム サブネット |
|
（IPv6 にのみ適用） |
|
|
| グローバル アクセス | networking.gke.io/internal-load-balancer-allow-global-access: "true"
VPC ネットワークまたは接続されたネットワークの任意のリージョンにあるクライアントが、転送ルールの IP アドレスにアクセスできるようにします。 |
GKE 1.16 以降ではプレビュー。GKE 1.17.9-gke.600 以降では一般提供しています。 | ||
| すべてのポート | アノテーションは必要ありませんが、GKE のサブセット化を有効にする必要があります。
|
GKE バージョン 1.18.19-gke.1400 以降 | ||
| ipFamilyPolicy |
GKE が Service に IP アドレスを割り振る方法を定義します。 詳細については、IPv4 / IPv6 デュアルスタック Service をご覧ください。 |
バージョン 1.29 以降の GKE クラスタでは、LoadBalancer Service のデュアルスタック ネットワークがサポートされます。 | ||
| ipFamilies（省略可） |
シングルスタックまたはデュアルスタックの Service を割り振る IP アドレス ファミリーを定義します。次のいずれかの値を使用します。
|
バージョン 1.29 以降の GKE クラスタでは、LoadBalancer Service のデュアルスタック ネットワークがサポートされます。 |
ヘルスチェック ポート
ロードバランサのヘルスチェックと externalTrafficPolicy で説明されているように、GKE は外部パススルー ネットワーク ロードバランサまたは内部パススルー ネットワーク ロードバランサを作成するときに、常にロードバランサのヘルスチェックをデプロイします。
healthCheckNodePort パラメータを設定できるかどうかは、次の externalTrafficPolicy 構成によって異なります。
externalTrafficPolicy |
ヘルスチェック ポート |
|---|---|
Cluster |
|
Local |
カスタムポートは、 |
ファイアウォール ルールと送信元 IP アドレスの許可リスト
LoadBalancer Service を作成すると、GKE によって Service に対応する VPC ファイアウォール ルールが作成されます。各ファイアウォール ルールには次の特徴があります。
- ファイアウォール ルールの方向は上り（内向き）で、アクションは allow です。Google Cloud の暗黙の上り（内向き）拒否ファイアウォール ルールは、GKE が上り（内向き）ファイアウォール ルールの作成時に許可リストモデルを使用することを意味します。
- GKE により、ファイアウォール ルールのプロトコルと宛先ポートは、Service の
spec.ports[]リストで指定されたものに設定されます。 - GKE は、ターゲット パラメータを LoadBalancer の仮想 IP アドレスに設定して、ファイアウォール ルールの宛先を設定します。
- Service に
spec.loadBalancerSourceRanges[]が含まれている場合、GKE により、ファイアウォール ルールの送信元パラメータは、そのリスト内の IP アドレスに設定されます。 また、各ノードで実行されているkube-proxyインスタンスにより、指定した IP アドレスにトラフィックを制限するように、そのノードのiptablesルールが構成されます。Service にloadBalancerSourceRanges[]が含まれていない場合、GKE により、ファイアウォール ルールの送信元パラメータは、すべての IP アドレス(0.0.0.0/0)に設定されます。
LoadBalancer Service 用に作成されたファイアウォール ルールでは、その Service のプロトコルと宛先ポートに一致するパケットを Service の仮想 IP アドレスに許可します。
共通ポートを使用する Service
クラスタに少なくとも 1 つの共通プロトコルと宛先ポートを共有する 2 つ以上の Service が含まれている場合、有効なソース範囲のセットは、そのプロトコルと宛先ポートの組み合わせを指定するすべての Service に対する loadBalancerSourceRanges の union になります。これは、上り（内向き）ファイアウォール ルールの target パラメータでは、宛先 IP アドレスが VM に関連付けられたすべての IP アドレスとして定義されているためです。
2 つの LoadBalancer Service があるクラスタについて考えてみましょう。
- 1 つ目の Service の
spec.ports[0].portは、TCP ポート80で、spec.loadBalancerSourceRanges=[100.10.0.0/16]です。この Service に対応するロードバランサは結果として、IP アドレス192.0.2.2を持ちます。 - 2 つ目の Service の
spec.ports[0].portは TCP ポート80、spec.ports[1].portは TCP ポート90で、spec.loadBalancerSourceRanges=[172.16.0.0/24]です。この Service に対応するロードバランサは結果として、IP アドレス198.51.100.3を持ちます。
GKE は、クラスタの Virtual Private Cloud ネットワークに 2 つの上り（内向き）許可ファイアウォール ルールを作成します。どちらのファイアウォール ルールも、クラスタのすべてのノードをターゲットとして指定します。
- 1 つ目のファイアウォール ルールは、送信元
100.10.0.0/16から TCP 宛先ポート80へのパケットを許可します。 - 2 つ目のファイアウォール ルールは、送信元
172.16.0.0/24から TCP 宛先ポート80と90へのパケットを許可します。
1 つ目の転送ルールは、192.0.2.2:80 の宛先に一致するトラフィックをルーティングします。2 つ目の転送ルールは、198.51.100.3:80 と 198.51.100.3:90 の両方の宛先に一致するトラフィックをルーティングします。各ノードでは、192.0.2.2:80、198.51.100.3:80、198.51.100.3:90 の 3 つはすべて有効な宛先です。これは次のことを意味します。
- どちらの Service も、送信元 IP アドレス範囲の union（
100.10.0.0/16または172.16.0.0/24）から TCP ポート80へのパケットを受け入れます。 - 2 つ目の Service は、
172.16.0.0/24から TCP ポート90へのパケットを受け入れます。
同じプロトコルと宛先ポートの組み合わせを使用するすべての Service では、そのプロトコルと宛先ポートの組み合わせを使用する 1 つ以上の Service で spec.loadBalancerSourceRanges を省略した場合、すべての IP アドレスが有効な送信元範囲のセットになります。たとえば、2 つ目の Service で spec.loadBalancerSourceRanges が省略されている場合、2 つ目のファイアウォールの送信元は 0.0.0.0/0 となり、次のとおりになります。
- どちらの Service も、送信元 IP アドレス範囲の union（
100.10.0.0/16または0.0.0.0/0）から、TCP ポート 80 へのパケットを受け入れます。0.0.0.0/0の範囲には100.10.0.0/16の範囲が含まれるため、TCP ポート 80 へのパケットの有効な送信元は任意の IP アドレスになります。 - 2 つ目の Service は
0.0.0.0/0（任意の IP アドレス）から TCP ポート90へのパケットを受け入れます。
静的 IP アドレス
静的 IP アドレスを作成し、その静的アドレスをロードバランサの転送ルールに割り当てるように GKE を構成できます。静的 IP アドレスを使用すると、LoadBalancer Service に変更を加えても、ロードバランサの IP アドレスは変わりません。静的 IP アドレスがない場合、GKE は LoadBalancer Service を更新するときに、ロードバランサ転送ルールに別の IP アドレスを割り当てることがあります。転送ルールの IP アドレスは、Service の spec.clusterIP アドレスと同じではありません。LoadBalancer Service を更新しても、Service の ClusterIP アドレスは変更されません。
静的 IP アドレス パラメータ
LoadBalancer Service に静的 IP アドレスを使用するように指示するには、spec.loadBalancerIP パラメータまたは networking.gke.io/load-balancer-ip-addresses アノテーションを使用します。GKE バージョン 1.29 以降では、Service マニフェストにパラメータとアノテーションの両方が含まれている場合、アノテーションが spec.loadBalancerIP よりも優先されます。
| パラメータまたはアノテーションと値 | 要件と機能 |
|---|---|
spec.loadBalancerIP:IPv4_ADDRESS
|
IPv4 のみの内部 LoadBalancer Service に対して、静的内部 IPv4 アドレスを指定できます。IPv4 のみの外部 LoadBalancer Service に対して、静的外部 IPv4 アドレスを指定できます。このパラメータは、サポートされているすべての GKE バージョンで使用できます。 |
networking.gke.io/load-balancer-ip-addresses:IP_ADDRESS_RESOURCE_NAME
|
IPv4 のみ、IPv6 のみ、およびデュアルスタックの内部 LoadBalancer Service と外部 LoadBalancer Service には、静的 IPv4 アドレス、静的 IPv6 アドレス範囲、またはその両方を指定できます。アノテーションには GKE 1.29 以降が必要で、次の追加要件があります。
|
共通の IP アドレスの共有に関する考慮事項
このセクションの表で示すように、各ロードバランサの転送ルールで IP アドレス、プロトコル、ポート指定、Network Service Tiers 仕様の一意の組み合わせが使用されている場合、2 つ以上の LoadBalancer Service が同じ静的 IP アドレスを参照できます。また、次の点も注意してください。
静的 IPv6 アドレスは実際には
/96IPv6 アドレス範囲ですが、GKE は、/96範囲の最初の IPv6 アドレス（/128）のパケットのみを受け入れるようにノードを構成します。複数の内部 LoadBalancer Service で同じ内部 IPv4 アドレスまたは内部 IPv6 アドレス範囲を使用するには、
SHARED_LOADBALANCER_VIPの目的で静的 IP アドレスを作成する必要があります。
| 内部 LoadBalancer Service | 外部 LoadBalancer Service | |
|---|---|---|
| ポートの指定 | 内部パススルー ネットワーク ロードバランサの転送ルールは、最大 5 つの個別のポート番号をサポートします。または、すべてのポートを使用するように構成することもできます。 内部 LoadBalancer Service に 6 つ以上の 転送ルールですべてのポートが使用される場合、他の転送ルール（つまり、他の内部 LoadBalancer Service）で同じ IP アドレスを使用することはできません。 |
LoadBalancer Service マニフェストに ターゲット プールベースの外部パススルー ネットワーク ロードバランサの転送ルールでは、連続したポート範囲を使用する必要があります。この連続したポート範囲には、Service が必要とするすべてのポートが含まれますが、Service で使用されないポートが含まれることもあります。たとえば、Service マニフェストでポート 80 と 443 を指定しているターゲット プール ベースの外部パススルー ネットワーク ロードバランサを利用する外部 LoadBalancer Service は、ポート範囲 80～443 のロードバランサ転送ルールを使用します。このポート範囲により、他の外部 LoadBalancer Service はポート 80 と 443 に加えて、その間の番号も使用できなくなります。 LoadBalancer Service マニフェストに |
| Network Service Tiers | 構成不可。内部アドレスは常にプレミアム ティアです。 | 静的リージョン外部 IPv4 アドレス用に構成できます。静的リージョン外部 IPv6 アドレス範囲は、プレミアム ティアでのみ作成できます。 静的外部 IP アドレスの Network Service Tiers の仕様が、次のいずれかと一致している必要があります。
プロジェクトのデフォルト ティアは、別途構成されていない限り、プレミアムです。 |
LoadBalancer のサブネット
クラスタと同じリージョンおよび VPC ネットワークにあるカスタム サブネットで、エフェメラルまたは静的 IPv4 アドレス、IPv6 アドレス範囲、またはその両方を使用するように、内部 LoadBalancer Service を構成できます。内部 LoadBalancer Service にカスタム サブネットを使用すると、次のことができます。
- 同じ VPC ネットワークとリージョン内の 2 つ以上の GKE クラスタから内部 LoadBalancer Service によって作成された内部パススルー ネットワーク ロードバランサをグループ化する。
- 内部パススルー ネットワーク ロードバランサの IPv4 アドレスがクラスタのノード IPv4 アドレスと異なる内部 LoadBalancer Service を作成する。
- デュアルスタック クラスタで、内部パススルー ネットワーク ロードバランサがクラスタのノードおよび Pod の IPv6 アドレスと異なる IPv6 アドレス範囲を持つ内部 LoadBalancer Service を作成する。クラスタのサブネットに外部 IPv6 アドレス範囲がある場合、内部 LoadBalancer Service をサポートするには、カスタム LoadBalancer サブネットが必要です。
クラスタと同じリージョンおよび VPC ネットワークにあるカスタム サブネットで、エフェメラルまたは静的 IPv6 アドレス範囲を使用するように外部 LoadBalancer Service を構成できます。カスタム サブネットを使用して、外部パススルー ネットワーク ロードバランサの IPv6 アドレス範囲がクラスタのノードおよび Pod の IPv6 アドレスと異なる外部 LoadBalancer Service を作成します。デュアルスタック限定公開クラスタで外部 LoadBalancer Service をサポートする場合は、クラスタのサブネットに内部 IPv6 アドレス範囲があるため、カスタム LoadBalancer サブネットが必要です。
カスタム サブネットのアノテーション
次のいずれかのアノテーションを使用して、カスタム サブネット内のエフェメラルまたは静的 IP アドレスを使用するように LoadBalancer Service に指示します。LoadBalancer Service のマニフェストに両方のアノテーションが含まれている場合、アノテーション要件が満たされていれば、networking.gke.io/load-balancer-subnet アノテーションが優先されます。
| アノテーションと値 | 要件と機能 |
|---|---|
networking.gke.io/internal-load-balancer-subnet:SUBNET_RESOURCE_NAME
|
アノテーションは、IPv4 のみの内部 LoadBalancer Service のカスタム サブネットを指定する場合にのみ使用できます。アノテーションは、サポートされているすべての GKE バージョンで機能します。 |
networking.gke.io/load-balancer-subnet:SUBNET_RESOURCE_NAME
|
IPv4 のみ、IPv6 のみ、またはデュアルスタックの内部 LoadBalancer Service のカスタム サブネットを指定できます。IPv6 のみまたはデュアルスタックの外部 LoadBalancer Service にカスタム サブネットを指定できます。アノテーションには GKE 1.29 以降が必要で、次の追加要件があります。
|
内部 LoadBalancer Service のサブネットと IPv4 アドレス
次の表に、IPv4 のみまたはデュアルスタックの内部 LoadBalancer Service で有効なサブネット仕様と IPv4 アドレスの組み合わせを示します。
静的 IPv4 アドレス
|
エフェメラル IPv4 アドレス | |
|---|---|---|
カスタム サブネット
|
カスタム サブネットと静的 IPv4 アドレス: 静的内部 IPv4 アドレスは、カスタム サブネットのプライマリ IPv4 アドレス範囲内で作成されている必要があります。 | カスタム サブネットとエフェメラル IPv4 アドレス: GKE は、カスタム サブネットのプライマリ IPv4 アドレス範囲内にある未割り振りの内部 IPv4 アドレスを使用します。 |
| クラスタのサブネット | クラスタのサブネットと静的 IPv4 アドレス: 静的内部 IPv4 アドレスは、クラスタのサブネットのプライマリ IPv4 アドレス範囲内で作成されている必要があります。 | クラスタのサブネットとエフェメラル IPv4 アドレス: GKE は、クラスタのサブネットのプライマリ IPv4 アドレス範囲内にある未割り振りの内部 IPv4 アドレスを使用します。 |
内部 LoadBalancer Service のサブネットと IPv6 アドレス範囲
次の表に、IPv6 のみまたはデュアルスタックの内部 LoadBalancer Service で有効なサブネット仕様と IPv6 アドレス範囲の組み合わせを示します。内部パススルー ネットワーク ロードバランサの IPv6 転送ルールは内部 /96 IPv6 アドレス範囲を使用しますが、GKE は、宛先が転送ルールの /96 範囲にある最初の IPv6 アドレス（/128）と一致するパケットのみを受け入れるようにノードを構成します。
静的 IPv6 アドレス範囲
|
エフェメラル IPv6 アドレス範囲 | |
|---|---|---|
カスタム デュアルスタック サブネット
|
カスタム サブネットと静的 IPv6 アドレス範囲: 静的内部 /96 IPv6 アドレス範囲は、カスタム サブネットの内部 /64 IPv6 アドレス範囲内で作成されている必要があります。
|
カスタム サブネットとエフェメラル IPv6 アドレス範囲: GKE は、カスタム サブネットの内部 /64 IPv6 アドレス範囲内にある未割り振りの内部 /96 IPv6 アドレス範囲を使用します。 |
クラスタのデュアルスタック サブネット
|
クラスタのサブネットと静的 IPv6 アドレス範囲: 静的内部 /96 IPv6 アドレス範囲は、クラスタのサブネットの内部 /64 IPv6 アドレス範囲内で作成されている必要があります。
|
クラスタのサブネットとエフェメラル IPv6 アドレス範囲: GKE は、クラスタのサブネットの内部 /64 IPv6 アドレス範囲内にある未割り振りの内部 /96 IPv6 アドレス範囲を使用します。
|
外部 LoadBalancer Service のサブネットと IPv4 アドレス
IPv4 のみおよびデュアルスタックの外部 LoadBalancer Service の外部 IPv4 アドレスは、静的外部 IPv4 アドレスとエフェメラル外部 IPv4 アドレスのどちらの場合も、サブネットから取得されません。
外部 LoadBalancer Service のサブネットと IPv6 アドレス範囲
次の表に、IPv6 のみまたはデュアルスタックの外部 LoadBalancer Service で有効なサブネット仕様と IPv6 アドレス範囲の組み合わせを示します。外部パススルー ネットワーク ロードバランサの IPv6 転送ルールは外部 /96 IPv6 アドレス範囲を使用しますが、GKE は、宛先が転送ルールの /96 範囲にある最初の IPv6 アドレス（/128）と一致するパケットのみを受け入れるようにノードを構成します。
静的 IPv6 アドレス範囲
|
エフェメラル IPv6 アドレス範囲 | |
|---|---|---|
カスタム デュアルスタック サブネット
|
カスタム サブネットと静的 IPv6 アドレス範囲: 静的外部 /96 IPv6 アドレス範囲は、カスタム サブネットの外部 /64 IPv6 アドレス範囲内で作成されている必要があります。静的外部 IPv6 アドレス範囲は、プレミアム ティアでのみ作成できます。
|
カスタム サブネットとエフェメラル IPv6 アドレス範囲: GKE は、カスタム サブネットの外部 /64 IPv6 アドレス範囲内にある未割り振りの外部 /96 IPv6 アドレス範囲を使用します。
|
クラスタのデュアルスタック サブネット
|
クラスタのサブネットと静的 IPv6 アドレス範囲: 静的外部 /96 IPv6 アドレス範囲は、クラスタのサブネットの外部 /64 IPv6 アドレス範囲内で作成されている必要があります。静的外部 IPv6 アドレス範囲は、プレミアム ティアでのみ作成できます。
|
クラスタのサブネットとエフェメラル IPv6 アドレス範囲: GKE は、クラスタのサブネットの外部 /64 IPv6 アドレス範囲内にある未割り振りの外部 /96 IPv6 アドレス範囲を使用します。
|
グローバル アクセス
networking.gke.io/internal-load-balancer-allow-global-access アノテーションが false であるか、内部 LoadBalancer Service で指定されていない場合、GKE は転送ルールでグローバル アクセスが無効になっている内部パススルー ネットワーク ロードバランサを作成します。グローバル アクセスが無効になっている場合、ロードバランサにアクセスする必要があるクライアントは、同じリージョンと VPC ネットワーク、またはクラスタの VPC ネットワークに接続されているネットワークに配置する必要があります。
内部 LoadBalancer Service の networking.gke.io/internal-load-balancer-allow-global-access アノテーションが true の場合、GKE は内部パススルー ネットワーク ロードバランサの転送ルールでグローバル アクセス オプションを有効にします。VPC ネットワークの任意のリージョンに配置されているクライアント、またはクラスタの VPC ネットワークに接続されているネットワーク内のクライアントは、ロードバランサにアクセスできます。
接続されているネットワーク内のクライアントにグローバルにアクセスする方法の詳細については、以下をご覧ください。
- 内部パススルー ネットワーク ロードバランサのドキュメントに記載されているクライアント アクセス
- 内部パススルー ネットワーク ロードバランサと接続ネットワーク
すべてのポート転送ルール
内部パススルー ネットワーク ロードバランサの転送ルールは、5 つの一意のポート番号またはすべてのポートをサポートします。
GKE のサブセット化が無効になっている GKE クラスタでは、内部 LoadBalancer Service は、Service の spec.ports[].port で 5 つの一意のポートのみをサポートします。
GKE のサブセット化が有効になっている GKE クラスタでは、内部 LoadBalancer Service は、Service の spec.ports[].port で最大 100 ポートまでしかサポートできません。6～100 個の一意の spec.ports[].port エントリを持つ内部 LoadBalancer Service の場合、GKE では、内部パススルー ネットワーク ロードバランサの転送ルールが、作成時からすべてのポートを使用するように構成されます。サービスに存在するポート数が 5 つを超えるため、GKE コントローラは転送ルールですべてのポートを有効にします。すべてのポートを使用するように転送ルールを構成する場合、GKE は、Service の spec.ports[].port に構成されている特定のポートに対してのみ、上り（内向き）許可ファイアウォール ルールを作成します。
内部パススルー ネットワーク ロードバランサの転送ルールと有効なポートの仕様の詳細については、転送ルールとポートの仕様をご覧ください。
IPv4 / IPv6 デュアルスタック LoadBalancer Service
内部または外部の LoadBalancer Service は、シングルスタック（IPv4 と IPv6 のどちらかのみ）またはデュアルスタックのいずれかで作成できます。シングルスタック LoadBalancer Service は、IPv4 アドレスまたは IPv6 アドレスのいずれかを持つ単一の転送ルールを作成します。デュアルスタック LoadBalancer Service は、IPv4 アドレス用と IPv6 アドレス用の 2 つの転送ルールを作成します。IPv4 / IPv6 デュアルスタック LoadBalancer Service を作成するには、IPv4 / IPv6 のデュアルスタック クラスタにデプロイし、使用するロードバランサのタイプに応じて次のいずれかを実施します。
- 内部 LoadBalancer Service の場合は、GKE のサブセット化を有効にする必要があります。詳細については、内部ロードバランサのサブセット化の有効化をご確認ください。
- 外部 LoadBalancer Service の場合は、リージョン バックエンド サービスを使用するバックエンド サービスベースの外部パススルー ネットワーク ロードバランサを使用する必要があります。詳細については、バックエンド サービスベースの外部ネットワーク ロードバランサに関する記事をご覧ください。
Service ごとに、ipFamilyPolicy と ipFamilies の仕様を定義できます。詳細については、IPv4 / IPv6 のデュアルスタックに関する記事をご覧ください。
デュアルスタック LoadBalancer Service の制限
- IPv6 アドレスを持つ LoadBalancer Service は、スタックタイプが
ipv4-ipv6のクラスタでのみサポートされます。詳細については、VPC ネイティブ クラスタでデュアル スタックの IP アドレスを使用する方法をご覧ください。 シングルスタック アドレスで作成された LoadBalancer Service は、デュアルスタック サービスにアップグレードできません。
デュアルスタック アドレスで作成された LoadBalancer Service は、次の条件に従ってシングルスタックに変更できます。
- ipFamilies
["IPv4","IPv6"]を持つ Service は、ipFamiliesIPv4を持つ Service に変更できますが、IPv6には変更できません。 - ipFamilies
["IPv6","IPv4"]を持つ Service は、ipFamiliesIPv6を持つ Service に変更できますが、IPv4には変更できません。
- ipFamilies