Anthos clusters on bare metal は、ベアメタル向け Google Distributed Cloud（ソフトウェアのみ）になりました。詳細については、プロダクトの概要をご覧ください。

このページは Cloud Translation API によって翻訳されました。

MetalLB を使用してバンドルされたロードバランシングを構成する

このページでは、Google Distributed Cloud の MetalLB を使用してバンドル型ロードバランシングを構成する方法について説明します。MetalLB ロードバランサは、ワーカーノードの専用プールまたはコントロールプレーンと同じノード上で動作します。

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

要件

すべてのロードバランサノードは、同じレイヤ 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_RANGE2

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 はありません。ロードバランサノードプール内のノードはワークロードを実行できますが、ワーカーノードプール内のノードとは分離されています。特定のクラスタノードを複数のノードプールに含めることはできません。ノードプール間でノード IP アドレスが重複すると、クラスタの作成などのクラスタオペレーションがブロックされます。

ロードバランサノードプール内のノードでワークロードが実行されないようにするには、次の taint をノードに追加します。

node-role.kubernetes.io/load-balancer:NoSchedule

Google Distributed Cloud は、ロードバランシングに必要な Pod にこの taint の toleration を追加します。

次の例は、2 つのノードを持つロードバランシングノードプールを示しています。最初のノードには、標準 IP アドレス nodePoolSpec.nodes.address（1.2.3.4）と Kubernetes IP アドレス nodePoolSpec.nodes.k8sIP（10.0.0.32）があります。ノードのオプションの k8sIP アドレスを指定すると、Kubernetes API、kubelet、ワークロードのリクエストやレスポンスなど、ノードのデータトラフィックの処理専用になります。この場合、管理クラスタオペレーションのノードへの SSH 接続には、標準 IP アドレス nodePoolSpec.nodes.address が使用されます。k8sIP アドレスを指定しない場合、標準ノードの IP アドレスがノードのすべてのトラフィックを処理します。

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

デフォルトでは、ロードバランサノードプール内のすべてのノードは、構成ファイルの loadBalancer.addressPools セクションで構成されているロードバランサの VIP と同じレイヤ 2 サブネット内にある必要があります。ただし、ノードに Kubernetes IP アドレス k8sIP を指定する場合は、そのアドレスのみが他のロードバランサの VIP と同じレイヤ 2 サブネットに存在する必要があります。

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

コントロールプレーンのロードバランシング

コントロールプレーンのロードバランサは、コントロールプレーンの仮想 IP アドレス（VIP）を提供します。Google Distributed Cloud は、ロードバランサノード上の Kubernetes 静的 Pod として Keepalived と HAProxy を実行し、コントロールプレーン VIP に通知します。Keepalived は、高可用性を実現するためにロードバランサノードの Virtual Router Redundancy Protocol（VRRP）を使用します。

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

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

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

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

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

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

Google Distributed Cloud は、クライアントの送信元 IP アドレスを保持するための次の 2 つの方法をサポートしています。

ロードバランシング転送モードを Direct Server Return（DSR）に設定します。DSR 転送モードの詳細（有効にする手順など）については、ロードバランシング転送モードを構成するをご覧ください。
LoadBalancer Service の外部トラフィックポリシーをローカルに設定し、それに応じて関連する Service と Ingress を構成します。以降のセクションでは、この方法を使用するようにクラスタを構成する方法について説明します。

サービス `LoadBalancer` 個

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

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

サービス `NodePort` 個

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

Ingress

アプリケーションが 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