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 ロードバランサを構成できます。

サブセット設定は、クラスタの作成時と既存のクラスタを編集する際に有効にできます。

要件と制限事項

GKE のサブセット化には次の要件と制限があります。

GKE バージョン 1.18.19-gke.1400 以降では、新規および既存のクラスタのサブセット化を有効にできます。
クラスタで HttpLoadBalancing アドオンが有効になっている必要があります。このアドオンはデフォルトで有効になっています。このアドオンを無効にしているクラスタでは、サブセット化を使用できません。HttpLoadBalancing アドオンを有効にしてカスタム Ingress コントローラを実行する方法については、HttpLoadBalancing アドオンを有効にしてカスタム Ingress コントローラを使用するをご覧ください。
Google Cloud CLI バージョン 345.0.0 以降が必要です。
ネットワークエンドポイントグループの割り当てが適用されます。Google Cloud は、内部 TCP / UDP ロードバランサにつき、ゾーンごとに 1 つの NEG を作成します。
転送ルール、バックエンドサービス、その他のネットワークリソースの割り当てが適用されます。
クラスタで一度有効にしたサブセット化を無効にすることはできません。
バックエンドサービスを共有するためのアノテーションにサブセット設定（alpha.cloud.google.com/load-balancer-backend-share）を使用することはできません。

準備

作業を始める前に、次のことを確認してください。

Google Kubernetes Engine API を有効にします。

Google Kubernetes Engine API を有効にする

このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化します。
注: 既存の gcloud CLI のインストールでは、必ず compute/region と compute/zone のプロパティを設定してください。デフォルトのロケーションを設定することで、gcloud CLI のエラー（One of [--zone, --region] must be supplied: Please specify location など）を防止できます。

新しいクラスタで内部ロードバランサのサブセット化を有効にする

内部ロードバランサのサブセット化を有効にしたクラスタを作成するには、Google Cloud CLI または Google Cloud コンソールを使用します。

Console

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

Google Kubernetes Engine に移動
[ 作成] をクリックします。
必要に応じてクラスタを構成します。
ナビゲーションパネルの [クラスタ] の下の [ネットワーキング] をクリックします。
[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 のリージョン。

既存のクラスタで内部ロードバランサのサブセット化を有効にする

既存のクラスタの内部ロードバランササブセット化を有効にするには、gcloud CLI または Google Cloud コンソールを使用します。クラスタで一度有効にした内部ロードバランサのサブセット化は無効にできません。

Console

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

Google Kubernetes Engine に移動
クラスタのリストで、変更するクラスタの名前をクリックします。
[ネットワーキング] で、[L4 内部ロードバランサのサブセット化] フィールドの横にある [L4 内部ロードバランサのサブセット化を有効にする] をクリックします。
[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 には、コンテナがリッスンするポートを指定します。
マニフェストをクラスタに適用します。
```
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 は無関係です。内部ロードバランサには関係ありません。

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: 2.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 Horizontal Pod Autoscaler associated with selected Deployment] チェックボックスをオンにして、[削除] をクリックします。

Service を削除する

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

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

[Service と Ingress] に移動
削除するサービスを選択して、[ 削除] をクリックします。
確認のメッセージが表示されたら、[削除] をクリックします。

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: 操作するバックエンドサービスのコンピューティングリージョン。

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

内部 TCP / UDP ロードバランサのサブセット化を使用する

要件と制限事項

準備

新しいクラスタで内部ロードバランサのサブセット化を有効にする

Console

gcloud

既存のクラスタで内部ロードバランサのサブセット化を有効にする

Console

gcloud

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

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

ロードバランサの転送ルールを表示する

内部 TCP ロードバランサを確認する

内部 TCP ロードバランサのリソースを削除する

kubectl

Deployment を削除する

Service を削除する

Console

Deployment を削除する

Service を削除する

Service のパラメータ

ロードバランサのサブネット

グローバル アクセス

共有 IP

制限事項

共有 IP の有効化

すべてのポート

要件

制限事項

内部 TCP / UDP ロードバランサの制限事項

内部 UDP ロードバランサの制限事項

上限

既知の問題

10 分ごとに接続タイムアウトする

スタンダード ティアでのロードバランサの作成でエラーが発生する

トラブルシューティング

次のステップ

グローバルアクセス

スタンダードティアでのロードバランサの作成でエラーが発生する