内部 TCP / UDP ロードバランサの使用


このページでは、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

  1. Google Cloud コンソールで [Google Kubernetes Engine] ページに移動します。

    Google Kubernetes Engine に移動

  2. [ 作成] をクリックします。

  3. 必要に応じてクラスタを構成します。

  4. ナビゲーション パネルの [クラスタ] の下の [ネットワーキング] をクリックします。

  5. [L4 内部ロードバランサのサブセット化を有効にする] チェックボックスをオンにします。

  6. [作成] をクリックします。

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

  1. Google Cloud コンソールで、Google Kubernetes Engine のページに移動します。

    Google Kubernetes Engine に移動

  2. クラスタのリストで、変更するクラスタの名前をクリックします。

  3. [ネットワーキング] で、[L4 内部ロードバランサのサブセット化] フィールドの横にある [L4 内部ロードバランサのサブセット化を有効にする] をクリックします。

  4. [L4 内部ロードバランサのサブセット化を有効にする] チェックボックスをオンにします。

  5. [変更を保存] をクリックします。

gcloud

gcloud container clusters update CLUSTER_NAME \
    --enable-l4-ilb-subsetting

次のように置き換えます。

  • CLUSTER_NAME: クラスタの名前。

ワークロードをデプロイする

以下のマニフェストは、サンプルのウェブ アプリケーション コンテナ イメージを実行する Deployment を説明しています。

  1. マニフェストを 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
    
  2. マニフェストをクラスタに適用します。

    kubectl apply -f ilb-deployment.yaml
    

内部 TCP ロードバランサを作成する

Service を使用して内部 TCP ロードバランサを作成します。この内部ロードバランサは TCP ポート 8080 に割り当てられています。

  1. マニフェストを 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 には、コンテナがリッスンするポートを指定します。
  2. マニフェストをクラスタに適用します。

    kubectl apply -f ilb-svc.yaml
    
  3. 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 は無関係です。内部ロードバランサには関係ありません。

  4. 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 を削除するには、次の手順を行います。

  1. Google Cloud コンソールの [ワークロード] ページに移動します。

    [ワークロード] に移動

  2. 削除する Deployment を選択して、[ 削除] をクリックします。

  3. 確認を求められたら、[Delete Horizontal Pod Autoscaler associated with selected Deployment] チェックボックスをオンにして、[削除] をクリックします。

Service を削除する

Service を削除するには、次の手順を行います。

  1. Google Cloud コンソールの [Service と Ingress] ページに移動します。

    [Service と Ingress] に移動

  2. 削除するサービスを選択して、[ 削除] をクリックします。

  3. 確認のメッセージが表示されたら、[削除] をクリックします。

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 を共有するには、次の操作を行います。

  1. --purpose SHARED_LOADBALANCER_VIP を使用して、静的内部 IP を作成します。共有を可能にするために、IP アドレスの作成が必要です。共有 VPC で静的内部 IP アドレスを作成する場合は、IP アドレスを使用するインスタンスと同じサービス プロジェクトに IP アドレスを作成する必要があります。これは、IP アドレスの値が共有 VPC ネットワークの選択された共有サブネット内の利用可能な IP の範囲から取得されたものだとしても、同様です。詳細については、共有 VPC のプロビジョニングのページで静的内部 IP の予約をご覧ください。

  2. この静的 IP を loadBalancerIP フィールドに指定して、最大 10 個の内部 LoadBalancer Service をデプロイします。内部 TCP / UDP ロードバランサは、GKE サービス コントローラによって調整され、同じフロントエンド IP を使用してデプロイします。

次の例は、同じ内部ロードバランサの IP で複数の TCP ポートと UDP ポートをサポートする方法を示しています。

  1. 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: 共有サブネットの名前。
  2. 次の 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
    
  3. この Service 定義をクラスタに適用します。

    kubectl apply -f tcp-service.yaml
    
  4. 次の 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
    
  5. このファイルをクラスタに適用します。

    kubectl apply -f udp-service.yaml
    
  6. ロードバランサ転送ルールのリストを取得して静的 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: 操作するバックエンド サービスのコンピューティング リージョン

次のステップ