バンドルされた負荷分散を構成する

このページでは、ベアメタル版 Anthos クラスタのバンドル型負荷分散を構成する方法について説明します。ベアメタル版 Anthos クラスタは、ワーカーノードの専用プールまたはコントロール プレーンと同じノードで実行されるレイヤ 4 ロードバランサをデプロイします。

ベアメタル版 Anthos クラスタで使用可能な負荷分散トポロジの例については、ロードバランサの概要をご覧ください。

バンドルされた負荷分散を構成する

要件

  • すべてのロードバランサ ノードは、同じレイヤ 2 サブネット内にある必要があります。
  • すべての VIP は、ロードバランサのノードのサブネット内に存在し、サブネットのゲートウェイからルーティング可能である必要があります。
  • ロードバランサのサブネットのゲートウェイは、Gratuitous ARP メッセージをリッスンし、ロードバランサ ノードに ARP パケットを転送するできる必要があります。

設定に関する項目

クラスタ構成ファイルの cluster.spec.loadBalancer セクションを編集して、バンドル型負荷分散を構成します。クラスタ構成ファイルと有効な構成の例に関する情報は、次のいずれかのページをご覧ください。

loadBalancer.mode

バンドル型負荷分散を有効にするには、この値を bundled にする必要があります。

loadBalancer.ports.controlPlaneLBPort

この値は、Kubernetes コントロール プレーン（Kubernetes API サーバー）に送信されるトラフィックに使用される宛先ポートを指定します。

loadBalancer.vips.controlPlaneVIP

この値は、Kubernetes コントロール プレーン（Kubernetes API サーバー）に送信されるトラフィックに使用する宛先 IP アドレスを指定します。この IP アドレスは、ロードバランサを実行しているノードと同じレイヤ 2 サブネットに存在する必要があります。構成ファイルの [address pools](#address-pools) セクションには、このアドレスを記述しないでください。

loadBalancer.vips.ingressVIP

この値は、上り（内向き）トラフィック用ロードバランサの背後にある Service に使用する IP アドレスを指定します。管理クラスタ構成ファイルでは、このフィールドを使用できません。このアドレスは、構成のアドレスプール セクションに記述する必要があります。

loadBalancer.addressPools

構成のこのセクションには、次の形式で指定された複数のアドレスプールが含まれています。

- name: pool-name
  avoidBuggyIPs: boolean
  manualAssign: boolean
  addresses:
  - ip-range
  - ip-range
  • name: ご自身の組織向けのアドレスプールの名前（pool-name）。
  • avoidBuggyIPs: （省略可）true または false。true の場合は、末尾が .0 と .255 のIP アドレスがプールから除外されます。一部のネットワーク ハードウェアは、これらの特別なアドレスへのトラフィックをドロップします。このフィールドは省略できます。デフォルト値は false です。
  • manualAssign: （省略可）。true または false。true の場合、このプール内のアドレスは Kubernetes Services に自動的に割り当てられません。true の場合、このプール内の IP アドレスは、サービスによって明示的に指定された場合にのみ使用されます。このフィールドは省略できます。デフォルト値は false です。
  • addresses 重複しない 1 つ以上の IP アドレス範囲のリスト。ip-range は、CIDR 表記（198.51.100.0/24 など）または範囲表記（198.51.100.0-198.51.100.10 など。ダッシュの前後にスペースなし）で指定します。

addresses リストの IP アドレス範囲は重複していてはならず、ロードバランサを実行しているノードと同じサブネット内に存在する必要があります。

loadBalancer.nodePoolSpec

構成のこのセクションでは、ロードバランサを実行するノードのリストを指定します。ロードバランサ ノードは、デフォルトで通常のワークロードを実行できます。これらのノードには特別な taint はありません。以下の例は、2 つのノードを持つノードプールを示しています。最初のノード 1.2.3.4 は、k8sIP フィールドを使用して、クラスタ内のノードの IP アドレスを指定します。1.2.3.4 アドレスは SSH アクセスにのみ使用されます。

nodePoolSpec:
  nodes:
  - address: 1.2.3.4
    k8sIP: 10.0.0.32
  - address: 10.0.0.33

ロードバランサ ノードプール内のすべてのノードは、構成ファイルの loadBalancer.addressPools セクションで構成されているロードバランサの VIP と同じレイヤ 2 サブネット内にある必要があります。ノードに k8sIP が構成されている場合は、他のロードバランサの VIP と同じレイヤ 2 サブネットになければならないアドレスはそのアドレスだけです。

nodePoolSpec が設定されない場合、バンドルされたロードバランサは、コントロール プレーン ノードで実行されます。可能であれば、ロードバランサは、別のノードプールで実行することをおすすめします。

コントロール プレーンの負荷分散

コントロール プレーンのロードバランサは、コントロール プレーンの仮想 IP アドレス（VIP）を提供します。Anthos clusters on bare metal は、Docker コンテナの Keepalived と HAProxy をロードバランサのノード上の systemd サービスとして実行して、コントロール プレーン VIP を通知します。Keepalived は、高可用性の目的でロードバランサ ノードの Virtual Router Redundancy Protocol（VRRP）を使用します。

次のようにして、ロードバランサ ノード上の Keepalived ログと HAProxy のログにアクセスします。

journalctl -u docker.keepalived.service

journalctl -u docker.haproxy.service

データプレーンの負荷分散

データ プレーン ロードバランサは、LoadBalancer タイプのすべての Kubernetes Service を対象としています。ベアメタル版 Anthos クラスタは、レイヤ 2 モードで実行される MetalLB を使用してデータプレーンの負荷分散を行います。データ プレーンの負荷分散は、ベアメタル版 Anthos クラスタを介してのみ構成できます。MetalLB の ConfigMap を直接変更しないでください。サービス間での IP アドレス共有など、すべての MetalLB 機能を使用できます。機能の詳細については、MetalLB のドキュメントをご覧ください。

MetalLBL は、デーモンセットを使用して各ノードでスピーカー Pod を実行し、高可用性のために memberlist を使用します。クラスタごとにではなく、Kubernetes Service ごとに専用の MetalLB 専用のロードバランサ ノードがあります。この方法により、複数のサービスがある場合、トラフィックはロードバランサ ノード間で分散されます。

データ プレーン ロードバランサは、コントロール プレーン ノードまたはワーカー ノードのサブセットで実行できます。コントロール プレーン ノードでデータプレーン ロードバランサのバンドルを行うと、コントロール プレーン ノードの使用率が増えます。ただし、コントロール プレーン ノードでバンドルを行うと、コントロール プレーンの過負荷のリスクが高まり、SSH 認証鍵などのコントロール プレーン上の機密情報のリスク プロファイルが増加します。

クライアントの送信元 IP アドレスの保持

バンドルされたレイヤ 2 ロード バランシング ソリューションで作成された LoadBalancer Service は、外部トラフィック ポリシーのデフォルトの Cluster 設定を使用します。この設定 spec.externalTrafficPolicy: Cluster は、クラスタ全体のエンドポイントに外部トラフィックを転送しますが、クライアント送信元 IP アドレスは不明瞭になります。

以降のセクションでは、クライアントの送信元 IP アドレスを保持するようにクラスタを構成する方法について説明します。

サービス NodePort 個

Kubernetes は、NodePort Service に送信元ネットワーク アドレス変換（NAT）を行います。クライアントの送信元 IP アドレスを保持するには、service.spec.externalTrafficPolicy を Local に設定します。Kubernetes はソース NAT を実行しなくなりますが、選択したノード IP で実行中の Pod があることを確認する必要があります。

サービス LoadBalancer 個

LoadBalancer Service で externalTrafficPolicy: Local を使用するときは、ロードバランサ ノードで確実に実行されるようにアプリケーション Pod を設定します。この変更を行うには、次の nodeSelector をアプリケーション Pod に追加します。

apiVersion: v1
kind: Pod
...
spec:
  nodeSelector:
      baremetal.cluster.gke.io/lbnode: "true"
...

上り（内向き）

アプリケーションが HTTP サービスである場合は、Ingress コンポーネントを構成することで、クライアント IP の可視性を実現できます。

  1. istio-ingress Service を編集用に開きます。

    kubectl edit service -n gke-system istio-ingress

  2. externalTrafficPolicy: Local を spec に追加し、エディタを保存して終了します。

    apiVersion: v1
kind: Service
...
spec:
...
  externalTrafficPolicy: Local

  3. istio-ingress Deployment を編集用に開きます。

    kubectl edit deployment -n gke-system istio-ingress

  4. 次の nodeSelector を Deployment に追加し、エディタを保存して終了します。

    apiVersion: apps/v1
kind: Deployment
...
spec:
  ...
  template:
    ...
    spec:
      ...
      nodeSelector:
          baremetal.cluster.gke.io/lbnode: "true"
...

次の例のように、Ingress の背後にあるすべてのサービスに、クライアント IP を含む X-Forwarded-For ヘッダーが表示されます。

X-Forwarded-For: 21.0.104.4