バンドル型ロードバランシングの構成

このページでは、GDCV for Bare Metal にバンドルされたロードバランシングを構成する方法について説明します。GDCV for Bare Metal は、ワーカーノードの専用プールまたはコントロールプレーンと同じノードで実行されるレイヤ 4 ロードバランサをデプロイします。

GDCV for Bare Metal で使用可能なロードバランシングトポロジの例については、ロードバランサの概要をご覧ください。

要件

すべてのロードバランサノードは、同じレイヤ 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 セクションには、このアドレスを記述しないでください。

loadBalancer.vips.ingressVIP

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

loadBalancer.addressPools

構成のこのセクションには、1 つ以上のアドレスプールが含まれています。各アドレスプールには、IP アドレス範囲のリストを指定します。LoadBalancer 型の Service を作成すると、Service の外部 IP アドレスはこうした範囲から選択されます。アドレスプールは次の形式で指定されます。

- 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）を提供します。GDCV for Bare Metal は、ロードバランサノードで Kubernetes の静的 Pod として Keepalived と HAProxy を実行し、コントロールプレーン VIP に通知します。Keepalived は、高可用性を実現するためにロードバランサノードの Virtual Router Redundancy Protocol（VRRP）を使用します。

データプレーンのロードバランシング

データプレーンロードバランサは、LoadBalancer タイプのすべての Kubernetes Service を対象としています。GDCV for Bare Metal は、レイヤ 2 モードで実行される MetalLB を使用してデータプレーンのロードバランシングを行います。データプレーンのロードバランシングは、GDCV for Bare Metal を介してのみ構成できます。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 の可視性を実現できます。

istio-ingress Service を編集用に開きます。
```
kubectl edit service -n gke-system istio-ingress
```
externalTrafficPolicy: Local を spec に追加し、エディタを保存して終了します。
```
apiVersion: v1
kind: Service
...
spec:
...
  externalTrafficPolicy: Local
```
istio-ingress Deployment を編集用に開きます。
```
kubectl edit deployment -n gke-system istio-ingress
```

次の 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