マルチネットワーク LoadBalancer Service をデプロイする

Autopilot Standard

このドキュメントでは、GKE で外部パススルー ネットワーク ロードバランサと内部パススルー ネットワーク ロードバランサ のリソースを作成して、マルチネットワーク Pod を内部クライアントまたは外部クライアントに公開する方法について説明します。 Google Cloud マルチネットワーク LoadBalancer Service の必要な構成、機能、制限事項について説明します。

ワークロードを複数の VPC ネットワークに接続する場合は、LoadBalancer タイプの Kubernetes Service を使用して、特定のセカンダリ ネットワーク上の Pod にトラフィックをルーティングします。Service を作成すると、GKE はパススルー ネットワーク ロードバランサを作成して、このトラフィックを管理します。

GKE のマルチネットワーキングの詳細については、Pod のマルチネットワーク サポートについてをご覧ください。

マルチネットワーク LoadBalancer Service の仕組み

マルチネットワーク ワークロードを公開するには、type: LoadBalancer の Service を作成します。 Service には、セカンダリ インターフェースのネットワークに基づいて Pod をターゲットとする特別なセレクタを含める必要があります。内部ロードバランサまたは外部ロードバランサを作成するかどうかを指定するアノテーションを追加します。

セレクタの networking.gke.io/network ラベルは、ネットワークでエンドポイントをフィルタします。このラベルにより、ロードバランサは指定されたネットワークに接続されている Pod インターフェースにのみトラフィックを送信します。

制限事項

マルチネットワーク ロードバランサには次の制限があります。

• externalTrafficPolicy: Cluster を使用する Service はサポートされていません。
• hostNetwork Pod をターゲットとする Service はサポートされていません。
• IPv6 とデュアルスタック ネットワーキングはサポートされていません。
• 既存の Service のネットワークは変更できません。
• レイヤ 3 ネットワークのみがサポートされています。
• ターゲット プールまたはインスタンス グループのバックエンドに基づくロードバランサはサポートされていません。
• ClusterIP Service と NodePort Service は、セカンダリ（デフォルト以外）のネットワークではサポートされていません。

始める前に

始める前に、次のタスクを完了します。

1. Pod のマルチネットワーク サポートを設定する の手順に沿って VPC ネットワークを準備し、追加のネットワークを使用して GKE クラスタを作成します。
2. クラスタでレイヤ 4 内部ロードバランサのサブセット化が有効になっていることを確認します。この機能を有効にするには、クラスタの作成または更新時に --enable-l4-ilb-subsetting フラグを使用します。
3. クラスタで GKE バージョン 1.36 以降が実行されていることを確認します。

マルチネットワーク Pod をデプロイする

Pod を追加のネットワークに接続するには、networking.gke.io/interfaces アノテーションを使用して Deployment を作成します。このアノテーションは、Pod のネットワークとインターフェースを指定します。

1. 次のマニフェストを web-app-deployment.yaml として保存します。

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: web-app
     labels:
       app: web-app
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: web-app
     template:
       metadata:
         labels:
           app: web-app
         annotations:
           networking.gke.io/default-interface: 'eth1'
           networking.gke.io/interfaces: '[
             {"interfaceName":"eth0","network":"default"},
             {"interfaceName": "eth1","network": "dmz"}
           ]'
   spec:
     containers:
     - name: whereami
       image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1
       ports:
       - containerPort: 8080
   

   このマニフェストは、3 つの Pod を持つ web-app という名前の Deployment を作成します。Pod には 2 つのインターフェースがあります。default ネットワークに接続された eth0 と、dmz ネットワークに接続された eth1 です。networking.gke.io/default-interface アノテーションは、Pod のデフォルト インターフェースとして eth1 を設定します。

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

   kubectl apply -f web-app-deployment.yaml
   

Service にデフォルト以外のインターフェースを使用する場合は、Pod 内でルーティングを構成する必要があります。ルーティングを構成するには、NET_ADMIN 機能を持つ initContainer を Pod 仕様に追加します。

次の例は、eth1 インターフェースのデフォルト ルートを追加する initContainer を示しています。

initContainers:
      - name: init-routes-busybox
        image: busybox
        command: ['sh', '-c', 'ip route add default dev eth1 table 200 && ip rule add from 172.16.1.0/24 table 200']
        securityContext:
          capabilities:
            add: ["NET_ADMIN"]

initContainer コマンドで、172.16.1.0/24 を Pod ネットワークのセカンダリ IP アドレス範囲に置き換えます。

内部 LoadBalancer Service をデプロイする

dmz ネットワークで web-app Deployment を公開するには、内部 LoadBalancer Service を作成します。

1. 次のマニフェストを internal-lb-service.yaml として保存します。

   apiVersion: v1
   kind: Service
   metadata:
     name: web-app-internal-lb
     namespace: default
     annotations:
       networking.gke.io/load-balancer-type: "Internal"
   spec:
     externalTrafficPolicy: Local
     ports:
     -   port: 80
       protocol: TCP
       targetPort: 8080
     selector:
       networking.gke.io/network: dmz
       app: web-app
     type: LoadBalancer
   

   このマニフェストは、次のプロパティを持つ Service を作成します。

   • networking.gke.io/load-balancer-type: "Internal": 内部パススルー ネットワーク ロードバランサを指定します。
   • selector: dmz ネットワークに接続されているラベル app: web-app を持つ Pod を選択します。

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

   kubectl apply -f internal-lb-service.yaml
   

外部 LoadBalancer Service をデプロイする

web-app Deployment を外部クライアントに公開するには、外部 LoadBalancer Service を作成します。

1. 次のマニフェストを external-lb-service.yaml として保存します。

   apiVersion: v1
   kind: Service
   metadata:
     name: web-app-external-lb
     namespace: default
     annotations:
       cloud.google.com/l4-rbs: "enabled"
   spec:
     externalTrafficPolicy: Local
     ports:
     -   port: 80
       protocol: TCP
       targetPort: 8080
     selector:
       networking.gke.io/network: dmz
       app: web-app
     type: LoadBalancer
   

   このマニフェストは、次のプロパティを持つ Service を作成します。

   • cloud.google.com/l4-rbs: "enabled": バックエンド サービスベースの 外部パススルー ネットワーク ロードバランサを指定します。
   • selector: dmz ネットワークに接続されているラベル app: web-app を持つ Pod を選択します。

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

   kubectl apply -f external-lb-service.yaml
   

Service を確認する

Service をデプロイしたら、ロードバランサが作成され、正しく構成されていることを確認します。

1. Service のステータスを確認します。

   kubectl get services
   

   出力は次のようになります。

   NAME                  TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)        AGE
   web-app-external-lb   LoadBalancer   10.8.47.77    35.239.57.231   80:31550/TCP   5m
   web-app-internal-lb   LoadBalancer   10.8.43.251   172.16.0.43     80:32628/TCP   6m
   kubernetes            ClusterIP      10.8.32.1     <none>          443/TCP        43h
   

   内部ロードバランサの EXTERNAL-IP アドレスは dmz ネットワークに属します。

2. プロジェクト内の転送ルールを一覧表示します。

   gcloud compute forwarding-rules list
   

   出力は次のようになります。

   NAME                                                   REGION        IP_ADDRESS     IP_PROTOCOL  TARGET
   af901673cc0f24907a6aa8c3ce4afc21                       us-central1   35.239.57.231  TCP          us-central1/backendServices/k8s2-xhvzqabw-default-web-app-external-lb-u4xbs4ot
   k8s2-tcp-xhvzqabw-default-web-app-internal-lb-vp1x1d6a us-central1   172.16.0.43    TCP          us-central1/backendServices/k8s2-xhvzqabw-default-web-app-internal-lb-vp1x1d6a
   

3. 内部ロードバランサの転送ルールを記述して、正しいネットワークに接続されていることを確認します。

   gcloud compute forwarding-rules describe k8s2-tcp-xhvzqabw-default-web-app-internal-lb-vp1x1d6a --region=$REGION
   

   REGION はクラスタのリージョンに置き換えます。

   出力は次のようになります。network フィールドと subnetwork フィールドが dmz ネットワークの詳細と一致していることを確認します。

   IPAddress: 172.16.0.43
   IPProtocol: TCP
   ...
   loadBalancingScheme: INTERNAL
   name: k8s2-tcp-xhvzqabw-default-web-app-internal-lb-vp1x1d6a
   network: https://www.googleapis.com/compute/v1/projects/projectId/global/networks/dmz-vpc
   ...
   subnetwork: https://www.googleapis.com/compute/v1/projects/projectId/regions/us-central1/subnetworks/dmz-subnet
   

ロードバランサをテストする

1. 外部ロードバランサをテストするには、その外部 IP アドレスにリクエストを送信します。

   curl EXTERNAL_LB_IP:80
   

   EXTERNAL_LB_IP は、web-app-external-lb Service の外部 IP アドレスに置き換えます。

2. 内部ロードバランサをテストするには、ロードバランサと同じ VPC 内のホストからリクエストを送信します。

   curl INTERNAL_LB_IP:80
   

   INTERNAL_LB_IP は、web-app-internal-lb Service の IP アドレスに置き換えます。

トラブルシューティング

このセクションでは、マルチネットワーク ロードバランサに関する問題のトラブルシューティング方法について説明します。

ロードバランサの作成に失敗する

ロードバランサの作成に失敗した場合は、Service イベントでエラー メッセージを確認します。

kubectl describe service SERVICE_NAME

SERVICE_NAME は Service の名前に置き換えます。

network some-other-network does not exist などのエラー メッセージは、Service セレクタで指定されたネットワークがクラスタで定義されていないことを示します。ネットワークが存在することを確認します。

kubectl get networks

ネットワークが存在する場合は、Network オブジェクトが有効な GKENetworkParamSet リソースを正しく参照していることを確認します。構成エラーを確認するには、Network リソースのステータスを調べます。

kubectl get networks NETWORK_NAME -o yaml

NETWORK_NAME はネットワーク名に置き換えてください。

有効な構成では、ParamsReady 条件と Ready 条件の両方が True になります。ParamsReady が True でない場合は、parametersRef in the Network 仕様が既存の GKENetworkParamSet リソースの名前、種類、グループと正しく一致していることを確認します。

Network リソースが正しくても準備ができていない場合は、参照されている GKENetworkParamSet のステータスで、サブネットの欠落などのエラーを確認します。

kubectl get gkenetworkparamsets GNP_NAME -o yaml

GNP_NAME は GKENetworkParamSet の名前に置き換えます。

ロードバランサにバックエンドがない

ロードバランサがプロビジョニングされているが、正常なバックエンドがない場合は、次の操作を行います。

1. Service が使用するネットワークにネットワーク インターフェースを持つノードプールが存在することを確認します。
2. Service によって選択された Pod が実行されていることを確認します。

3. Service のエンドポイントを確認します。

   kubectl describe endpointslice -l kubernetes.io/service-name=SERVICE_NAME
   

   multinet-endpointslice-controller.gke.io コントローラは、マルチネットワーク エンドポイントを作成します。EndpointSlice にリストされている Pod の IP アドレスは、Service が使用するネットワークに属します。EndpointSlice にエンドポイントがない場合は、Service セレクタのラベルが実行中の Pod と一致し、ネットワーク セレクタが Pod のネットワークと一致していることを確認します。

次のステップ

• Pod の マルチネットワーク サポート について学習する。
• マルチネットワーク Serviceについて学習する。