Anthos clusters on VMware は VMware 向け Google Distributed Cloud（ソフトウェアのみ）になりました。詳細については、製品の概要をご覧ください。

Metal LB によるバンドルされたロードバランシング

このドキュメントでは、MetalLB ロードバランサを使用してバンドル型ロードバランシングを使用するように GKE on VMware を構成する方法について説明します。

GKE on VMware では、MetaLB はレイヤ 2 モードで実行されます。

MetalLB 構成の例

次は、MetalLB ロードバランサを実行するクラスタの構成例です。

MetalLB ロードバランサの構成。 — MetalLB ロードバランサの構成

上の図は、MetalLB のデプロイメントを示しています。MetalLB は、クラスタノードで直接実行されます。この例では、管理クラスタとユーザークラスタが 2 つの別々の VLAN にあり、各クラスタは別々のサブネットにあります。

クラスタ	サブネット
管理クラスタ	172.16.20.0/24
ユーザークラスタ	172.16.40.0/24

admin-cluster.yaml

管理クラスタ構成ファイルの次の部分は、前の図にある構成を示しています。

高可用性コントロールプレーン
MetalLB ロードバランサ
管理クラスタの Kubernetes API サーバー用の MetalLB の VIP

network:
  ...
  controlPlaneIPBlock:
    netmask: "255.255.255.0"
    gateway: "172.16.20.1"
    ips:
    - ip: "172.16.20.50"
      hostname: "admin-cp-1"
    - ip: "172.16.20.51"
      hostname: "admin-cp-2"
    - ip: "172.16.20.52"
      hostname: "admin-cp-3"
loadBalancer:
  kind: "MetalLB"
  ...
  vips:
    controlPlaneVIP: "172.16.20.100"
...
adminMaster:
  cpus: 4
  memoryMB: 16384
  replicas: 3

user-cluster.yaml

ユーザークラスタ構成ファイルの次の部分は、次の構成を示しています。

選択して LoadBalancer タイプの Service に割り当てる、MetalLB コントローラのアドレスプール。Ingress VIP はこのプールにあります。
ユーザークラスタの Kubernetes API サーバー用に指定された VIP と、Ingress プロキシ用に構成するように選択した Ingress VIP。
MetalLB の使用が有効になっているノードプール。MetalLB は、このノードプール内のノードにデプロイされます。

enableControlplaneV2: true
...
network:
  hostConfig:
  ...

  ipMode:
    type: "static"
    ipBlockFilePath: "config-folder/user-cluster-ipblock.yaml"
...
  controlPlaneIPBlock:
    netmask: "255.255.255.0"
    gateway: "172.16.40.1"
    ips:
    - ip: "172.16.40.21"
      hostname: "user-cp"
loadBalancer:
  kind: MetalLB
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
      - "172.16.40.101-172.16.40.112
      avoidBuggyIPs: true
  ...

  vips:
    controlPlaneVIP: "172.16.20.100"
    ingressVIP: "172.16.40.101"
...
nodePools:
- name: "node-pool-1"
  cpus: 4
  memoryMB: 8192
  replicas: 3
  enableLoadBalancer: true

上記の例の構成では、Service に使用できるアドレスのセットを指定します。アプリケーションのデベロッパーがユーザークラスタに LoadBalancer タイプの Service を作成すると、MetalLB コントローラがこのプールから IP アドレスを選択します。

user-cluster-ipblock.yaml

次の IP ブロックファイルの例は、ユーザークラスタ内に存在するワーカーノードの IP アドレスの指定を示しています。これには、クラスタのアップグレード、更新、自動修復で使用する追加の IP アドレスが含まれます。

blocks:
- netmask: "255.255.255.0"
  gateway: "17.16.40.1"
  ips:
  - ip: 172.16.40.22
    hostname: user-vm-1
  - ip: 172.16.40.23
    hostname: user-vm-2
  - ip: 172.16.40.24
    hostname: user-vm-3
  - ip: 172.16.40.25
    hostname: user-vm-4
  - ip: 172.16.40.26
    hostname: user-vm-5
  - ip: 172.16.40.27
    hostname: user-vm-6

MetalLB の設定

開放するファイアウォールポート

MetalLB は、Go memberlist ライブラリを使用してリーダー選出を行います。memberlist ライブラリでは、TCP ポート 7946 と UDP ポート 7946 を使用して情報が交換されます。すべてのロードバランサノードで、受信トラフィックと送信トラフィックがこれらのポートにアクセスできることを確認してください。

新しい管理クラスタの MetalLB を有効にする

管理クラスタ構成ファイルで、loadBalancer.kind を "MetalLB" に設定します。

loadBalancer:
  kind: "MetalLB"

管理クラスタの残りの構成ファイルを入力し、管理クラスタの作成の説明のとおりに管理クラスタを作成します。

アドレスプールの指定

MetalLB コントローラが Service の IP アドレス管理を行います。そのため、アプリケーションデベロッパーが、ユーザークラスタに LoadBalancer タイプの Service を作成する際に、Service の IP アドレスを手動で指定する必要はありません。代わりに、MetalLB コントローラは、クラスタ作成時に指定されたアドレスプールから IP アドレスを選択します。

ユーザークラスタで常にアクティブな LoadBalancer タイプの Service の数を考慮します。次に、ユーザークラスタ構成ファイルの loadBalancer.metalLB.addressPools セクションで、それらの Service に対応する十分な IP アドレスを指定します。

ユーザークラスタの Ingress VIP は、アドレスプールで指定したアドレス内にある必要があります。これは、Ingress プロキシが LoadBalancer タイプの Service によって公開されるためです。

アプリケーションデベロッパーが LoadBalancer タイプの Service を作成する必要がない場合は、Ingress VIP 以外のアドレスを指定する必要はありません。

アドレスは CIDR 形式または範囲形式にする必要があります。個々のアドレスを指定する場合は、/32 CIDR を使用します。例:

addresses:
  - "192.0.2.0/26"
  - "192.0.2.64-192.0.2.72"
  - "192.0.2.75/32

クラスタの作成後にプール内のアドレスを調整する必要がある場合は、gkectl update cluster を使用できます。詳細については、MetalLB の更新をご覧ください。

新しいユーザークラスタの MetalLB を有効にする

ユーザークラスタの構成ファイルで、次の操作を行います。

loadBalancer.kind を "MetalLB" に設定する。
Service のアドレスプールを 1 つ以上指定します。Ingress VIP をプールの 1 つに含める必要があります。
enableLoadBalancer をクラスタ内の少なくとも 1 つのノードプールの true に設定します。

ユーザークラスタ構成ファイルの残りの部分を入力し、ユーザークラスタを作成するの説明のとおりにユーザークラスタを作成します。

サービスアドレスの手動割り当て

MetalLB コントローラが特定のプールの IP アドレスを Service に自動的に割り当てないようにするには、プールの manualAssign フィールドを true に設定します。次に、デベロッパーは、LoadBalancer タイプの Service を作成し、プールからアドレスのいずれか 1 つを手動で指定します。次に例を示します。

loadBalancer:
  metalLB:
    addressPools:
    - name: "my-address-pool-2"
      addresses:
      - "192.0.2.73-192.0.2.80"
      manualAssign: true

バグのある IP アドレスの回避

アドレスプールの avoidBuggyIPs フィールドを true に設定すると、末尾が .0 または .255 のプールのアドレスは、MetalLB コントローラでは使用されなくなります。これにより、バグの多いコンシューマデバイスが、これらの特別な IP アドレスに送信されたトラフィックを誤って破棄するという問題を回避できます。次に例を示します。

loadBalancer:
  metalLB:
    addressPools:
    - name: "my-address-pool-1"
      addresses:
      - "192.0.2.0/24"
      avoidBuggyIPs: true

LoadBalancer タイプの Service を作成する

以下は、Deployment と Service の 2 つのマニフェストです。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  selector:
    matchLabels:
      greeting: hello
  replicas: 3
  template:
    metadata:
      labels:
        greeting: hello
    spec:
      containers:
      - name: hello
        image: gcr.io/google-samples/hello-app:2.0
---
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: LoadBalancer
  selector:
    greeting: hello
  ports:
  - name: metal-lb-example-port
    protocol: TCP
    port: 60000
    targetPort: 8080

Service マニフェストでは外部 IP アドレスを指定していないことに注意してください。MetalLB コントローラは、ユーザークラスタの構成ファイルで指定されたアドレスプールから外部 IP アドレスを選択します。

マニフェストを my-dep-svc.yaml という名前のファイルに保存します。次に、Deployment オブジェクトと Service オブジェクトを作成します。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f my-dep-svc.yaml

Service を表示します。

kubectl --kubeconfig USER_CLUSTER_KUBECONIFG get service my-service --output wide

出力には、Service に自動的に割り当てられた外部 IP アドレスが表示されます。例:

NAME         TYPE           CLUSTER-IP    EXTERNAL-IP   PORT(S)           AGE   SELECTOR
my-service   LoadBalancer   10.96.2.166   192.0.2.2   60000:31914/TCP   28s

割り当てられた外部 IP アドレスが、ユーザークラスタの構成ファイルで指定したアドレスプールから取得されたことを確認します。たとえば、192.0.2.2 はこのアドレスプールに存在します。

metalLB:
  addressPools:
  - name: "address-pool-1"
    addresses:
     - "192.0.2.0/24"
     - "198.51.100.1-198.51.100.3"

Service を呼び出します。

curl EXTERNAL_IP_ADDRESS:60000

出力には、Hello, world! メッセージが表示されます。

Hello, world!
Version: 2.0.0

MetalLB の更新

クラスタを作成したら、MetalLB アドレスプールとノードプールの enableLoadBalancer フィールドを更新できます。ユーザークラスタの構成ファイルで必要な変更を行い、gkectl update cluster を呼び出します。

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONIFG --config USER_CLUSTER_CONFIG

MetalLB Pod と ConfigMap

MetalLB コントローラは Deployment として実行され、MetalLB スピーカーは enableLoadBalancer が true に設定されているプール内のノードで DaemonSet として実行されます。MetalLB コントローラは、Service に割り当てられた IP アドレスを管理します。MetalLB スピーカーはリーダー選出を行い、Service VIP を通知します。

すべての MetalLB Pod を表示します。

kubectl --kubeconfig USER_CLUSTER_KUBECONIFG get pods --namespace kube-system --selector app=metallb

MetalLB Pod のログを使用してトラブルシューティングを行うことができます。

MetalLB 構成は、MetalLB で知られている形式で ConfigMap に保存されます。ConfigMap を直接変更しないでください。代わりに、前述のように gkectl update cluster を使用します。トラブルシューティングのために ConfigMap を表示するには:

kubectl --kubeconfig USER_CLUSTER_KUBECONIFG get configmap metallb-config --namespace kube-system

MetalLB を使用するメリット

MetalLB はクラスタノード上で直接実行されるため、追加の VM は不要です。
MetalLB コントローラが Service の IP アドレス管理を行うため、Service ごとに手動で IP アドレスを選択する必要はありません。
異なる Service の MetalLB のアクティブなインスタンスを異なるノードで実行できます。
Service 間で IP アドレスを共有できます。

MetalLB の F5 BIG-IP と Seesaw との比較

VIP はクラスタノードと同じサブネット内に存在する必要があるこれは Seesaw の要件でもありますが、F5 BIG-IP の要件ではありません。
トラフィックの指標はありません。
ヒットレスフェイルオーバーは発生しません。既存の接続がフェイルオーバー中にリセットされます。
特定の Service の Pod への外部トラフィックは、MetalLB スピーカーを実行している 1 つのノードを通過します。つまり、通常、クライアント IP アドレスは、Pod で実行されているコンテナには表示されません。

Metal LB によるバンドルされたロード バランシング