内部負荷分散

内部負荷分散

このページでは、Kubernetes Engine と Kubernetes 上で内部ロードバランサを作成する方法について説明します。

概要

内部ロードバランシングを使用すれば、同じネットワーク上ではあるもののクラスタ外部で実行中のアプリケーションからクラスタのサービスにアクセスできます。たとえば、同じネットワーク内のいくつかの Compute Engine VM インスタンスとともにクラスタを実行し、クラスタ内部のサービスをクラスタ外部のインスタンスから使用できるようにするには、クラスタのサービスリソースのいずれかを、内部ロードバランサを追加するように設定する必要があります。

内部ロードバランシングを使用しない場合は、外部ロードバランサをセットアップして、アクセスを制限するファイアウォールルールを作成し、アプリケーションの IP アドレスにクラスタ外部からアクセスできるようにネットワークルートをセットアップする必要があります。

内部負荷分散では、ユーザーのサブネット内の IP 範囲から同じコンピューティングリージョン内のネットワーク上のトラフィックを受信するためのプライベート（RFC1918）LoadBalancer Ingress IP アドレスをクラスタ内に作成します。

サービスリソースに LoadBalancer 仕様を追加することで、内部ロードバランサを作成します。クラスタにサービスが含まれていない場合は、サービスを作成する必要があります。これにより、Kubernetes kubectl コマンドラインインターフェースを使用して、内部ロードバランサを作成できるようになります。

準備

Cloud SDK がインストールされていることを確認します。
Kubernetes 1.7.2 以降が実行されているアクティブなコンテナクラスタがあることを確認します。

サービス設定ファイルの記述

内部ロードバランサを設定するサービスリソースの例を以下に示します。

config.yaml

apiVersion: v1
kind: Service
metadata:
  name: [SERVICE_NAME]
  annotations:
    cloud.google.com/load-balancer-type: "Internal"
  labels:
    app: echo
spec:
  type: LoadBalancer
  loadBalancerIP: [IP_ADDRESS]
  ports:
  - port: 9000
    protocol: TCP
  selector:
    [KEY]: [VALUE]

サービス設定ファイルには以下の要素を含める必要があります。

タイプ LoadBalancer と port フィールド
内部ロードバランサを設定するように指定するアノテーション cloud.google.com/load-balancer-type: "Internal"
[SERVICE_NAME] はサービスに付ける名前です

オプションの spec: protocol フィールドでは、内部ロードバランサによって使用されるネットワークプロトコルを定義します。このフィールドを省略すると、プロトコルは TCP に設定されます。

オプションの spec: loadBalancerIP フィールドを使用すれば、特定の IP アドレスを選択できます。IP アドレスは、別の内部ロードバランサやサービスによって使用されていないものにする必要があります。loadBalancerIP フィールドが指定されていない場合は、エフェメラル IP が LoadBalancer に割り当てられます。

サービスには、対象となるポッドを指定するための spec: selector フィールドも必要です。たとえば、selector のターゲットを app: echo というラベルの付いたポッドにすることができます。

内部ロードバランサの作成

内部ロードバランサを作成するには、シェルまたはターミナルウィンドウで以下のコマンドを実行します。

kubectl apply -f config.yaml

このコマンドによって、既存のサービスが更新されて内部ロードバランサが追加されるか、内部ロードバランサのある新しいサービスが作成されます。

サービスの検査

Console

内部ロードバランサの詳細を表示するには、次の手順を実行します。

GCP Console で、Kubernetes Engine の [検出と負荷分散] メニューにアクセスします。
[検出と負荷分散] メニューにアクセスする
目的のサービスを選択します。

gcloud

サービスが想定どおりに作成または更新されたことを検証するには、以下のコマンドを実行します。

kubectl describe service [SERVICE_NAME]

コマンドの出力は次のようになります。

Name:     [SERVICE_NAME]
Namespace:    default
Labels:     app=echo
Annotations:    cloud.google.com/load-balancer-type=Internal
Selector:   app=echo
Type:     LoadBalancer
IP:     10.0.146.226
LoadBalancer Ingress: 10.128.0.6
Port:       9000/TCP
NodePort:   30387/TCP
Endpoints:    10.100.1.10:80,10.100.2.10:80,10.100.3.8:80
Session Affinity: ClientIP

内部ロードバランサを使用する

内部ロードバランサは、externalTrafficPolicy、sessionAffinity、loadBalancerSourceRanges などの Kubernetes サービスパラメータをサポートします。

clusterIP（上記の例では IP）アドレスを使用して、クラスタ内部からサービスに引き続きアクセスできます。クラスタの外からサービスにアクセスするには、LoadBalancer Ingress IP アドレスを使用します。

サービスパラメータの設定の詳細については、クラウドプロバイダのファイアウォールを設定するをご覧ください。

既存の Ingress に関する考慮事項

クラスタに既存の Ingress リソースがある場合は、そのリソースでバランシングモード RATE を使用する必要があります。UTILIZATION バランシングモードは互換性がありません。

Kubernetes Ingress Resources オブジェクトによって作成された、以前の BackendService リソースは、分散モードを指定しないで作成されています。この API では、HTTP ロードバランサについてはデフォルトでバランシングモード UTILIZATION が使用されていました。しかし、内部ロードバランサでは、UTILIZATION を使って他のロードバランサを使用するインスタンスグループを指すことができません。

Kubernetes クラスタでの内部ロードバランサと Ingress リソースの互換性を保証するには、いくつかの手順を手動で実行することが必要になる可能性があります。

Ingress の互換性の判断

Ingress に互換性があるかどうかを判断するには、シェルまたはターミナルウィンドウから以下のコマンドを実行します。

GROUPNAME=`kubectl get configmaps ingress-uid -o jsonpath='k8s-ig--{.data.uid}' --namespace=kube-system`
gcloud compute backend-services list --format="table(name,backends[].balancingMode,backends[].group)" | grep $GROUPNAME

これらのコマンドによって、シェル変数 GROUPNAME がエクスポートされます。これによってクラスタのインスタンスグループ名が取得されます。次に、プロジェクトのコンピューティング BackendService リソースがポーリングされ、$GROUPNAME の内容に基づいて結果が絞り込まれます。

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

k8s-be-31210--...  [u'RATE']       us-central1-b/instanceGroups/k8s-ig--...
k8s-be-32125--...  [u'RATE']       us-central1-b/instanceGroups/k8s-ig--...

出力に RATE が表示されるか、エントリが返されなかった場合、内部ロードバランサは互換性があり、追加作業は必要ありません。

UTILIZATION とマークされたエントリが出力に表示される場合、Ingress は互換性がありません。

既存の Ingress の更新

バランシングモードのタイプは、既存の HTTP(S) ロードバランサがクラスタを指していない場合にのみ変更できます。

内部ロードバランサと互換性があるように Ingress リソースを更新するには、以下のいずれか 1 つを実行する必要があります。

マスターで Kubernetes バージョン 1.5.8 以降、または 1.6.4 以降が実行されている場合は、すべての Ingresses を削除して再作成します。その後、クラスタを Kubernetes バージョン 1.7.2 以降にアップグレードして、内部ロードバランサとの互換性を確保します。
Kubernetes バージョン 1.7.2 以降が実行される新しいクラスタを作成し、サービスをそのクラスタに移行します。新しいクラスタに移行すると、互換性のない balancingMode 値を持つ Ingress が存在することはなくなります。

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

マスターとノードで、Kubernetes バージョン 1.7.2 以降が実行されている必要があります。
内部ロードバランサは、1 つのタイプのプロトコル（TCP または UDP）でのみトラフィックを処理でき、サービス定義で指定された最初のポートのプロトコルを使用します。
内部ロードバランサは、同じネットワークとリージョン内からのみアクセスできます。
Kubernetes バージョン 1.7.4 以降を実行しているクラスタでは、自動モードサブネット（バージョン 1.7.2 以降で使用可能）に加えてカスタムモードサブネットを持つ内部ロードバランサを使用できます。
clusterIP は変更されませんが、内部ロードバランサの IP アドレスは予約できません。ポート、プロトコル、またはセッションアフィニティを変更すると、この IP アドレスが変更される可能性があります。

制限

クラスタの各ノードはバックエンドインスタンスであり、バックエンドインスタンスの制限に基づいてカウントされます。たとえば、クラスタに 300 ノードがあり、バックエンドインスタンス数が 250 に制限されている場合、250 インスタンスのみがトラフィックを受信します。この制限は、externalTrafficPolicy が Local に設定されたサービスに悪影響を及ぼす可能性があります。

内部ロードバランサの制限事項に関する情報は、Compute Engine の内部ロードバランシングの制限事項のセクションをご覧ください。

次のステップ

このページは役立ちましたか？評価をお願いいたします。

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 3.0 License, and code samples are licensed under the Apache 2.0 License. For details, see our Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

最終更新日: 3月 6, 2018