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

このページでは、内部パススルー ネットワーク ロードバランサを構築する内部 LoadBalancer Service をデプロイする方法について説明します。このページを読む前に、次のことをよく理解しておいてください。

内部パススルー ネットワーク ロードバランサの一般的な詳細については、内部パススルー ネットワーク ロードバランサの概要をご覧ください。

始める前に

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

  • Google Kubernetes Engine API を有効にする。
    • Google Kubernetes Engine API を有効化
  • このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。gcloud CLI をインストール済みの場合は、gcloud components update コマンドを実行して最新のバージョンを取得します。以前のバージョンの gcloud CLI では、このドキュメントのコマンドを実行できない場合があります。
  • すでに Autopilot クラスタまたは Standard クラスタが存在していることを確認する。新しいクラスタを作成するには、Autopilot クラスタの作成をご覧ください。

要件

  • このチュートリアルでは、spec.loadBalancerClass を使用して、GCE_VM_IP NEG バックエンドを使用する内部パススルー ネットワーク ロードバランサを作成します。このチュートリアルでは、GKE バージョン 1.33.1-gke.1779000 以降が必要です。これは、spec.loadBalancerClass に GKE バージョン 1.33.1-gke.1779000 以降が必要なためです。

  • ゾーン アフィニティには、GKE バージョン 1.33.3-gke.1392000 以降が必要です。

  • クラスタで GKE のサブセット化が有効になっている必要があります。

    • GKE サブセットは、バージョン 1.36 以降を実行するクラスタではデフォルトで有効になっています。これらのバージョンでは、クラスタのサブセット化フラグの値に関係なく、サブセット化が有効になっています。

    • バージョン 1.36 より前のサポートされている GKE バージョンでは、GKE サブセット化を明示的に有効にする必要があります。GKE のサブセット化は、新しいクラスタの作成時または既存のクラスタの更新時に有効にできます。GKE のサブセット化を有効にすると、無効にすることはできません。詳細については、GKE サブセッティングを確認して有効にするをご覧ください。

  • クラスタのバージョンが 1.36 より前の場合は、クラスタで HttpLoadBalancing アドオンが有効になっている必要があります。このアドオンはデフォルトで有効になっています。

  • 内部 LoadBalancer Service で Cloud Logging を有効にするには、GKE クラスタでバージョン 1.36.0-gke.2459000 以降を使用する必要があります。

GKE のサブセット化を確認して有効にする

GKE のサブセット化が有効になっていることを確認します。

  • GKE バージョン 1.36 以降では、GKE のサブセット化は常に有効になっています。

  • GKE バージョン 1.18.19-gke.1400 以降、GKE バージョン 1.36 より前の GKE バージョンを実行している新規および既存の Standard クラスタと Autopilot クラスタで、GKE サブセット化を手動で有効にできます。GKE のサブセット化を有効にした後、無効にすることはできません。

GKE のサブセット化が重要な理由については、内部 LoadBalancer Service の特別な考慮事項をご覧ください。

GKE サブセッティングが有効になっているかどうかを確認するには、次のコマンドを実行します。

gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format="get(currentMasterVersion, networkConfig.enableL4ilbSubsetting)"

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

  • CLUSTER_NAME: クラスタの名前。
  • LOCATION : クラスタのゾーンまたはリージョン。

コマンドの出力には、クラスタのコントロール プレーンのバージョンと、networkConfig.enableL4ilbSubsetting 属性の True または False が表示されます。出力は次のように解釈します。

  • コントロール プレーンのバージョンが 1.36 以降の場合、networkConfig.enableL4ilbSubsetting 属性が True か False かにかかわらず、GKE サブセッティングが有効になります。
  • コントロール プレーンのバージョンが 1.36 より前の場合は、次の操作を行います。
    • True は、GKE のサブセット化が有効になっていることを意味します。
    • False は、GKE のサブセット化が無効になっていることを意味します。

GKE バージョン 1.18.19-gke.1400 以降、GKE バージョン 1.36 より前のバージョンを実行しているクラスタで GKE サブセットを有効にするには、gcloud CLI または Google Cloud コンソールを使用します。

コンソール

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

    Google Kubernetes Engine に移動

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

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

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

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

gcloud

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION
    --enable-l4-ilb-subsetting

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

  • CLUSTER_NAME: クラスタの名前。
  • LOCATION : クラスタのゾーンまたはリージョン。

gcloud CLI、Google Cloud コンソールを使用するか、クラスタをバージョン 1.36 以降にアップグレードして GKE のサブセット化を有効にしても、既存の内部 LoadBalancer Service は変更されません。既存の内部 LoadBalancer Service を移行して GCE_VM_IP NEG バックエンドを使用する場合は、代替 Service マニフェストをデプロイする必要があります。

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

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

内部 LoadBalancer Service を作成する

  1. （省略可）VPC ファイアウォール ルールの自動作成を無効にします。

    GKE は、内部ロードバランサへのトラフィックを許可する VPC ファイアウォール ルールを自動的に作成しますが、VPC ファイアウォール ルールの自動作成を無効にして、ファイアウォール ルールを独自に管理することもできます。VPC ファイアウォール ルールを無効にできるのは、内部 LoadBalancer Service で GKE サブセット化を有効にしている場合のみです。ただし、VPC ファイアウォール ルールの管理は省略可能であり、自動ルールを利用できます。

    VPC ファイアウォール ルールの自動作成を無効にする前に、トラフィックがロードバランサとアプリケーション Pod に到達することを許可する許可ルールを定義してください。

    VPC ファイアウォール ルールの管理の詳細については、ファイアウォール ルールの自動作成を管理するをご覧ください。ファイアウォール ルールの自動作成を無効にする方法については、GKE LoadBalancer Service のユーザー管理ファイアウォール ルールをご覧ください。

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

    1. マニフェストを ilb-svc.yaml として保存します。

      apiVersion: v1
kind: Service
metadata:
  name: ilb-svc
spec:
  type: LoadBalancer
  # Request an internal load balancer.
  loadBalancerClass: networking.gke.io/l4-regional-internal
  # Evenly route external traffic to all endpoints.
  externalTrafficPolicy: Cluster
  # Prioritize routing traffic to endpoints that are in the same zone.
  trafficDistribution: PreferClose
  selector:
    app: ilb-deployment
  # Forward traffic from TCP port 80 to port 8080 in backend Pods.
  ports:
  - name: tcp-port
    protocol: TCP
    port: 80
    targetPort: 8080

      マニフェストには次のものを含める必要があります。

      • 内部 LoadBalancer Service の name。この場合は ilb-svc。
      • 例のマニフェストに示すように、内部 LoadBalancer Service を指定するために networking.gke.io/l4-regional-internal 値に設定された spec.loadBalancerClass フィールド。
      • type: LoadBalancer。
      • spec: selector フィールド。Service が対象にするポッドを指定します。例: 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 をご覧ください。

      • spec.trafficDistribution（プレビュー）: GKE が受信トラフィックをルーティングする方法を定義します。ゾーン アフィニティを有効にするには、このフィールドの値を PreferSameZone に設定します。ゾーン アフィニティとは、GKE がゾーンから発生したトラフィックを同じゾーン内のノードと Pod に転送することを優先することを意味します。そのゾーンに正常な Pod がない場合、トラフィックは別のゾーンに転送されます。1.35.0-gke.1811000 より前のクラスタ バージョンの場合は、代わりに PreferClose を値として使用します。ゾーン アフィニティを使用するには、GKE サブセット化を有効にする必要があります。

      詳細については、LoadBalancer Service のパラメータをご覧ください。

    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":["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
    # Kubernetes automatically allocates a port on the node during the
    # process of implementing a Service of type LoadBalancer.
    nodePort: 30521
    port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    app: ilb-deployment
  sessionAffinity: None
  trafficDistribution: PreferSameZone
  type: LoadBalancer
status:
  # IP address of the load balancer forwarding rule.
  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 は、内部パススルー ネットワーク ロードバランサとは関係ありません。

  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":["ZONE_NAME"]}

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

バックエンド サービスのロギングを有効にする

内部パススルー ネットワーク ロードバランサのログの有効化、無効化、表示を行えます。バックエンド サービスのロギングを有効にするには、GKE サブセット化を有効にする必要があります。

Cloud Logging を構成するには、ロギング設定を指定する L4LBConfig カスタム リソースを作成します。L4LBConfig リソースは、Service マニフェスト内の Kubernetes Service にリンクされています。マニフェストを適用すると、GKE コントローラはバックエンド サービスのロギングを構成します。L4LBConfig リソースを Service にリンクしない場合、コントローラはロギングが無効になっていることを確認し、ロギングを有効にしようとする手動操作をオーバーライドします。

次のフィールドを構成できます。

  • enabled: true に設定すると、この Service のロギングが有効になり、ログが Cloud Logging で使用できるようになります。それ以外の場合、この Service のロギングは無効になります。
  • sampleRate: 0 から 1,000,000（デフォルト）までの値を指定します。0 を設定すると、パケットはまったくロギングされません。1,000,000 を設定すると、すべてのパケットがロギングされます。sampleRate フィールドは省略可能で、enable フィールドの値が true に設定されている場合にのみ関連します。
  • optionalMode: ロードバランサの生成されたログに含めるオプションのメタデータ フィールドを制御します。このフィールドには、次のいずれかの文字列値を指定します。
    • EXCLUDE_ALL_OPTIONAL: optionalMode が指定されていない場合のデフォルト設定。設定すると、オプション フィールドはログに含まれず、最も簡潔なログ形式になります。
    • INCLUDE_ALL_OPTIONAL: 使用可能なすべてのオプション フィールドのロギングを有効にし、最も詳細なログエントリを提供します。
    • CUSTOM: ログに含まれるオプション フィールドのカスタムリストを指定します。CUSTOM モードでは、optionalFields パラメータを使用して、必要なフィールドのカンマ区切りのリストを指定する必要があります。
  • optionalFields: フィールド名のカンマ区切り文字列。生成されたログに含めるオプションのメタデータ フィールドを正確に定義します。このフィールドは、optionalMode が CUSTOM に設定されている場合にのみ使用されます。それ以外の場合は、値は無視されます。

Cloud Logging を構成するには、Service リソースと同じ Namespace に L4LBConfig リソースを作成します。次の L4LBConfig マニフェストの例では、Cloud Logging を有効にし、特定のロードバランサ サービスのサンプルレートをリクエストの 50% に設定します。

  1. 次のマニフェストを svc-l4lb-config.yaml として保存します。

    apiVersion: networking.gke.io/v1
kind: L4LBConfig
metadata:
  name: svc-l4lb-config
  namespace: default
spec:
  logging:
    enabled: true # must be included
    sampleRate: 500000
    optionalMode: "INCLUDE_ALL_OPTIONAL"

  2. L4LBConfig マニフェストをクラスタに適用します。

    kubectl apply -f svc-l4lb-config.yaml

  3. ilb-svc.yaml Service マニフェストに networking.gke.io/l4lb-config アノテーションを追加します。

    apiVersion: v1
kind: Service
metadata:
  name: ilb-svc
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
    networking.gke.io/l4lb-config: "svc-l4lb-config"
spec:
  type: LoadBalancer
  selector:
    app: store
  ports:
    - name: tcp-port
      protocol: TCP
      port: 8080
      targetPort: 8080

  4. Service マニフェストをクラスタに適用します。

    kubectl apply -f ilb-svc.yaml

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

このセクションでは、内部パススルー ネットワーク ロードバランサの主要コンポーネントを確認する方法について説明します。

  • Service が実行されていることを確認します。

    kubectl get service SERVICE_NAME --output yaml

    SERVICE_NAME は、Service マニフェストの名前に置き換えます。

    ゾーン アフィニティを有効にすると、出力に spec.trafficDistribution パラメータが含まれます。このフィールドの値は PreferSameZone に設定されます。クラスタのバージョンが 1.35.0-gke.1811000 より前の場合は、PreferClose に設定されます。

  • 内部パススルー ネットワーク ロードバランサの転送ルールの IP アドレスを確認します。内部 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 は、バックエンド サービスのコンピューティング リージョンに置き換えます。

    ゾーン アフィニティを有効にした場合:

    • networkPassThroughLbTrafficPolicy.zonalAffinity.spillover フィールドは ZONAL_AFFINITY_SPILL_CROSS_ZONE 値に設定する必要があります。
    • networkPassThroughLbTrafficPolicy.zonalAffinity.spilloverRatio フィールドは 0 に設定するか、含めないようにします。

    出力には、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
networkPassThroughLbTrafficPolicy:
  zonalAffinity:
    spillover: ZONAL_AFFINITY_SPILL_CROSS_ZONE
protocol: TCP
...

    ゾーン アフィニティを無効にした場合、networkPassThroughLbTrafficPolicy.zonalAffinity.spillover フィールドは ZONAL_AFFINITY_DISABLED に設定するか、含めないようにする必要があります。クラスタのバージョンが 1.33.3-gke.1392000 より前の場合は、ゾーン アフィニティが自動的に無効になります。

  • サービスのサブセットのノードのリストを確認します。

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

  • Service で Cloud Logging が有効になっていることを確認します。

    kubectl get svc SERVICE_NAME --output yaml

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

    • SERVICE_NAME: Service の名前。

    出力で、Status.Conditions フィールドに Type: LoggingConfigManaged と Reason: Reconciled が含まれていることを確認します。

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

クラスタと同じリージョンで次のコマンドを実行します。

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

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

    [ワークロード] に移動

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

  3. 確認を求められたら、[選択した Deployment に関連付けられている水平 Pod オートスケーラーを削除します] チェックボックスをオンにして、[削除] をクリックします。

Service を削除する

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

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

    [Service と Ingress] に移動

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

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

共有 IP

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

制限事項

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

  • 各転送ルールには最大 5 つのポート（連続または非連続）を設定できます。また、すべてのポートでトラフィックを照合して転送するように構成することもできます。内部 LoadBalancer Service で 6 つ以上のポートが定義されている場合、転送ルールはすべてのポートに一致するように自動的に設定されます。
  • IP アドレスを共有できるのは最大 10 個の Services（転送ルール）です。このため、共有 IP あたり最大で 50 個のポートを設定できます。
  • 同じ IP アドレスを共有する転送ルールはそれぞれ、固有のプロトコルとポートの組み合わせを使用する必要があります。そのため、内部 LoadBalancer 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 をデプロイします。内部パススルー ネットワーク ロードバランサは、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/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: 共有サブネットの名前。

  2. 次の TCP Service の構成を tcp-service.yaml というファイルに保存し、クラスタにデプロイします。IP_ADDRESS を前のステップで選択した IP アドレスに置き換えます。

    apiVersion: v1
kind: Service
metadata:
  name: tcp-service
  namespace: default
spec:
  type: LoadBalancer
  # Request an internal load balancer.
  loadBalancerClass: networking.gke.io/l4-regional-internal
  # Use an IP address that you create.
  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
spec:
  type: LoadBalancer
  # Request an internal load balancer.
  loadBalancerClass: networking.gke.io/l4-regional-internal
  # Use the same IP address that you used for the TCP Service.
  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

既知の問題

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

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

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 のサブセット化が有効になっている GKE バージョン 1.23.3-gke.900 以降で解決されています。

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

次のステップ