このページでは、バックエンド サービスベースの外部パススルー ネットワーク ロードバランサを構築する外部 LoadBalancer Service をデプロイする方法について説明します。このページを読む前に、次のことをよく理解しておいてください。
外部パススルー ネットワーク ロードバランサの一般的な詳細については、バックエンド サービスベースの外部パススルー ネットワーク ロードバランサをご覧ください。
始める前に
始める前に、次の作業が完了していることを確認してください。
- Google Kubernetes Engine API を有効にする。 Google Kubernetes Engine API の有効化
- このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、
gcloud components updateを実行して最新のバージョンを取得する。
要件
外部 LoadBalancer Service を作成するには、GKE クラスタでバージョン 1.25.5 以降を使用する必要があります。重み付けされたロード バランシングを使用するには、クラスタでバージョン 1.31.0-gke.1506000 以降を使用する必要があります。
クラスタで
HttpLoadBalancingアドオンが有効になっている必要があります。このアドオンはデフォルトで有効になっています。これにより、クラスタは、バックエンド サービスを使用するロードバランサを管理できます。
クラスタを選択する
新しいクラスタを作成することも、要件を満たす既存のクラスタを選択することもできます。
新しいクラスタを作成する
Autopilot
新しい Autopilot クラスタを作成するには:
gcloud container clusters create-auto CLUSTER_NAME \
--release-channel=RELEASE_CHANNEL \
--cluster-version=VERSION \
--location=COMPUTE_LOCATION
次のように置き換えます。
CLUSTER_NAME: 新しいクラスタの名前。RELEASE_CHANNEL: クラスタの GKE リリース チャンネルの名前。VERSION: クラスタの GKE バージョン。COMPUTE_LOCATION: クラスタの Compute Engine のリージョン。
Standard
新しい Standard クラスタを作成するには:
gcloud container clusters create CLUSTER_NAME \
--release-channel=RELEASE_CHANNEL \
--cluster-version=VERSION \
--location=COMPUTE_LOCATION
次のように置き換えます。
CLUSTER_NAME: 新しいクラスタの名前。RELEASE_CHANNEL: クラスタの GKE リリース チャンネルの名前。VERSION: クラスタの GKE バージョン。COMPUTE_LOCATION: クラスタの Compute Engine のリージョン。
既存のクラスタをアップグレードする
gcloud CLI を使用して既存のクラスタを更新します。
gcloud container clusters upgrade CLUSTER_NAME \
--cluster-version=VERSION \
--master \
--location=COMPUTE_LOCATION
次のように置き換えます。
CLUSTER_NAME: 既存のクラスタの名前。VERSION: クラスタをアップグレードする特定の GKE バージョン。詳細については、コントロール プレーンの手動アップグレードをご覧ください。COMPUTE_LOCATION: クラスタの Compute Engine のリージョン。
サンプル ワークロードをデプロイする
外部 LoadBalancer Service のサービング Pod を提供する次のサンプル ワークロードをデプロイします。
次のサンプル Deployment を
store-deployment.yamlとして保存します。apiVersion: apps/v1 kind: Deployment metadata: name: store spec: replicas: 20 selector: matchLabels: app: store template: metadata: labels: app: store spec: containers: - image: gcr.io/google_containers/echoserver:1.10 imagePullPolicy: Always name: echoserver ports: - name: http containerPort: 8080 readinessProbe: httpGet: path: /healthz port: 8080 scheme: HTTPマニフェストをクラスタに適用します。
kubectl apply -f store-deployment.yamlDeployment に 20 のサービング Pod があることを確認します。
kubectl get pods出力は次のようになります。
NAME READY STATUS RESTARTS AGE store-cdb9bb4d6-s25vw 1/1 Running 0 10s store-cdb9bb4d6-vck6s 1/1 Running 0 10s ....
外部 LoadBalancer Service を作成する
外部 LoadBalancer Service を作成して、サンプル ワークロードを公開します。
次の Service マニフェストを
store-v1-lb-svc.yamlとして保存します。apiVersion: v1 kind: Service metadata: name: store-v1-lb-svc annotations: cloud.google.com/l4-rbs: "enabled" spec: type: LoadBalancer selector: app: store ports: - name: tcp-port protocol: TCP port: 8080 targetPort: 8080マニフェストをクラスタに適用します。
kubectl apply -f store-v1-lb-svc.yaml
このサンプル マニフェストについては、次の点に注意してください。
マニフェストがクラスタに初めて適用されるときに、Service マニフェストに
cloud.google.com/l4-rbs: "enabled"アノテーションを含める必要があります。バックエンド サービスベースの外部パススルー ネットワーク ロードバランサを作成するように GKE に指示します。IPv6 や重み付けロード バランシングなどの機能をサポートするには、バックエンド サービスベースの外部パススルー ネットワーク ロードバランサが必要です。cloud.google.com/l4-rbs: "enabled"アノテーションを既存の外部 LoadBalancer Service のマニフェストに追加した場合（つまり、ロードバランサの作成後）、GKE はアノテーションを無視します。マニフェストにこのアノテーションがない状態で作成された外部 LoadBalancer Service は、ターゲット プールベースの外部パススルー ネットワーク ロードバランサを使用します。ターゲット プールベースの外部パススルー ネットワーク ロードバランサの使用はおすすめしません。
重み付きロード バランシングを有効にする
各ノードに存在するサービング Pod、準備完了 Pod、終了していない Pod の数に基づいて、新しい接続をノードに比例して分散するには、Service マニフェストに networking.gke.io/weighted-load-balancing:
"pods-per-node" アノテーションを追加して、重み付けロード バランシングを有効にします。
networking.gke.io/weighted-load-balancing: "pods-per-node"アノテーションをstore-v1-lb-svc.yamlService マニフェストに追加し、次のようにexternalTrafficPolicy: Localも設定します。apiVersion: v1 kind: Service metadata: name: store-v1-lb-svc annotations: cloud.google.com/l4-rbs: "enabled" networking.gke.io/weighted-load-balancing: "pods-per-node" spec: type: LoadBalancer externalTrafficPolicy: Local selector: app: store ports: - name: tcp-port protocol: TCP port: 8080 targetPort: 8080マニフェストをクラスタに適用します。
kubectl apply -f store-v1-lb-svc.yaml
重み付きロード バランシングに関するこの例については、次の点に注意してください。
Service マニフェストは
externalTrafficPolicy: Localを使用します。重み付きロード バランシングを有効にする必要がない場合は、externalTrafficPolicy: Clusterを使用することもできます。externalTrafficPolicyがノードグループを定義する方法、どのノードがロードバランサのヘルスチェックに合格するのか、パケットの処理方法の詳細については、LoadBalancer Service のコンセプトをご覧ください。重み付けロード バランシングを有効にしても、GKE で
externalTrafficPolicy: Clusterを使用できないわけではありませんが、externalTrafficPolicy: Clusterではロードバランサの後にパケットが別のノードに転送される可能性があるため、重み付けロード バランシングが事実上無効になります。
kubectl edit svc service-name を使用して、既存の外部 LoadBalancer Service で重み付けされたロード バランシングを有効にすることもできます。kubectl edit コマンドを使用すると、構成したテキスト エディタで既存のロードバランサの Service マニフェストが開きます。ここで、マニフェストを変更して保存できます。既存の外部 LoadBalancer Service を編集する場合は、次の点に注意してください。
既存の外部 LoadBalancer Service によって、バックエンド サービスベースの外部パススルー ネットワーク ロードバランサが作成されている必要があります。つまり、マニフェストがクラスタに最初に適用されたときに、既存の外部 LoadBalancer Service に
cloud.google.com/l4-rbs: "enabled"アノテーションが含まれている必要があります。ターゲット プールベースの外部パススルー ネットワーク ロードバランサを使用する既存の外部 LoadBalancer Service に
networking.gke.io/weighted-load-balancing: "pods-per-node"アノテーションを追加しても効果はありません。既存の外部 LoadBalancer Service マニフェストを更新する場合は、
externalTrafficPolicy: Localを設定してください。externalTrafficPolicy: Clusterを使用すると、パケットがロードバランサの後に別のノードに転送される可能性があるため、重み付けロード バランシングが無効になります。
重み付きロード バランシングを無効にする
各ノードに存在するサービング Pod の数に関係なく、新しい接続をノードに分散するには、Service マニフェストから networking.gke.io/weighted-load-balancing: "pods-per-node" アノテーションを削除して、重み付けロード バランシングを無効にします。
外部 LoadBalancer Service とそのコンポーネントを確認する
Service が実行されていることを確認します。
kubectl get svc store-v1-lb-svc出力は次のようになります。
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE store-v1-lb-svc LoadBalancer 10.44.196.160 35.193.28.231 8080:32466/TCP 11mGKE は、外部パススルー ネットワーク ロードバランサの
EXTERNAL_IPを割り当てました。ロードバランサへの接続をテストします。
curl EXTERNAL_IP:PORT次のように置き換えます。
EXTERNAL_IP: 外部パススルー ネットワーク ロードバランサに割り振られた IP アドレス。PORT: 外部パススルー ネットワーク ロードバランサに割り当てられたポート番号。
出力は次のようになります。
Hostname: store-v1-lb-svc-cdb9bb4d6-hflxd Pod Information: -no pod information available- Server values: server_version=nginx: 1.13.3 - lua: 10008 Request Information: client_address=10.128.0.50 method=GET real path=/ query= request_version=1.1 request_scheme=http request_uri=EXTERNAL_IP Request Headers: accept=*/* host=EXTERNAL_IP user-agent=curl/7.81.0 Request Body: -no body in request-LoadBalancer Service と、Google Cloud リソースを記述する一連のアノテーションを確認します。
kubectl describe svc store-v1-lb-svc出力は次のようになります。
Name: my-service-external Namespace: default Labels: <none> Annotations: cloud.google.com/l4-rbs: enabled networking.gke.io/weighted-load-balancing: pods-per-node #This annotation appears in the output only if weighted load balancing is enabled. service.kubernetes.io/backend-service: k8s2-qvveq1d8-default-my-service-ext-5s55db85 service.kubernetes.io/firewall-rule: k8s2-qvveq1d8-default-my-service-ext-5s55db85 service.kubernetes.io/firewall-rule-for-hc: k8s2-qvveq1d8-default-my-service-ext-5s55db85-fw service.kubernetes.io/healthcheck: k8s2-qvveq1d8-default-my-service-ext-5s55db85 service.kubernetes.io/tcp-forwarding-rule: a808124abf8ce406ca51ab3d4e7d0b7d Selector: app=my-app Type: LoadBalancer IP Family Policy: SingleStack IP Families: IPv4 IP: 10.18.102.23 IPs: 10.18.102.23 LoadBalancer Ingress: 35.184.160.229 Port: tcp-port 8080/TCP TargetPort: 8080/TCP NodePort: tcp-port 31864/TCP Endpoints: 10.20.1.28:8080,10.20.1.29:8080 Session Affinity: None External Traffic Policy: Local HealthCheck NodePort: 30394 Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ADD 4m55s loadbalancer-controller default/my-service-extバックエンド サービスベースの外部パススルー ネットワーク ロードバランサとその Google Cloud リソースが正常に作成されたことを示すフィールドがいくつかあります。
Eventsフィールド。LoadBalancer Service とそのリソースが正常に作成された場合、このフィールドは空になります。エラーが発生した場合は、ここに表示されます。Annotationsのリストが有効: GKE は、読み取り専用アノテーションの次のリストを Service マニフェストに追加します。名前がservice.kubernetes.io/で始まる各アノテーションは、ロードバランサの一部として作成された、またはロードバランサをサポートする Google Cloud リソースの名前を示すために使用されます。networking.gke.io/weighted-load-balancing: pods-per-nodeアノテーションは、重み付きロード バランシングが適用され、ロードバランサが各ノードで実行されている Pod の数に基づいてバックエンド Pod にトラフィックを分散することを示します。service.kubernetes.io/backend-serviceアノテーションは、ロードバランサのバックエンド サービスの名前を示します。service.kubernetes.io/healthcheckアノテーションは、バックエンド サービスによって使用されるロードバランサのヘルスチェックの名前を示します。service.kubernetes.io/tcp-forwarding-ruleアノテーションまたはservice.kubernetes.io/udp-forwarding-ruleアノテーションは、ロードバランサの転送ルールの名前を示します。service.kubernetes.io/firewall-ruleアノテーションは、クラスタノードへのトラフィックを許可するために作成されたファイアウォール ルールの名前を示します。このファイアウォール ルールのソース範囲は、spec.loadBalancerSourceRanges[]を使用してカスタマイズできます。LoadBalancer Service のファイアウォール ルールの詳細については、ファイアウォール ルールと送信元 IP アドレスの許可リストをご覧ください。service.kubernetes.io/firewall-rule-for-hcアノテーションは、ロードバランサのヘルスチェックに必要なファイアウォール ルールの名前を示します。
外部 LoadBalancer Service のロードバランサ リソースとファイアウォール ルールが作成されていることを確認します。
転送ルールを表示するには、次のコマンドを実行します。
gcloud compute forwarding-rules describe FWD_RULE_NAME \ --region=REGION_NAME次のように置き換えます。
FWD_RULE_NAME: 読み取り専用アノテーションservice.kubernetes.io/tcp-forwarding-ruleまたはservice.kubernetes.io/udp-forwarding-ruleによって提供される転送ルール名。これらのアノテーションを確認するには、kubectl describe svc SERVICE_NAMEを実行します。REGION_NAME: クラスタを含む Google Cloud リージョン。ゾーンクラスタの場合、リージョンにはクラスタが使用するゾーンが含まれています。
バックエンド サービスを表示するには、次のコマンドを実行します。
gcloud compute backend-services describe BACKEND_SERVICE_NAME \ --region=REGION_NAME次のように置き換えます。
BACKEND_SERVICE_NAME:service.kubernetes.io/backend-service読み取り専用アノテーションによって提供されるバックエンド サービスの名前。この読み取り専用アノテーションを確認するには、kubectl describe svc SERVICE_NAMEを実行します。REGION_NAME: クラスタを含む Google Cloud リージョン。ゾーンクラスタの場合、リージョンにはクラスタが使用するゾーンが含まれています。
ロードバランサのヘルスチェックを表示するには、次のコマンドを実行します。
gcloud compute health-checks describe HEALTH_CHECK_NAME \ --region=REGION_NAME次のように置き換えます。
HEALTH_CHECK_NAME: ロードバランサのヘルスチェック名。ヘルスチェックの名前は、service.kubernetes.io/healthcheck読み取り専用アノテーションによって提供されます。この読み取り専用アノテーションを確認するには、kubectl describe svc SERVICE_NAMEを実行します。REGION_NAME: クラスタを含む Google Cloud リージョン。ゾーンクラスタの場合、リージョンにはクラスタが使用するゾーンが含まれています。
ファイアウォール ルールを表示するには、次のコマンドを実行します。
gcloud compute firewall-rules describe FIREWALL_RULE_NAME \ gcloud compute firewall-rules describe HEALTH_CHECK_FIREWALL_RULE_NAME次のように置き換えます。
FIREWALL_RULE_NAME: ロードバランサへのトラフィックを許可するファイアウォール ルールの名前。このファイアウォール ルールの名前は、service.kubernetes.io/firewall-rule読み取り専用アノテーションによって提供されます。この読み取り専用アノテーションを確認するには、kubectl describe svc SERVICE_NAMEを実行します。HEALTH_CHECK_FIREWALL_RULE_NAME: ロードバランサのバックエンド（クラスタのノード）のヘルスチェックを許可するファイアウォール ルールの名前。このファイアウォール ルールの名前は、service.kubernetes.io/firewall-rule-for-hc読み取り専用アノテーションによって提供されます。この読み取り専用アノテーションを確認するには、kubectl describe svc SERVICE_NAMEを実行します。
外部 LoadBalancer Service を削除する
サンプルの store-v1-lb-svc 外部 LoadBalancer Service を削除するには、次のコマンドを使用します。
kubectl delete service store-v1-lb-svc
GKE は、外部 LoadBalancer Service 用に作成したすべてのロードバランサ リソースを自動的に削除します。
外部 LoadBalancer Service のトラブルシューティング
externalTrafficPolicy: Local を設定しないと、次のコマンドを使用して Service の説明を取得するときに、警告イベントが発生することがあります。
kubectl describe svc store-v1-lb-svc`
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning UnsupportedConfiguration 4m55s loadbalancer-controller Weighted load balancing by pods-per-node has no effect with External Traffic Policy: Cluster.
重み付きロード バランシングを有効にするには、externalTrafficPolicy: Local を設定する必要があります。
次のステップ
- ロードバランサ Service の概要については、LoadBalancer Service をご覧ください。
- ロードバランサ Service のパラメータの詳細については、LoadBalancer Service のパラメータをご覧ください。
- GKE でのロード バランシングのトラブルシューティング。