このページでは、Google Kubernetes Engine(GKE)で内部 TCP / UDP ロードバランサを作成する方法について説明します。外部ネットワーク ロードバランサを作成するために、LoadBalancer タイプの Service の作成方法を学習する。
内部 TCP / UDP ロードバランサのサブセット化を使用する
内部 TCP / UDP ロードバランサを使用すると、同じ VPC ネットワークを使用し、同じ Google Cloud リージョンに配置されているクラスタ外のアプリケーションに、クラスタのサービスがアクセスできるようになります。たとえば、us-west1
リージョンにクラスタを配置している場合、そのクラスタのサービスの 1 つが、同じ VPC ネットワークを使用し、このリージョンで実行されている Compute Engine 仮想マシン(VM)インスタンスにアクセスできるようになります。
GKE の内部ロードバランサ サブセット化は、バックエンドを小さな重複グループにパーティショニングすることで、内部 TCP / UDP ロードバランサのスケーラビリティを改善します。サブセット化を使用すると、250 を超えるノードを持つクラスタで内部 TCP / UDP ロードバランサを構成できます。
Autopilot クラスタでは、内部ロードバランサのサブセット化がデフォルトで有効になっているため、ワークロードのデプロイまでスキップできます。Standard クラスタでは、クラスタの作成時と既存のクラスタを編集することで、サブセット化を有効にできます。
要件と制限事項
GKE のサブセット化には次の要件と制限があります。
- GKE バージョン 1.18.19-gke.1400 以降では、新規および既存の Standard クラスタのサブセット化を有効にできます。
- クラスタで
HttpLoadBalancing
アドオンが有効になっている必要があります。このアドオンはデフォルトで有効になっており、Autopilot クラスタで無効にすることはできません。このアドオンを無効にしている Standard クラスタでは、サブセット化を使用できません。HttpLoadBalancing
アドオンを有効にしてカスタム Ingress コントローラを実行する方法については、カスタム Ingress コントローラを使用するをご覧ください。 - Google Cloud CLI バージョン 345.0.0 以降が必要です。
- ネットワーク エンドポイント グループの割り当てが適用されます。Google Cloud は、内部 TCP / UDP ロードバランサにつき、ゾーンごとに 1 つの NEG を作成します。
- 転送ルール、バックエンド サービス、その他のネットワーク リソースの割り当てが適用されます。
- Standard クラスタで一度有効にしたサブセット化を無効にすることはできません。
- バックエンド サービスを共有するためのアノテーションにサブセット設定(
alpha.cloud.google.com/load-balancer-backend-share
)を使用することはできません。
準備
作業を始める前に、次のことを確認してください。
- Google Kubernetes Engine API を有効にします。 Google Kubernetes Engine API の有効化
- このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化します。
新しい Standard クラスタで内部ロードバランサのサブセット化を有効にする
内部ロードバランサのサブセット化を有効にした Standard クラスタを作成するには、Google Cloud CLI または Google Cloud コンソールを使用します。
Console
Google Cloud コンソールで [Google Kubernetes Engine] ページに移動します。
[add_box 作成] をクリックします。
必要に応じてクラスタを構成します。
ナビゲーション パネルの [クラスタ] の下の [ネットワーキング] をクリックします。
[L4 内部ロードバランサのサブセット化を有効にする] チェックボックスをオンにします。
[作成] をクリックします。
gcloud
gcloud container clusters create CLUSTER_NAME \
--cluster-version=VERSION \
--enable-l4-ilb-subsetting \
--region=COMPUTE_REGION
次のように置き換えます。
CLUSTER_NAME
: 新しいクラスタの名前。VERSION
: GKE バージョン。1.18.19-gke.1400 以降にする必要があります。--release-channel
オプションを使用して、リリース チャンネルを選択することもできます。リリース チャンネルには、デフォルトのバージョン 1.18.19-gke.1400 以降が必要です。COMPUTE_REGION
: クラスタの Compute Engine のリージョン。
既存のクラスタで内部ロードバランサのサブセット化を有効にする
既存の Standard クラスタの内部ロードバランサ サブセット化を有効にするには、gcloud CLI または Google Cloud コンソールを使用します。クラスタで一度有効にした内部ロードバランサのサブセット化は無効にできません。
Console
Google Cloud コンソールで、Google Kubernetes Engine のページに移動します。
クラスタのリストで、変更するクラスタの名前をクリックします。
[ネットワーキング] で、[L4 内部ロードバランサのサブセット化] フィールドの横にある [editL4 内部ロードバランサのサブセット化を有効にする] をクリックします。
[L4 内部ロードバランサのサブセット化を有効にする] チェックボックスをオンにします。
[変更を保存] をクリックします。
gcloud
gcloud container clusters update CLUSTER_NAME \
--enable-l4-ilb-subsetting
次のように置き換えます。
CLUSTER_NAME
: クラスタの名前。
ワークロードをデプロイする
以下のマニフェストは、サンプルのウェブ アプリケーション コンテナ イメージを実行する Deployment を説明しています。
マニフェストを
ilb-deployment.yaml
として保存します。apiVersion: apps/v1 kind: Deployment metadata: name: ilb-deployment spec: replicas: 3 selector: matchLabels: app: ilb-deployment template: metadata: labels: app: ilb-deployment spec: containers: - name: hello-app image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
マニフェストをクラスタに適用します。
kubectl apply -f ilb-deployment.yaml
内部 TCP ロードバランサを作成する
Service を使用して内部 TCP ロードバランサを作成します。この内部ロードバランサは TCP ポート 8080 に割り当てられています。
マニフェストを
ilb-svc.yaml
として保存します。apiVersion: v1 kind: Service metadata: name: ilb-svc annotations: networking.gke.io/load-balancer-type: "Internal" spec: type: LoadBalancer externalTrafficPolicy: Cluster selector: app: ilb-deployment ports: - name: tcp-port protocol: TCP port: 8080 targetPort: 8080
マニフェストには次のものを含める必要があります。
- Service の
name
。この場合ilb-svc
です。 - 内部 TCP / UDP ロードバランサを指定するアノテーション。アノテーションは、GKE クラスタのバージョンによって異なります。GKE バージョン 1.17 以降の場合は、アノテーション
networking.gke.io/load-balancer-type: "Internal"
を使用します。それよりも前のバージョンでは、アノテーションcloud.google.com/load-balancer-type: "Internal"
を使用します。 type: LoadBalancer
。spec: selector
フィールド。Service が対象にするポッドを指定します。例:app: hello
port
には、Service が公開されるポートを指定します。targetPort
には、コンテナがリッスンするポートを指定します。
- Service の
マニフェストをクラスタに適用します。
kubectl apply -f ilb-svc.yaml
Service に関する詳細情報を取得します。
kubectl get service ilb-svc --output yaml
出力は次のようになります。
apiVersion: v1 kind: Service metadata: annotations: cloud.google.com/neg: '{"ingress":true}' cloud.google.com/neg-status: '{"network_endpoint_groups":{"0":"k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r"},"zones":["us-central1-a","us-central1-b","us-central1-c"]}' kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{"networking.gke.io/load-balancer-type":"Internal"},"name":"ilb-svc","namespace":"default"},"spec":{"externalTrafficPolicy":"Cluster","ports":[{"name":"tcp-port","port":8080,"protocol":"TCP","targetPort":8080}],"selector":{"app":"ilb-deployment"},"type":"LoadBalancer"}} networking.gke.io/load-balancer-type: Internal service.kubernetes.io/backend-service: k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r service.kubernetes.io/firewall-rule: k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r service.kubernetes.io/firewall-rule-for-hc: k8s2-pn2h9n5f-l4-shared-hc-fw service.kubernetes.io/healthcheck: k8s2-pn2h9n5f-l4-shared-hc service.kubernetes.io/tcp-forwarding-rule: k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r creationTimestamp: "2022-07-22T17:26:04Z" finalizers: - gke.networking.io/l4-ilb-v2 - service.kubernetes.io/load-balancer-cleanup name: ilb-svc namespace: default resourceVersion: "51666" uid: d7a1a865-7972-44e1-aa9e-db5be23d6567 spec: allocateLoadBalancerNodePorts: true clusterIP: 10.88.2.141 clusterIPs: - 10.88.2.141 externalTrafficPolicy: Cluster internalTrafficPolicy: Cluster ipFamilies: - IPv4 ipFamilyPolicy: SingleStack ports: - name: tcp-port nodePort: 30521 port: 8080 protocol: TCP targetPort: 8080 selector: app: ilb-deployment sessionAffinity: None type: LoadBalancer status: loadBalancer: ingress: - ip: 10.128.15.245
出力には次の属性があります。
- 内部ロードバランサの IP アドレス(
status.loadBalancer.ingress
の下)。この IP アドレスは、clusterIP
の値と異なります。この例の場合、ロードバランサの IP アドレスは10.128.15.245
です。 app: ilb-deployment
というラベルを持つポッドは、この Service のメンバーです。これらは、内部ロードバランサに送信されたリクエストを最後に受信するポッドになります。クライアントは、Service マニフェストの
port
フィールドに指定されたloadBalancer
IP アドレスと TCP ポートを使用して Service を呼び出します。リクエストは、targetPort
フィールドに指定された TCP ポートのいずれかのメンバーポッドに転送されます。前の例で、クライアントは TCP ポート 80 の10.128.15.245
で Service を呼び出します。リクエストは、いずれかのメンバーポッドの TCP ポート 8080 に転送されます。メンバー Pod には、ポート 8080 でリッスンするコンテナが必要です。nodePort
値 30521 は無関係です。内部ロードバランサには関係ありません。
- 内部ロードバランサの IP アドレス(
Service ネットワーク エンドポイント グループを検査します。
kubectl get svc ilb-svc -o=jsonpath="{.metadata.annotations.cloud\.google\.com/neg-status}"
出力は次のようになります。
{"network_endpoint_groups":{"0":"k8s2-knlc4c77-default-ilb-svc-ua5ugas0"},"zones":["us-central1-c"]}
レスポンスは、GKE が
k8s2-knlc4c77-default-ilb-svc-ua5ugas0
という名前のネットワーク エンドポイント グループを作成したことを示します。このアノテーションは、GKE サブセット設定を使用するLoadBalancer
タイプの Service に存在し、サブセット設定を使用しない Service には存在しません。
ロードバランサの転送ルールを表示する
内部ロードバランサは転送ルールとして実装されています。転送ルールにはバックエンド Service が設定され、この Service にはインスタンス グループが設定されています。
内部ロードバランサのアドレス(前の例では 10.128.15.245
)は転送ルールのアドレスと同じです。内部ロードバランサを実装する転送ルールを確認するには、プロジェクト内のすべての転送ルールのリストを取得します。
gcloud compute forwarding-rules list --filter="loadBalancingScheme=INTERNAL"
出力には、内部ロードバランサと同じアドレスの転送ルールが含まれます(この例では 10.128.15.245
)。
NAME ... IP_ADDRESS ... TARGET
...
k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r 10.128.15.245 us-central1/backendServices/k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
出力には、関連するバックエンド サービスも表示されます(この例では k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r
)。
バックエンド サービスの説明:
gcloud compute backend-services describe k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r --region=us-central1
出力には、関連するインスタンス グループが表示されます(この例では k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r
)。
backends:
- balancingMode: CONNECTION
group: .../us-central1-b/networkEndpointGroups/k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
...
kind: compute#backendService
loadBalancingScheme: INTERNAL
name: aae3e263abe0911e9b32a42010a80008
...
内部 TCP ロードバランサを確認する
VM インスタンスに SSH で接続し、次のコマンドを実行します。
curl LOAD_BALANCER_IP
LOAD_BALANCER_IP
は、LoadBalancer ingress
の IP アドレスに置き換えます。
レスポンスには ilb-deployment
の出力が含まれます。
Hello, world!
Version: 1.0.0
Hostname: ilb-deployment-77b45987f7-pw54n
同じ VPC ネットワークの外部または同じリージョンの外部からコマンドを実行すると、タイムアウト エラーが発生します。グローバル アクセスを構成すると、同じ VPC ネットワーク内の任意のリージョン内に配置されているクライアントがロードバランサにアクセスできます。
内部 TCP ロードバランサのリソースを削除する
Deployment と Service を削除するには、kubectl delete
または Google Cloud コンソールを使用します。
kubectl
Deployment を削除する
Deployment を削除するには、次のコマンドを実行します。
kubectl delete deployment ilb-deployment
Service を削除する
Service を削除するには、次のコマンドを実行します。
kubectl delete service ilb-svc
Console
Deployment を削除する
Deployment を削除するには、次の手順を行います。
Google Cloud コンソールの [ワークロード] ページに移動します。
削除する Deployment を選択して、[delete 削除] をクリックします。
確認を求められたら、[Delete Horizontal Pod Autoscaler associated with selected Deployment] チェックボックスをオンにして、[削除] をクリックします。
Service を削除する
Service を削除するには、次の手順を行います。
Google Cloud コンソールの [Service と Ingress] ページに移動します。
削除するサービスを選択して、[delete 削除] をクリックします。
確認のメッセージが表示されたら、[削除] をクリックします。
Service のパラメータ
構成可能なロードバランサのパラメータの詳細については、TCP / UDP 負荷分散の構成をご覧ください。さらに、内部 LoadBalancer Service は、次の追加パラメータをサポートしています。
機能 | 概要 | サービス フィールド | GKE バージョンのサポート |
---|---|---|---|
ロードバランサのサブネット | ロードバランサが IP を自動的にプロビジョニングするサブネットを指定します。 | metadata:annotations:
networking.gke.io/internal-load-balancer-subnet |
GKE 1.17 以降と 1.16.8-gke.10 以降のベータ版 GKE 1.17.9-gke.600 以降の一般提供 |
グローバル アクセス | Google Cloud リージョンのクライアントが内部 TCP / UDP ロードバランサの仮想 IP アドレスにアクセスできるようにします。 | metadata:annotations:
networking.gke.io/internal-load-balancer-allow-global-access |
GKE 1.16 以降のベータ版 GKE 1.17.9-gke.600 以降の一般提供 |
ロードバランサのサブネット
デフォルトでは、GKE はノードのサブネット範囲を使用して内部 TCP / UDP ロードバランサをデプロイします。サブネットは、networking.gke.io/internal-load-balancer-subnet
アノテーションを使用して Service ごとに指定できます。これは、内部ロードバランサの IP をノード IP から個別にファイアウォールする場合や、複数の GKE クラスタ間で同じ Service のサブネットを共有する場合に便利です。このパラメータは、内部 TCP / UDP ロードバランサの Service にのみ関連します。
GKE はサブネット自体のライフサイクルを管理しないため、Servie のリソースによって参照される前にサブネットが存在する必要があります。サブネットは、GKE クラスタと同じ VPC とリージョンに存在する必要もあります。このステップでは、GKE から帯域外に作成されます。
gcloud compute networks subnets create gke-vip-subnet \
--network=default \
--range=10.23.0.0/24 \
--region=us-central1
次の Service 定義では、internal-load-balancer-subnet
を使用してサブネットを名前で参照します。デフォルトでは、サブネットから使用可能な IP が自動的に選択されます。loadBalancerIP
を指定することもできますが、参照されるサブネットの一部である必要があります。
この内部ロードバランサのサブネットを共有して、さまざまなユースケースを実現する方法は複数あります。
- 同じクラスタ内の Service のグループに対する複数のサブネット
- クラスタ内のすべての Service の単一サブネット
- 複数のクラスタと Service 間で共有される単一のサブネット
apiVersion: v1
kind: Service
metadata:
name: ilb-svc
annotations:
networking.gke.io/load-balancer-type: "Internal"
networking.gke.io/internal-load-balancer-subnet: "gke-vip-subnet"
labels:
app: hello
spec:
type: LoadBalancer
loadBalancerIP: 10.23.0.15
selector:
app: hello
ports:
- port: 80
targetPort: 8080
protocol: TCP
グローバル アクセス
グローバル アクセスは、同じ VPC ネットワーク内の任意のリージョンに配置されているクライアントに対し、内部 TCP / UDP ロードバランサへのアクセスを許可するために使用する、内部 LoadBalancer Service のオプション パラメータです。グローバル アクセスを使用しない場合、トラフィックを送信するクライアントは、ロードバランサと同じ VPC ネットワーク内の同じリージョンに配置されていなければなりません。グローバル アクセスを使用すると、任意のリージョン内のクライアントがロードバランサにアクセスできます。ただし、バックエンド インスタンスはロードバランサと同じリージョン内に配置されている必要があります。
グローバル アクセスは、次のアノテーションを使用してサービスごとに有効にされます。networking.gke.io/internal-load-balancer-allow-global-access: "true"
従来のネットワークでは、グローバル アクセスはサポートされません。リージョン間でグローバル アクセスを使用する場合は、通常のリージョン間トラフィック費用が適用されます。リージョン間の下り(外向き)ネットワーク料金については、ネットワーク料金をご覧ください。GKE クラスタ 1.16 以降では、グローバル アクセスはベータ版として提供されています。1.17.9-gke.600 以降では一般提供されています。
オンプレミスのクライアントは、グローバル アクセスにより、どのリージョンでも Cloud VPN または Cloud Interconnect(VLAN)を使用してロードバランサにアクセスできます。詳細については、Cloud VPN と Cloud Interconnect の使用をご覧ください。
共有 IP
内部 TCP / UDP ロードバランサでは、複数の転送ルール間で仮想 IP アドレスを共有できます。これは、同じ IP で同時使用のポート数を拡張する場合や、同じ IP で UDP トラフィックと TCP トラフィックを受け入れる場合に便利です。IP アドレスあたり最大 50 個の公開ポートが許可されます。共有 IP は、内部 LoadBalancer Service のある GKE クラスタでネイティブにサポートされます。デプロイ時に、Service の loadBalancerIP
フィールドを使用して、Service 間で共有する IP を指定します。
制限事項
複数のロードバランサの共有 IP には、次のような制限と機能があります。
- 各 Service(または転送ルール)に最大で 5 個のポートを設定できます。
- IP アドレスを共有できるのは最大 10 個の Services(転送ルール)です。このため、共有 IP あたり最大で 50 個のポートを設定できます。
- プロトコル / ポートタプルは、同じ IP を共有する Service 間で重複させることはできません。
- 同じ共有 IP では TCP 専用と UDP 専用の Service の組み合わせがサポートされていますが、同じ Service で TCP ポートと UDP ポートの両方を公開することはできません。
共有 IP の有効化
内部 LoadBalancer Service で共通の IP を共有するには、次の操作を行います。
--purpose SHARED_LOADBALANCER_VIP
を使用して、静的内部 IP を作成します。共有を可能にするために、IP アドレスの作成が必要です。共有 VPC で静的内部 IP アドレスを作成する場合は、IP アドレスを使用するインスタンスと同じサービス プロジェクトに IP アドレスを作成する必要があります。これは、IP アドレスの値が共有 VPC ネットワークの選択された共有サブネット内の利用可能な IP の範囲から取得されたものだとしても、同様です。詳細については、共有 VPC のプロビジョニングのページで静的内部 IP の予約をご覧ください。この静的 IP を
loadBalancerIP
フィールドに指定して、最大 10 個の内部 LoadBalancer Service をデプロイします。内部 TCP / UDP ロードバランサは、GKE サービス コントローラによって調整され、同じフロントエンド IP を使用してデプロイします。
次の例は、同じ内部ロードバランサの IP で複数の TCP ポートと UDP ポートをサポートする方法を示しています。
GKE クラスタと同じリージョンに静的 IP を作成します。サブネットはロードバランサが使用するサブネットと同じにする必要があります。デフォルトは、GKE クラスタノードの IP によって使用されるサブネットです。
クラスタと VPC ネットワークが同じプロジェクト内にある場合:
gcloud compute addresses create IP_ADDR_NAME \ --project=PROJECT_ID \ --subnet=SUBNET \ --addresses=IP_ADDRESS \ --region=COMPUTE_REGION \ --purpose=SHARED_LOADBALANCER_VIP
クラスタが共有 VPC サービス プロジェクトにあるが、ホスト プロジェクトで共有 VPC ネットワークを使用している場合:
gcloud compute addresses create IP_ADDR_NAME \ --project=SERVICE_PROJECT_ID \ --subnet=projects/HOST_PROJECT_ID/regions/REGION/subnetworks/SUBNET \ --addresses=IP_ADDRESS \ --region=COMPUTE_REGION \ --purpose=SHARED_LOADBALANCER_VIP
次のように置き換えます。
IP_ADDR_NAME
: IP アドレス オブジェクトの名前。SERVICE_PROJECT_ID
: サービス プロジェクトの ID。PROJECT_ID
: プロジェクト(単一プロジェクト)の ID。HOST_PROJECT_ID
: 共有 VPC ホスト プロジェクトの ID。COMPUTE_REGION
: 共有サブネットを含むコンピューティング リージョン。IP_ADDRESS
: 選択したサブネットのプライマリ IP アドレス範囲の未使用の内部 IP アドレス。IP アドレスの指定を省略すると、Google Cloud は選択したサブネットのプライマリ IP アドレス範囲から未使用の内部 IP アドレスを選択します。自動的に選択されるアドレスを確認するには、gcloud compute addresses describe
を実行する必要があります。SUBNET
: 共有サブネットの名前。
次の TCP Service の構成を
tcp-service.yaml
というファイルに保存し、クラスタにデプロイします。IP_ADDRESS
を前のステップで選択した IP アドレスに置き換えます。apiVersion: v1 kind: Service metadata: name: tcp-service namespace: default annotations: networking.gke.io/load-balancer-type: "Internal" spec: type: LoadBalancer loadBalancerIP: IP_ADDRESS selector: app: myapp ports: - name: 8001-to-8001 protocol: TCP port: 8001 targetPort: 8001 - name: 8002-to-8002 protocol: TCP port: 8002 targetPort: 8002 - name: 8003-to-8003 protocol: TCP port: 8003 targetPort: 8003 - name: 8004-to-8004 protocol: TCP port: 8004 targetPort: 8004 - name: 8005-to-8005 protocol: TCP port: 8005 targetPort: 8005
この Service 定義をクラスタに適用します。
kubectl apply -f tcp-service.yaml
次の UDP Service 構成を
udp-service.yaml
というファイルに保存し、デプロイします。また、前のステップで指定したIP_ADDRESS
も使用します。apiVersion: v1 kind: Service metadata: name: udp-service namespace: default annotations: networking.gke.io/load-balancer-type: "Internal" spec: type: LoadBalancer loadBalancerIP: IP_ADDRESS selector: app: my-udp-app ports: - name: 9001-to-9001 protocol: UDP port: 9001 targetPort: 9001 - name: 9002-to-9002 protocol: UDP port: 9002 targetPort: 9002
このファイルをクラスタに適用します。
kubectl apply -f udp-service.yaml
ロードバランサ転送ルールのリストを取得して静的 IP をフィルタリングし、VIP がロードバランサ転送ルール間で共有されていることを確認します。これは、UDP と TCP の両方の転送ルールが、共有
IP_ADDRESS
(この例では10.128.2.98
)で 7 つの異なるポートをリッスンしていることを示しています。gcloud compute forwarding-rules list | grep 10.128.2.98 ab4d8205d655f4353a5cff5b224a0dde us-west1 10.128.2.98 UDP us-west1/backendServices/ab4d8205d655f4353a5cff5b224a0dde acd6eeaa00a35419c9530caeb6540435 us-west1 10.128.2.98 TCP us-west1/backendServices/acd6eeaa00a35419c9530caeb6540435
すべてのポート
内部転送ルールは、転送ルールごとに最大 5 つのポート、または、転送ルールですべてのポートを転送するオプションのパラメータ --ports=ALL
をサポートします。
要件
GKE のすべてのポートには、次の要件と制限があります。
--enable-l4-ilb-subsetting
が有効になっている場合にのみサポートされます。- 内部ロードバランサ サービスでのみサポートされています。
- 最大 100 個の連続するポート範囲で任意の数のポートをサポートします。
GKE コントローラは、サービスに存在するポート数が 5 つを超える場合、転送ルールですべてのポートを自動的に有効にします。たとえば、次のサービス マニフェストでは、2 つの連続する範囲で 6 つのポートが構成されています。
apiVersion: v1
kind: Service
metadata:
name: all-ports
annotations:
networking.gke.io/load-balancer-type: "Internal"
spec:
type: LoadBalancer
selector:
app: myapp
ports:
- port: 8081
targetPort: 8081
name: 8081-to-8081
protocol: TCP
- port: 8082
targetPort: 8082
name: 8082-to-8082
protocol: TCP
- port: 8083
targetPort: 8083
name: 8083-to-8083
protocol: TCP
- port: 9001
targetPort: 9001
name: 9001-to-9001
protocol: TCP
- port: 9002
targetPort: 9002
name: 9002-to-9002
protocol: TCP
- port: 9003
targetPort: 9003
name: 9003-to-9003
protocol: TCP
サービスに存在するポート数が 5 つを超えるため、GKE コントローラは転送ルールですべてのポートを有効にします。ただし、GKE コントローラは、サービスで指定されたポートのファイアウォール ポートのみを作成します。他のすべてのルールは、VPC ファイアウォールによってブロックされます。
制限事項
内部 TCP / UDP ロードバランサの制限事項
- Kubernetes バージョン 1.7.4 以降を実行しているクラスタでは、自動モードのサブネットだけでなく、カスタムモードのサブネットの内部ロードバランサも使用できます。
- Kubernetes バージョン 1.7.X 以降を実行しているクラスタは、
--purpose
フラグをSHARED_LOADBALANCER_VIP
に設定した予約済み IP アドレスを作成した場合、内部 TCP / UDP ロードバランサに対する予約済み IP アドレスの使用をサポートします。詳しい手順については、共有 IP の有効化をご覧ください。GKE は、Service がその目的で内部 IP アドレスを参照する場合にのみ、内部 TCP / UDP ロードバランサの IP アドレスを保持します。それ以外の場合、Service が更新されるときに(ポートが変更された場合など)、GKE がロードバランサの IP アドレス(spec.loadBalancerIP
)を変更することがあります。 - ロードバランサの IP アドレスが変更されても(前のポイントを参照)、
spec.clusterIP
は一定に保たれます。
内部 UDP ロードバランサの制限事項
- 内部 UDP ロードバランサは、
sessionAffinity: ClientIP
の使用をサポートしていません。
上限
type: LoadBalancer
の Kubernetes Service と networking.gke.io/load-balancer-type: Internal
アノテーションを使用すると、Kubernetes Service を対象にする内部ロードバランサが作成されます。このような Service の数は、VPC ネットワークで作成できる内部転送ルールの数によって制限されます。詳細については、ネットワークごとの制限をご覧ください。
内部 TCP / UDP ロードバランサを含む GKE クラスタの最大ノード数は、externalTrafficPolicy
の値によって異なります。
externalTrafficPolicy: Cluster
: 内部 TCP / UDP ロードバランサのバックエンドは、ランダムに選択された最大 250 個のノードを使用します。クラスタのノード数が 250 より多い場合、ロードバランサのすべてのトラフィックは 250 のノードからクラスタに入り、ランダムに選択された Pod に転送されます。250 を超えるノードでは、このモードの使用はおすすめしません。externalTrafficPolicy: Local
: 内部 TCP / UDP ロードバランサのバックエンドは、ランダムに選択された最大 250 個のノードを使用します。選択した 250 個のどのノードでも内部 TCP / UDP ロードバランサ サービスのバックエンド Pod が実行されない場合、LoadBalancer
IP への接続は失敗します。250 を超えるノードでは、このモードの使用はサポートされていません。
この制限を削除するには、内部ロードバランサのサブセット設定を有効にします。
VPC の上限の詳細については、割り当てと上限をご覧ください。
既知の問題
10 分ごとに接続タイムアウトする
サブセットを使用して作成した内部 LoadBalancer Service では、約 10 分ごとにトラフィックが中断されることがあります。このバグは次のバージョンで修正されています。
- 1.18.19-gke.1700 以降
- 1.19.10-gke.1000 以降
- 1.20.6-gke.1000 以降
スタンダード ティアでのロードバランサの作成でエラーが発生する
プロジェクトのデフォルト ネットワーク階層がスタンダードに設定されているプロジェクトで内部 TCP / UDP ロードバランサを作成すると、次のエラー メッセージが表示されます。
Error syncing load balancer: failed to ensure load balancer: googleapi: Error 400: STANDARD network tier (the project's default network tier) is not supported: Network tier other than PREMIUM is not supported for loadBalancingScheme=INTERNAL., badRequest
1.23.3-gke.900 より前の GKE バージョンでこの問題を解決するには、プロジェクトのデフォルト ネットワーク階層を Premium に構成します。
この問題は、GKE バージョン 1.23.3-gke.900 以降で解決されています。GKE コントローラは、プロジェクトのデフォルト ネットワーク階層がスタンダードに設定されていても、Premium ネットワーク階層で内部 TCP/UDP ロードバランサを作成します。
トラブルシューティング
サービスのサブセットのノードのリストを確認するには、次のコマンドを使用します。
gcloud compute network-endpoint-groups list-network-endpoints NEG_NAME \
--zone=COMPUTE_ZONE
次のように置き換えます。
NEG_NAME
: GKE コントローラによって作成されたネットワーク エンドポイント グループの名前。COMPUTE_ZONE
: 動作対象のネットワーク エンドポイント グループのコンピューティング ゾーン。
内部 TCP / UDP ロードバランサの正常なノードのリストを確認するには、次のコマンドを使用します。
gcloud compute backend-services get-health SERVICE_NAME \
--region=COMPUTE_REGION
次のように置き換えます。
SERVICE_NAME
: バックエンド サービスの名前。この値は、GKE コントローラによって作成されたネットワーク エンドポイント グループの名前と同じです。COMPUTE_REGION
: 操作するバックエンド サービスのコンピューティング リージョン。
次のステップ
- GKE ネットワークの概要を読む。
- Compute Engine ロードバランサの詳細を確認する。
- VPC ネイティブ クラスタの作成方法について学ぶ。
- IP マスカレード エージェントについて学ぶ。
- 承認済みネットワークの構成について学ぶ。