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

Autopilot Standard

このページでは、Google Kubernetes Engine（GKE）で内部パススルーネットワークロードバランサまたは内部ロードバランサを作成する方法について説明します。外部パススルーネットワークロードバランサを作成する場合は、LoadBalancer タイプの Service を作成する方法をご確認ください。

内部パススルーネットワークロードバランサのサブセット化を使用する

内部パススルーネットワークロードバランサにより、クラスタの VPC ネットワーク内のクライアントと、クラスタの VPC ネットワークに接続されたネットワーク内のクライアントが、クラスタの Service にアクセスできるようになります。クライアントはクラスタ内に配置しておく必要はありません。たとえば、内部 LoadBalancer Service には、クラスタの VPC ネットワークにある仮想マシン（VM）インスタンスからアクセスできます。

GKE のサブセット化の使用

GKE のサブセット化は、インスタンスグループではなく GCE_VM_IP ネットワークエンドポイントグループ（NEG）をバックエンドとして使用するため、内部 LoadBalancer Service のスケーラビリティを向上させます。GKE のサブセット化を有効にすると、GKE は内部 LoadBalancer Service のコンピューティングゾーンごとに 1 つの NEG を作成します。NEG のメンバーエンドポイントは、Service のサービスを提供する Pod を少なくとも 1 つ含むノードの IP アドレスです。GKE のサブセット化の詳細については、ノードのグループ化をご覧ください。

要件と制限事項

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

GKE バージョン 1.18.19-gke.1400 以降では、新規および既存の Standard クラスタの GKE のサブセット化を有効にできます。GKE のサブセット化を有効にすると、無効にすることはできません。

Autopilot クラスタでは GKE のサブセット化が無効になっています。
GKE のサブセット化を使用するには、HttpLoadBalancing アドオンを有効にする必要があります。このアドオンはデフォルトで有効になっています。Autopilot クラスタでは、この必要なアドオンを無効にすることはできません。
ネットワークエンドポイントグループの割り当てが適用されます。Google Cloud は、内部 LoadBalancer Service ごとに、ゾーンあたり 1 つの GCE_VM_IP NEG を作成します。
転送ルール、バックエンドサービス、ヘルスチェックの割り当てが適用されます。詳細については、割り当てと上限をご覧ください。
アノテーションとともに GKE のサブセット化を使用して、複数のロードバランサ（alpha.cloud.google.com/load-balancer-backend-share）間でバックエンドサービスを共有することはできません。
Google Cloud CLI のバージョン 345.0.0 以降が必要です。

始める前に

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

Google Kubernetes Engine API を有効にする。

Google Kubernetes Engine API の有効化

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

新しい Standard クラスタで GKE のサブセット化を有効にする

Google Cloud CLI、Google Cloud コンソール、または Terraform を使用して、GKE のサブセット化を有効にした Standard クラスタを作成できます。GKE のサブセット化を有効にして作成されたクラスタでは、常に GKE のサブセット化が使用されます。

コンソール

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

Google Kubernetes Engine に移動
[ 作成] をクリックします。
必要に応じてクラスタを構成します。
ナビゲーションパネルの [クラスタ] の下の [ネットワーキング] をクリックします。
[L4 内部ロードバランサのサブセット化を有効にする] チェックボックスをオンにします。
[作成] をクリックします。

gcloud

gcloud container clusters create CLUSTER_NAME \
    --cluster-version=VERSION \
    --enable-l4-ilb-subsetting \
    --location=COMPUTE_LOCATION

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

CLUSTER_NAME: 新しいクラスタの名前。
VERSION: GKE バージョン。1.18.19-gke.1400 以降にする必要があります。--release-channel オプションを使用して、リリースチャンネルを選択することもできます。リリースチャンネルには、デフォルトのバージョン 1.18.19-gke.1400 以降が必要です。
COMPUTE_LOCATION: クラスタの Compute Engine のロケーション。

Terraform

Terraform を使用して GKE のサブセットを有効にして Standard クラスタを作成するには、次の例をご覧ください。

resource "google_container_cluster" "default" {
  name               = "gke-standard-regional-cluster"
  location           = "us-central1"
  initial_node_count = 1

  enable_l4_ilb_subsetting = true

  # Set `deletion_protection` to `true` will ensure that one cannot
  # accidentally delete this instance by use of Terraform.
  deletion_protection = false
}

Terraform の使用方法の詳細については、GKE での Terraform のサポートをご覧ください。

既存の Standard クラスタで GKE のサブセット化を有効にする

既存の Standard クラスタに対して GKE のサブセット化を有効にするには、gcloud CLI または Google Cloud コンソールを使用します。GKE のサブセット化を有効にした後、無効にすることはできません。

コンソール

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

Google Kubernetes Engine に移動
クラスタのリストで、変更するクラスタの名前をクリックします。
[ネットワーキング] で、[L4 内部ロードバランサのサブセット化] フィールドの横にある [L4 内部ロードバランサのサブセット化を有効にする] をクリックします。
[L4 内部ロードバランサのサブセット化を有効にする] チェックボックスをオンにします。
[変更を保存] をクリックします。

gcloud

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

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

CLUSTER_NAME: クラスタの名前。

GKE のサブセット化を有効にしても、既存の内部 LoadBalancer Service は中断されません。既存の内部 LoadBalancer Service を移行し、GCE_VM_IP NEG をバックエンドとして使用するバックエンドサービスを使用する場合は、代替 Service マニフェストをデプロイする必要があります。詳細については、LoadBalancer Service のコンセプトドキュメントのノードのグループ化をご覧ください。

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

以下のマニフェストは、サンプルのウェブアプリケーションコンテナイメージを実行する 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
```

内部 LoadBalancer Service を作成する

次の例では、TCP ポート 80 を使用して内部 LoadBalancer Service を作成します。GKE は、転送ルールでポート 80 を使用する内部パススルーネットワークロードバランサをデプロイしますが、ポート 8080 のバックエンド Pod にトラフィックを転送します。

マニフェストを 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: 80
    targetPort: 8080
```
マニフェストには次のものを含める必要があります。
- 内部 LoadBalancer Service の name。この場合は ilb-svc。
- 内部 LoadBalancer Service を要求することを示すアノテーション。GKE バージョン 1.17 以降の場合は、マニフェストの例に示すように、アノテーション networking.gke.io/load-balancer-type: "Internal" を使用します。それより前のバージョンの場合は、代わりに cloud.google.com/load-balancer-type: "Internal" を使用してください。
- type: LoadBalancer。
- spec: selector フィールド。Service が対象にする Pod を指定します（例: app: hello）。
- ポート情報:
  - port は、内部パススルーネットワークロードバランサの転送ルールがパケットを受信する宛先ポートを表します。
  - targetPort は、サービスを提供する各 Pod で定義された containerPort と一致する必要があります。
  - port と targetPort の値を同じにする必要はありません。ノードは常に宛先 NAT を実行し、宛先ロードバランサの転送ルールの IP アドレスと port を宛先 Pod の IP アドレスと targetPort に変更します。詳細については、LoadBalancer Service のコンセプトドキュメントのノードでの宛先ネットワークアドレス変換をご覧ください。
マニフェストには次の対象を含めることができます。
- spec.ipFamilyPolicy と ipFamilies は、GKE が IP アドレスを Service に割り振る方法を定義します。GKE は、シングルスタック（IPv4 のみまたは IPv6 のみ）またはデュアルスタックの IP LoadBalancer Service をサポートしています。デュアルスタック LoadBalancer Service は、2 つの個別の内部パススルーネットワークロードバランサの転送ルール（IPv4 トラフィック用と IPv6 トラフィック用）で実装されます。GKE デュアルスタック LoadBalancer Service は、バージョン 1.29 以降で使用できます。詳細については、IPv4 / IPv6 デュアルスタック Service をご覧ください。
詳細については、LoadBalancer 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":["ZONE_NAME","ZONE_NAME","ZONE_NAME"]}'
    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":80,"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: 80
    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 というラベルを持つ Pod は、この Service 用のサービスを提供する Pod です。これらの Pod は、内部パススルーネットワークロードバランサによって転送されたパケットを受信します。
クライアントは、この loadBalancer IP アドレスと Service マニフェストの port フィールドに指定された TCP 宛先ポートを使用して Service を呼び出します。ノードで受信されたパケットが転送される仕組みの詳細については、パケット処理をご覧ください。
GKE が Service に nodePort を割り当てました。この例では、ポート 30521 が割り当てられています。nodePort は、内部パススルーネットワークロードバランサとは関係ありません。

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":["ZONE_NAME"]}
```
レスポンスは、GKE が k8s2-knlc4c77-default-ilb-svc-ua5ugas0 という名前のネットワークエンドポイントグループを作成したことを示します。このアノテーションは、GKE のサブセット化を使用する LoadBalancer タイプの Service に存在し、GKE のサブセット化を使用しない Service には存在しません。

内部パススルーネットワークロードバランサのコンポーネントを確認する

内部 LoadBalancer Service を作成するセクションに記載されている例では、内部パススルーネットワークロードバランサの転送ルールの IP アドレスは 10.128.15.245 です。Google Cloud CLI を使用すると、この転送ルールがクラスタのプロジェクトの転送ルールのリストに含まれていることを確認できます。

gcloud compute forwarding-rules list --filter="loadBalancingScheme=INTERNAL"

出力には、関連する内部パススルーネットワークロードバランサの転送ルール、その IP アドレス、転送ルールで参照されるバックエンドサービス（この例では k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r）が含まれます。

NAME                          ... IP_ADDRESS  ... TARGET
...
k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r   10.128.15.245   ZONE_NAME/backendServices/k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r

Google Cloud CLI を使用して、ロードバランサのバックエンドサービスの説明を取得できます。

gcloud compute backend-services describe k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r --region=COMPUTE_REGION

COMPUTE_REGION は、バックエンドサービスのコンピューティングリージョンに置き換えます。

出力には、1 つまたは複数の Service のバックエンド GCE_VM_IP NEG（この例では k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r）が含まれます。

backends:
- balancingMode: CONNECTION
  group: .../ZONE_NAME/networkEndpointGroups/k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
...
kind: compute#backendService
loadBalancingScheme: INTERNAL
name: aae3e263abe0911e9b32a42010a80008
...

サービスのサブセットのノードのリストを確認するには、次のコマンドを使用します。

gcloud compute network-endpoint-groups list-network-endpoints NEG_NAME \
    --zone=COMPUTE_ZONE

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

NEG_NAME: GKE コントローラによって作成されたネットワークエンドポイントグループの名前。
COMPUTE_ZONE: 動作対象のネットワークエンドポイントグループのコンピューティングゾーン。

内部パススルーネットワークロードバランサの正常なノードのリストを確認するには、次のコマンドを使用します。

gcloud compute backend-services get-health SERVICE_NAME \
    --region=COMPUTE_REGION

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

SERVICE_NAME: バックエンドサービスの名前。この値は、GKE コントローラによって作成されたネットワークエンドポイントグループの名前と同じです。
COMPUTE_REGION: 操作するバックエンドサービスのコンピューティングリージョン。

内部パススルーネットワークロードバランサへの接続をテストする

クラスタと同じ VPC ネットワークとリージョン内の VM インスタンスに SSH で接続し、次のコマンドを実行します。

curl LOAD_BALANCER_IP:80

LOAD_BALANCER_IP は、ロードバランサの転送ルールの IP アドレスに置き換えます。

レスポンスには ilb-deployment の出力が含まれます。

Hello, world!
Version: 1.0.0
Hostname: ilb-deployment-77b45987f7-pw54n

内部パススルーネットワークロードバランサには、同じ VPC ネットワーク（または接続されたネットワーク）内でのみアクセスできます。デフォルトでは、ロードバランサの転送ルールはグローバルアクセスを無効にしているため、クライアント VM、Cloud VPN トンネル、または Cloud Interconnect アタッチメント（VLAN）は、内部パススルーネットワークロードバランサと同じリージョンに配置する必要があります。すべてのリージョンのクライアントをサポートするには、Service マニフェストにグローバルアクセスアノテーションを含めることで、ロードバランサの転送ルールでグローバルアクセスを有効にします。

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

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] に移動
削除するサービスを選択して、[ 削除] をクリックします。
確認のメッセージが表示されたら、[削除] をクリックします。

共有 IP

内部パススルーネットワークロードバランサを使用すると、複数の転送ルール間で仮想 IP アドレスを共有できます。これは、同じ IP で同時使用のポート数を拡張する場合や、同じ IP で UDP トラフィックと TCP トラフィックを受け入れる場合に便利です。IP アドレスあたり最大 50 個の公開ポートが許可されます。共有 IP は、内部 LoadBalancer Service のある GKE クラスタでネイティブにサポートされます。デプロイ時に、Service の loadBalancerIP フィールドを使用して、Service 間で共有する IP を指定します。

制限事項

複数のロードバランサの共有 IP には、次のような制限と機能があります。

各 Service（または転送ルール）に最大で 5 個のポートを設定できます。
IP アドレスを共有できるのは最大 10 個の Services（転送ルール）です。このため、共有 IP あたり最大で 50 個のポートを設定できます。
同じ IP アドレスを共有する転送ルールはそれぞれ、固有のプロトコルとポートの組み合わせを使用する必要があります。そのため、内部 LoadBalancer 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 をデプロイします。内部パススルーネットワークロードバランサは、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/COMPUTE_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
```

制限事項

内部パススルーネットワークロードバランサの制限事項

Kubernetes バージョン 1.7.4 以降を実行しているクラスタでは、自動モードのサブネットだけでなく、カスタムモードのサブネットの内部ロードバランサも使用できます。
Kubernetes バージョン 1.7.X 以降を実行しているクラスタは、--purpose フラグを SHARED_LOADBALANCER_VIP に設定した予約済み IP アドレスを作成した場合、内部パススルーネットワークロードバランサに対する予約済み IP アドレスの使用をサポートします。詳しい手順については、共有 IP の有効化をご覧ください。GKE は、Service がその目的で内部 IP アドレスを参照する場合にのみ、内部パススルーネットワークロードバランサの IP アドレスを保持します。それ以外の場合、Service が更新されるときに（ポートが変更された場合など）、GKE がロードバランサの IP アドレス（spec.loadBalancerIP）を変更することがあります。
ロードバランサの IP アドレスが変更されても（前のポイントを参照）、spec.clusterIP は一定に保たれます。

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

内部 UDP ロードバランサは、sessionAffinity: ClientIP の使用をサポートしていません。

既知の問題

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

サブセットを使用して作成した内部 LoadBalancer Service では、約 10 分ごとにトラフィックが中断されることがあります。このバグは次のバージョンで修正されています。

1.18.19-gke.1700 以降
1.19.10-gke.1000 以降
1.20.6-gke.1000 以降

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

プロジェクトのデフォルトネットワーク階層がスタンダードに設定されているプロジェクトで内部パススルーネットワークロードバランサを作成すると、次のエラーメッセージが表示されます。

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 バージョンでこの問題を解決するには、プロジェクトのデフォルトネットワーク階層をプレミアムに構成します。

この問題は、GKE のサブセット化が有効になっている GKE バージョン 1.23.3-gke.900 以降で解決されています。

GKE コントローラは、プロジェクトのデフォルトネットワーク階層がスタンダードに設定されていても、プレミアムネットワーク階層で内部パススルーネットワークロードバランサを作成します。

次のステップ

IP マスカレードエージェントについて学ぶ。

承認済みネットワークの構成について学ぶ。

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

内部パススルー ネットワーク ロードバランサのサブセット化を使用する

GKE のサブセット化の使用

要件と制限事項

始める前に

新しい Standard クラスタで GKE のサブセット化を有効にする

コンソール

gcloud

Terraform

既存の Standard クラスタで GKE のサブセット化を有効にする

コンソール

gcloud

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

内部 LoadBalancer Service を作成する

内部パススルー ネットワーク ロードバランサのコンポーネントを確認する

内部パススルー ネットワーク ロードバランサへの接続をテストする

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

kubectl

Deployment を削除する

Service を削除する

Console

Deployment を削除する

Service を削除する

共有 IP

制限事項

共有 IP の有効化

制限事項

内部パススルー ネットワーク ロードバランサの制限事項

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

既知の問題

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

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

次のステップ

内部パススルーネットワークロードバランサのサブセット化を使用する

内部パススルーネットワークロードバランサのコンポーネントを確認する

内部パススルーネットワークロードバランサへの接続をテストする

内部パススルーネットワークロードバランサの制限事項

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