Seesaw によるバンドル型負荷分散

GKE on VMware は、統合、手動、バンドル型の 3 つの負荷分散モードのいずれかで実行できます。このドキュメントでは、バンドル型モードで Seesaw ロードバランサを実行するように GKE on VMware を構成する方法について説明します。

ここでは手順全体を詳しく解説します。Seesaw ロードバランサの使用方法の概要については、Seesaw ロードバランサ（クイックスタート）をご覧ください。

バンドル型負荷分散モードでは、GKE on VMware がロードバランサの提供と管理をします。ロードバランサにライセンスを割り当てる必要はありません。必要なセットアップ作業は最小限に抑えられます。

このドキュメントでは、管理クラスタと 1 つの関連するユーザー クラスタ向けに Seesaw ロードバランサを構成する方法について説明します。Seesaw ロードバランサは、単一の VM で実行することも、2 つの VM を使用する高可用性（HA）モードで実行することもできます。HA モードでは、Seesaw ロードバランサは Virtual Router Redundancy Protocol（VRRP）を使用します。その 2 つの VM は、マスターとバックアップと呼ばれます。各 Seesaw VM には、任意の仮想ルーター ID（VRID）を指定します。

Seesaw 構成の例

HA モードで Seesaw ロードバランサを実行するクラスタの構成例を示します。

HA モードでの Seesaw ロードバランサの構成。
HA モードでの Seesaw ロードバランサの構成（クリックして拡大）

上の図には、管理クラスタとユーザー クラスタのそれぞれに 2 つの Seesaw VM があります。この例では、管理クラスタとユーザー クラスタが 2 つの別々の VLAN にあり、各クラスタは別々のサブネットにあります。

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

admin-cluster.yaml

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

  • 管理クラスタにサービスを提供する Seesaw VM のペアのマスター IP アドレス。

  • 管理クラスタの Kubernetes API サーバー用に指定された VIP。

network:
  hostConfig:
  ...

  ipMode:
    type: "static"
    ipBlockFilePath: "config-folder/admin-cluster-ipblock.yaml"
...

loadBalancer:
  seesaw:
    ipBlockFilePath: "config-folder/admin-seesaw-ipblock.yaml"
    masterIP: 172.16.20.57
  ...

  vips:
    controlPlaneVIP: "172.16.20.70"
    addonsVIP: "172.16.20.71"

admin-cluster-ipblock.yaml

次の IP ブロック ファイルの例では、管理クラスタ内にあるノードの IP アドレスの指定を示します。これには、ユーザー クラスタのコントロール プレーン ノードのアドレスと、クラスタのアップグレード中に使用する IP アドレスも含まれます。

blocks:
- netmask: "255.255.255.0"
  gateway: "17.16.20.1"
  ips:
  - ip: 172.16.20.50
    hostname: admin-vm-1
  - ip: 172.16.20.51
    hostname: admin-vm-2
  - ip: 172.16.20.52
    hostname: admin-vm-3
  - ip: 172.16.20.53
    hostname: admin-vm-4
  - ip: 172.16.20.54
    hostname: admin-vm-5

admin-seesaw-ipblock.yaml

次に示す別の IP ブロック ファイルの例では、管理クラスタにサービスを提供する Seesaw VM に 2 つの IP アドレスを指定しています。これは、ロードバランサ VM 用の別々の IP ブロック ファイルであり、クラスタノード用ではないことに留意してください。

blocks:
  - netmask: "255.255.255.0"
    gateway: "172.16.20.1"
    ips:
    - ip: "172.16.20.60"
      hostname: "admin-seesaw-vm-1"
    - ip: "172.16.20.61"
      hostname: "admin-seesaw-vm-2"

user-cluster.yaml

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

  • ユーザー クラスタにサービスを提供する Seesaw VM のペアのマスター IP アドレス。

  • ユーザー クラスタ内の Kubernetes API サーバーと Ingress サービス用に指定された VIP。ユーザー クラスタ用のコントロール プレーンは管理クラスタ内のノードで実行されるため、Kubernetes API サーバー VIP は管理クラスタ サブネットにあります。

network:
  hostConfig:
  ...

  ipMode:
    type: "static"
    ipBlockFilePath: "config-folder/user-cluster-ipblock.yaml"
...

loadBalancer:
  seesaw:
    ipBlockFilePath: "config-folder/user-seesaw-ipblock.yaml"
    masterIP: 172.16.40.31
  ...

  vips:
    controlPlaneVIP: "172.16.20.72"
    ingressVIP: "172.16.40.100"

user-cluster-ipblock.yaml

次の IP ブロック ファイルの例は、ユーザー クラスタ内に存在するノードの IP アドレスの指定を示しています。これには、クラスタのアップグレード中に使用する IP アドレスが含まれます。

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

user-seesaw-ipblock.yaml

次に示す別の IP ブロック ファイルの例では、ユーザー クラスタにサービスを提供する Seesaw VM に 2 つの IP アドレスを指定しています。

blocks:
  - netmask: "255.255.255.0"
    gateway: "172.16.40.1"
    ips:
    - ip: "172.16.40.29"
      hostname: "user-seesaw-vm-1"
    - ip: "172.16.40.30"
      hostname: "user-seesaw-vm-2"

ポート グループ

次の表に、上図に示す各 Seesaw VM のネットワーク インターフェースとそれらの接続ポートグループの構成を示します。

Seesaw VM ネットワーク インターフェース ネットワーク インターフェースの設定 接続されたポートグループ
マスター network-interface-1 VIP load-balancer
network-interface-2 Seesaw VM の IP ブロック ファイルから取得した IP アドレス cluster-node
バックアップ network-interface-1 構成なし load-balancer
network-interface-2 Seesaw VM の IP ブロック ファイルから取得した IP アドレス cluster-node

クラスタノードは、クラスタノードのポートグループにも接続されます。

上の表に示すように、管理クラスタとユーザー クラスタのそれぞれの Seesaw VM には、2 つのネットワーク インターフェースがあります。Seesaw VM ごとに、2 つのネットワーク インターフェースは 2 つの別々のポートグループに接続されます。

  • ロードバランサのポートグループ

  • クラスタノードのポートグループ

クラスタの 2 つのポートグループは、そのクラスタの同じ VLAN 上にあります。

Seesaw ロードバランサを設定する

上の図は、Seesaw のロード バランシングに推奨されるネットワーク構成を示しています。独自の構成を計画する際は、バンドル型ロード バランシング モードに vSphere 6.7 以降と Virtual Distributed Switch（VDS）6.6 以降を使用することを強くおすすめします。

必要に応じて、以前のバージョンを使用することもできますが、インストールの安全性は低下します。このトピックの残りのセクションでは、vSphere 6.7 以降と VDS 6.6 以降を使用する際のセキュリティ上の利点について詳しく説明します。

VLAN の計画

バンドル型負荷分散モードでは、クラスタを別々の VLAN に配置することを強くおすすめします。

管理クラスタが専用の VLAN 上に存在する場合、コントロール プレーンのトラフィックはデータプレーンのトラフィックから分離されます。これにより、管理クラスタとユーザー クラスタのコントロール プレーンが構成ミスから保護されます。このようなミスは、たとえば、同じ VLAN 内のレイヤ 2 ループによるブロードキャスト ストームや、データプレーンとコントロール プレーンの間の望ましい分離を排除する IP アドレスの競合などの問題につながる可能性があります。

VM リソースのプロビジョニング

Seesaw ロードバランサを実行する VM については、発生が予想されるネットワーク トラフィックに応じて CPU リソースとメモリリソースをプロビジョニングします。

Seesaw ロードバランサは、メモリ消費量が少なく、メモリが 1 GB の VM で実行できます。ただし、ネットワークのパケットレートが増加すると、CPU の要件も増加します。

次の表では、Seesaw VM をプロビジョニングするためのストレージ、CPU、メモリのガイドラインを示します。パケットレートは、ネットワーク パフォーマンスの一般的な基準ではないため、表には、アクティブなネットワーク接続の最大数に関するガイドラインも示しています。このガイドラインでは、VM に 10 Gbps のリンクがあり、CPU が 70% 未満の能力で実行される環境を想定しています。

Seesaw ロードバランサを HA モードで実行すると、（マスター、バックアップ）ペアが使用され、すべてのトラフィックが 1 つの VM を通過します。実際の使用例は変化するため、これらのガイドラインは実際のトラフィックに基づいて変更する必要があります。必要な変更は、CPU とパケットレートの指標をモニタリングして判断します。

Seesaw VM の CPU とメモリを変更する場合は、ロードバランサのアップグレードをご覧ください。なお、ロードバランサのバージョンを変えずに維持し、CPU の数とメモリ割り当てを変更できます。

小規模な管理クラスタの場合は 2 つの CPU を、大規模な管理クラスタの場合は 4 つの CPU をおすすめします。

ストレージ CPU メモリ パケットレート（pps） アクティブ接続の最大数
20 GB 1（非本番環境） 1 GB 250,000 100
20 GB 2 3 GB 450,000 300
20 GB 4 3 GB 850,000 6,000
20 GB 6 3 GB 1,000,000 10,000

VIP と IP アドレスを確保する

VIP

負荷分散モードのどれを選択するかにかかわらず、負荷分散に使用する仮想 IP アドレス（VIP）をいくつか確保する必要があります。この VIP により、外部クライアントは Kubernetes API サーバー、Ingress Service、アドオン サービスにアクセスできます。

また、ユーザー クラスタで常にアクティブなタイプ LoadBalancer の Service の数を考慮し、十分な VIP を確保します。後でタイプ LoadBalancer の Service を作成すると、Anthos clusters on VMware が自動的にロードバランサの Service VIP を構成します。

ノード IP アドレス

バンドル型負荷分散モードでは、クラスタノードの静的 IP アドレスを指定することも、クラスタノードが DHCP サーバーから IP アドレスを取得することもできます。

クラスタノードに静的 IP アドレスを割り当てる場合は、管理クラスタ内のノードと、作成するすべてのユーザー クラスタのノードに十分な数のアドレスを確保します。また、クラスタのアップグレード中に使用するクラスタごとに、追加の IP アドレスも確保します。設定するノード IP アドレスの数の詳細については、管理クラスタの作成をご覧ください。

Seesaw VM の IP アドレス

次に、クラスタ、管理者とユーザーごとに、Seesaw ロードバランサを実行する VM の IP アドレスを確保します。確保するアドレスの数は、HA Seesaw ロードバランサか非 HA Seesaw ロードバランサを作成するかによって異なります。

マスター IP アドレス

Seesaw VM の IP アドレスに加えて、各クラスタの Seesaw VM のペアにも単一のマスター IP アドレスを確保します。

非 HA 構成

設定が非 HA 構成の場合:

  • 管理クラスタでは、Seesaw VM 用に 1 個の IP アドレス、Seesaw ロードバランサ用に 1 個のマスター IP アドレスを確保します。これらのアドレスは両方とも、管理クラスタノードと同じ VLAN 上にある必要があります。

  • ユーザー クラスタでは、Seesaw VM 用に 1 個の IP アドレス、Seesaw ロードバランサ用に 1 個のマスター IP アドレスを確保します。これらのアドレスは両方とも、ユーザー クラスタノードと同じ VLAN 上にある必要があります。

ポートグループの計画

上の図は、HA 構成で使用される 2 つのポートグループと、それらの Seesaw VM のネットワーク インターフェースへの接続方法を示しています。個別の Seesaw VM では、2 つのネットワーク インターフェースを同じ vSphere ポートグループに接続することも、別々のポートグループに接続することもできます。MAC ラーニングを有効化しない場合は、1 つのポートグループを作成できます。ポートグループが別々の場合は、同じ VLAN 上にある必要があります。

IP ブロック ファイルの作成

クラスタ、管理者、ユーザーごとに、Seesaw VM 用に選択したアドレスを IP ブロック ファイルに指定します。 クラスタノードに静的 IP アドレスを使用する場合は、それらのアドレスに個別の IP ブロック ファイルを作成する必要があります。

構成ファイルの入力

構成ファイルは、管理クラスタ用と、ユーザー クラスタ用に別々に準備します。

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

loadBalancer で、seesaw セクションに以下を入力します。

loadBalancer:
  kind: Seesaw
  seesaw:

クラスタ構成ファイルの seesaw セクションの入力方法については、loadbalancer.seesaw（管理クラスタ）またはloadbalancer.seesaw（ユーザー クラスタ）を参照してください。

管理クラスタの構成ファイルで、次を指定します。

  • 管理クラスタの Kubernetes API サーバーの VIP
  • 管理クラスタ アドオンの VIP
  • 管理クラスタにサービスを提供する Seesaw VM のペアのマスター IP アドレス。

これらの VIP は、管理クラスタ サブネット上に存在する必要があります。

ユーザー クラスタの構成ファイルで、次を指定します。

  • ユーザー クラスタの Kubernetes API サーバーの VIP（これは管理クラスタのサブネット上に存在する必要があります）
  • ユーザー クラスタの上り（内向き）VIP
  • ユーザー クラスタにサービスを提供する Seesaw VM のペアのマスター IP アドレス。

上のリストの最後の 2 つのアドレスは、ユーザー クラスタのサブネット上に存在する必要があります。

MAC ラーニングまたは無作為モードの有効化（HA のみ）

非 HA Seesaw ロードバランサを設定する場合は、このセクションをスキップできます。

loadBalancer.seesaw.disableVRRPMAC を true に設定した場合は、このセクションをスキップできます。

HA Seesaw ロードバランサをセットアップしていて、loadBalancer.seesaw.disableVRRPMAC を false に設定している場合は、ロードバランサのポートグループで、MAC ラーニング、偽装送信、無作為モードの組み合わせを有効化する必要があります。

こうした機能を有効にする方法は、スイッチのタイプによって異なります。

スイッチのタイプ機能の有効化セキュリティへの影響
vSphere 7.0 VDS vSphere 7.0 HA では、loadBalancer.seesaw.disableVRRPMAC を true に設定する必要があります。MAC ラーニングはサポートされていません。
vSphere 6.7 と VDS 6.6

次のコマンドを実行し、ロードバランサの MAC ラーニングと偽造送信を有効にします。gkectl prepare network --config [CONFIG_FILE]。ここで、[CONFIG_FILE] はクラスタ構成ファイルのパスです。これを行うには、dvPort group.Modify 権限が必要です。

 最小。ロードバランサ ポートグループが Seesaw VM にのみ接続されている場合、MAC ラーニングを信頼できる Seesaw VM のみに制限できます。

vSphere 6.5 または

VDS のバージョンが 6.6 より前のバージョンの vSphere 6.7

 ロードバランサ ポートグループの無作為モードと偽造転送を有効にします。[ネットワーキング] タブのポートグループ ページで vSphere のユーザー インターフェースを使用します（[設定を編集] -> [セキュリティ]）。 ロードバランサ ポートグループのすべての VM は無作為モードです。そのため、ロードバランサ ポートグループのどの VM もすべてのトラフィックを表示できます。ロードバランサ ポートグループが Seesaw VM にのみ接続されている場合、すべてのトラフィックを表示できるのはそれらの VM のみです。
NSX-T 論理スイッチ 論理スイッチで MAC ラーニングを有効化します。 vSphere は、同じレイヤ 2 ドメインに 2 つの論理スイッチを作成することをサポートしていません。そのため、Seesaw VM とクラスタノードは同じ論理スイッチ上にある必要があります。これは、すべてのクラスタノードで MAC ラーニングが有効であることを意味します。攻撃者がクラスタ内で特権 Pod を運用中にすることで、MAC なりすましを実現できる可能性があります。
vSphere Standard Switch ロードバランサ ポートグループの無作為モードと偽造転送を有効にします。各 ESXI ホストで vSphere のユーザー インターフェースを使用します（[構成] -> [仮想スイッチ] -> [Standard Switch] -> [ポートグループの設定を編集] -> [セキュリティ]）。 ロードバランサ ポートグループのすべての VM は無作為モードです。そのため、ロードバランサ ポートグループのどの VM もすべてのトラフィックを表示できます。ロードバランサ ポートグループが Seesaw VM にのみ接続されている場合、すべてのトラフィックを表示できるのはそれらの VM のみです。

管理クラスタ構成ファイルの入力を完了する

管理クラスタの作成の手順に沿って、管理クラスタの構成ファイルの入力を完了します。

プリフライト チェックを実行する

管理クラスタ構成ファイルのプリフライト チェックを実行します。

gkectl check-config --config ADMIN_CLUSTER_CONFIG

ADMIN_CLUSTER_CONFIG は、管理クラスタ構成ファイルのパスで置き換えます。

OS イメージのアップロード

OS イメージを vSphere 環境にアップロードします。

gkectl prepare --config ADMIN_CLUSTER_CONFIG

管理クラスタのロードバランサを作成する

gkectl create loadbalancer --config [ADMIN_CLUSTER_CONFIG]

管理クラスタを作成する

管理クラスタの作成の手順に沿って、管理クラスタを作成します。

ユーザー クラスタ構成ファイルの入力を完了する

ユーザー クラスタを作成するの手順に沿って、ユーザー クラスタ構成ファイルの入力を完了します。

プリフライト チェックを実行する

ユーザー クラスタ構成ファイルのプリフライト チェックを実行します。

gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

次のように置き換えます。

  • ADMIN_CLUSTERE_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス

  • USER_CLUSTER_CONFIG: ユーザー クラスタの構成ファイルのパス

OS イメージのアップロード

OS イメージを vSphere 環境にアップロードします。

gkectl prepare --config USER_CLUSTER_CONFIG

ユーザー クラスタにロードバランサを作成する

ユーザー クラスタにロードバランサを作成する

gkectl create loadbalancer --config USER_CLUSTER_CONFIG

ユーザー クラスタを作成する

ユーザー クラスタを作成するの手順に沿ってユーザー クラスタを作成します。

パフォーマンスと負荷テスト

アプリケーションのダウンロード スループットは、バックエンドの数に比例します。これは、ロードバランサを迂回し、Direct Server Return を使用して、バックエンドがクライアントに直接レスポンスを送信するためです。

対照的に、アプリケーションのアップロード スループットは、負荷分散を実行する 1 つの Seesaw VM の処理能力によって制限されます。

必要な CPU とメモリの量はアプリケーションによって異なるため、多数のクライアントへの運用を開始する前に負荷テストを行うことが非常に重要です。

テストでは、6 個の CPU と 3 GB のメモリを備えた 1 つの Seesaw VM が、10 K の同時 TCP 接続で 10 GB/秒（ラインレート）のアップロードのトラフィックを処理できることが示されています。ただし、多数の同時 TCP 接続のサポートを計画している場合は、独自の負荷テストを実行することが重要です。

スケーリングの上限

バンドル型負荷分散では、クラスタのスケーリングに上限があります。クラスタ内のノード数には上限があり、ロードバランサで構成できるサービス数にも上限があります。ヘルスチェックにも上限があります。ヘルスチェック数は、ノード数とサービス数の両方に依存します。

バージョン 1.3.1 以降では、ヘルスチェックの数はノードの数とトラフィックのローカル サービスの数によって異なります。トラフィックのローカル サービスは、externalTrafficPolicy が "Local" に設定された Service です。

バージョン 1.3.0バージョン 1.3.1 以降
最大サービス数（S）100500
最大ノード数（N）100100
最大ヘルスチェック数S * N <= 10KN + L * N <= 10K、L はトラフィックのローカル サービス数

例: バージョン 1.3.1 では、100 個のノードと 99 個のトラフィックのローカル サービスがあります。この場合、ヘルスチェックの数は 100 + 99 × 100 = 10,000 となります。これは上限 10,000 の範囲内です。

クラスタのロードバランサのアップグレード

クラスタをアップグレードすると、ロードバランサは自動的にアップグレードされます。ロードバランサをアップグレードするために別のコマンドを実行する必要はありません。ロードバランサが HA モードの場合、GKE on VMware はローリング方式でロードバランサ VM を再作成します。アップグレード中のサービスが中断しないように、クラスタは新しい VM を作成する前にフェイルオーバーを開始します。

必要な場合は、完全にアップグレードせずに Seesaw VM の CPU やメモリを更新できます。まず、クラスタ構成ファイルの cpus 値と memoryMB 値を編集します。次に例を示します。

apiVersion: v1
bundlePath:
loadBalancer:
  kind: Seesaw
  seesaw:
    cpus: 3
    memoryMB: 3072

次に、管理クラスタのロードバランサを更新するために、以下の処理を行います。

gkectl upgrade loadbalancer --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG --admin-cluster
 ユーザー クラスタのロードバランサを更新します。
gkectl upgrade loadbalancer --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG

次のように置き換えます。

  • ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス

  • ADMIN_CLUSTER_CONFIG は、管理クラスタ構成ファイルのパス

  • USER_CLUSTER_CONFIG: ユーザー クラスタの構成ファイルのパス

Seesaw のログの表示

Seesaw がバンドルされたロードバランサでは、Seesaw VM のログファイルが /var/log/seesaw/ に保存されます。最も重要なログファイルは seesaw_engine.INFO です。

v1.6 以降で Stackdriver が有効になっている場合、ログも Cloud にアップロードされます。このようなリソースは anthos_l4lb リソースで確認できます。ログのアップロードを無効にするには、SSH で VM に接続し、次のコマンドを実行します。

sudo systemctl disable --now docker.fluent-bit.service

Seesaw VM に関する情報を表示する

クラスタの Seesaw VM に関する情報は、SeesawGroup のカスタム リソースから取得できます。

クラスタの SeesawGroup のカスタム リソースを表示します。

kubectl --kubeconfig CLUSTER_KUBECONFIG get seesawgroups -n kube-system -o yaml

CLUSTER_KUBECONFIG は、クラスタの kubeconfig ファイルのパスに置き換えます。

出力には、VM がトラフィックを処理できる状態かどうかを示す isReady フィールドがあります。出力には、Seesaw VM の名前と IP アドレス、およびどの VM がプライマリであるかも表示されます。

apiVersion: seesaw.gke.io/v1alpha1
kind: SeesawGroup
metadata:
  ...
  name: seesaw-for-cluster-1
  namespace: kube-system
  ...
spec: {}
status:
  machines:
  - hostname: cluster-1-seesaw-1
    ip: 172.16.20.18
    isReady: true
    lastCheckTime: "2020-02-25T00:47:37Z"
    role: Master
  - hostname: cluster-1-seesaw-2
    ip: 172.16.20.19
    isReady: true
    lastCheckTime: "2020-02-25T00:47:37Z"
    role: Backup

Seesaw 指標を表示する

Seesaw がバンドルされたロードバランサには次の指標があります。

  • サービスまたはノードあたりのスループット
  • サービスまたはノードあたりのパケットレート
  • サービスまたはノードあたりのアクティブな接続の数
  • CPU とメモリの使用状況
  • サービスあたりの正常なバックエンド Pod の数
  • プライマリ VM とバックアップ VM
  • 稼働率

v1.6 以降では、これらの指標が Stackdriver で Cloud にアップロードされます。これらのリソースは、anthos_l4lb のモニタリング リソースで確認できます。

Prometheus 形式がサポートされている限り、任意のモニタリング ソリューションとダッシュボード ソリューションを使用できます。

ロードバランサの削除

バンドルされた負荷分散を使用するクラスタを削除する場合は、そのクラスタの Seesaw VM を削除する必要があります。これを行うには、vSphere ユーザー インターフェースで Seesaw VM を削除します。

別の方法として、gkectl delete loadbalancer を実行することもできます。

管理クラスタの場合は、次のコマンドを実行します。

gkectl delete loadbalancer --config ADMIN_CLUSTER_CONFIG --seesaw-group-file GROUP_FILE

ユーザー クラスタの場合は、次のコマンドを実行します。

gkectl delete loadbalancer  --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG \
    --seesaw-group-file GROUP_FILE

次のように置き換えます。

  • ADMIN_CLUSTER_CONFIG: 管理クラスタの構成ファイルのパス

  • USER_CLUSTER_CONFIG: ユーザー クラスタの構成ファイルのパス

  • ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス

  • GROUP_FILE: Seesaw グループ ファイルのパス。グループ ファイルの名前の形式は
    seesaw-for-CLUSTER_NAME-IDENTIFIER.yamlです。
    例: seesaw-for-gke-admin-12345.yaml

Seesaw ロードバランサで使用するためのステートレス NSX-T 分散ファイアウォール ポリシーの構成

構成でステートフル NSX-T 分散ファイアウォールを使用していて、Seesaw ロードバランサも使用する場合は、方法がいくつかあります。ご使用の環境に最も合う方法を選択してください。

NSX 構成チェックリスト

ここで説明する修復方法を実行する前に、次の NSX DFW 構成が設定されていることを確認してください。

  • ステートフル NSX DFW セクションがデフォルトの構成です。これはおそらく環境内にあります。ファイアウォール セクションとファイアウォール ルールをご覧ください。

  • サービス挿入は、パートナー インテグレーションの一環としてサービス チェイニングと L7 検査を提供するために、NSX DFW とともに使用されることがあります。サービス挿入ポリシーもデフォルトではステートフルです。このインテグレーションがご利用の環境で有効になっているかどうかを確認するには、こちらの情報をご覧ください。

方法 1 - Seesaw ロードバランサのステートレス分散ファイアウォール ポリシーを作成する

このオプションを使用すると、Anthos インフラストラクチャ（特に Seesaw ロードバランサ）をステートレス ポリシーにマッピングしながら、分散ファイアウォールを環境で有効にすることができます。ステートレス ファイアウォールとステートフル ファイアウォールの違いを考慮して、環境に最適なタイプを選択してください。VMware ドキュメントのマネージャー モードのファイアウォール ルールの追加 - 手順 - ステップ 6 をご覧ください。

ステートレス ファイアウォール ポリシーを作成するには:

  1. [インベントリ] > [タグ] に移動します。seesaw という名前のタグを作成します。

  2. [Inventory] > [Groups] に移動します。Seesaw という名前のグループを作成します。

  3. Seesaw セットのメンバーを構成します。

    • [Set Members] をクリックします。作成した seesaw タグに基づいて、[Membership Criteria] でセットメンバーを構成します。一般的に、NSX タグを使用することは、VMware によりベスト プラクティスと考えられていますが、この方法では、環境内の Anthos クラスタをアップグレードまたはサイズ変更する場合など、環境が変更されるたびにこれらを設定する自動化が必要です。そうなると、他のメンバーシップ条件に基づくポリシーの方が適しています。他の動的メンバーシップの方法（VM 名（正規表現を含む）、セグメント、セグメント ポートなど）を使用できます。グループ メンバーシップ条件の詳細については、グループを追加するをご覧ください。

  4. [Security] > [Distributed Firewall] に移動します。Anthos という名前のセクションを作成します。

  5. 右上の歯車アイコンをクリックし、[Stateful] スイッチを [No] に切り替えます。

  6. このセクションにルールを追加します。少なくとも 2 つの対称ルールを使用することをおすすめします。次に例を示します。

    Source: Seesaw Group, Destination: Any, Applied to: Seesaw Group
Source: Any, Destination: Seesaw Group, Applied to: Seesaw Group

  7. 変更を公開して、オペレーションを確認します。

ステートレス セクションは、ステートフルの方法で同じトラフィックを許可（ステートレス ルールをマスキング）する他のセクションよりも優先されるように、NSX DFW テーブルに配置する必要があります。ステートレス セクションが最も具体的で、さらに、重なる可能性がある他のポリシーよりもステートレス セクションが優先されるようにします。

必須ではありませんが、すべての Anthos VM を含むグループを作成するには、Segment タグなどの大まかなメンバーシップ条件を使用します。つまり、特定の NSX ネットワークに接続されたすべての VM がそのグループに含まれます。そうすると、ステートレス ポリシーでこのグループを使用できます。

方法 2 - Seesaw VM を分散ファイアウォール除外リストに追加する

このオプションを使用すると、NSX DFW を無効にすることなく、分散ファイアウォール検査から VM を完全に除外できます。ファイアウォール除外リストの管理をご覧ください。

  1. [Security] > [Distributed Firewall] に移動します。[Actions] > [Exclusion List] を選択します。

  2. Seesaw グループ、つまりすべての Anthos VM を含むグループを選択します。

トラブルシューティング

Seesaw VM への SSH 接続の確立

場合によっては、Seesaw VM に SSH 接続してトラブルシューティングやデバッグを行うこともあります。

SSH 認証鍵の取得

クラスタをすでに作成している場合は、次の手順で SSH 認証鍵を取得します。

  1. クラスタから seesaw-ssh Secret を取得します。Secret から SSH 認証鍵を取得し、base64 でデコードします。デコードした鍵を一時ファイルに保存します。

    kubectl --kubeconfig CLUSTER_KUBECONFIG get -n  kube-system secret seesaw-ssh -o \
jsonpath='{@.data.seesaw_ssh}' | base64 -d | base64 -d > /tmp/seesaw-ssh-key

    CLUSTER_KUBECONFIG は、クラスタの kubeconfig ファイルのパスに置き換えます。

  2. 鍵のファイルに適切な権限を設定します。

    chmod 0600 /tmp/seesaw-ssh-key

    クラスタをまだ作成していない場合は、次の手順で SSH 認証鍵を取得します。

  3. seesaw-for-CLUSTER_NAME-IDENTIFIER.yaml という名前のファイルを見つけます。

    このファイルはグループ ファイルと呼ばれ、config.yaml の横にあります。

    また、gkectl create loadbalancer でグループ ファイルの場所が表示されます。

  4. ファイルで credentials.ssh.privateKey の値を取得し、base64 でデコードします。デコードした鍵を一時ファイルに保存します。

    cat seesaw-for-CLUSTER_NAME-IDENTIFIER.yaml  | grep privatekey | sed 's/    privatekey: //g' \
| base64 -d > /tmp/seesaw-ssh-key

  5. 鍵のファイルに適切な権限を設定します。

    chmod 0600 /tmp/seesaw-ssh-key

これで、Seesaw VM に SSH 接続できるようになりました。

ssh -i /tmp/seesaw-ssh-key ubuntu@SEESAW_IP

SEESAW_IP は、Seesaw VM の IP アドレスに置き換えます。

スナップショットを取得する

--scenario フラグと一緒に gkectl diagnose snapshot コマンドを使用すると、Seesaw VM のスナップショットがキャプチャできます。

--scenario を all や all-with-logs に設定した場合、出力には Seesaw スナップショットと他のスナップショットが含まれます。

--scenario を seesaw に設定した場合、出力には Seesaw スナップショットのみが含まれます。

例:

gkectl diagnose snapshot --kubeconfig ADMIN_CLUSTER_KUBECONFIG --scenario seesaw

gkectl diagnose snapshot --kubeconfig ADMIN_CLUSTER_KUBECONFIG --cluster-name CLUSTER_NAME --scenario seesaw

gkectl diagnose snapshot --seesaw-group-file GROUP_FILE --scenario seesaw

次のように置き換えます。

  • ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス

  • GROUP_FILE: クラスタ用のグループ ファイルのパス。

破損した状態から Seesaw VM を再作成する

Seesaw VM が誤って削除された場合は、--no-diff フラグと --force フラグを指定して gkectl upgrade loadbalancer コマンドを使用すると、VM を再作成できます。これにより、存在やヘルス ステータスに関係なく、クラスタ内のすべての Seesaw VM が再作成されます。ロードバランサが HA モードであり、2 つの VM のうち 1 つだけが削除されている場合は、このコマンドを実行すると両方の VM が再作成されます。

たとえば、管理クラスタで Seesaw ロードバランサを再作成するには、次のコマンドを実行します。

gkectl upgrade loadbalancer --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG --admin-cluster --no-diff --force

ユーザー クラスタで Seesaw ロードバランサを再作成するには、次のコマンドを実行します。

gkectl upgrade loadbalancer --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG --no-diff --force

次のように置き換えます。

  • ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス

  • ADMIN_CLUSTER_CONFIG は、管理クラスタ構成ファイルのパス

  • USER_CLUSTER_CONFIG: ユーザー クラスタの構成ファイルのパス

既知の問題

Cisco ACI は Direct Server Return（DSR）と連動しない

Seesaw は DSR モードで動作します。デフォルトでは、データプレーン IP 学習が原因で Cisco ACI では機能しません。アプリケーション エンドポイント グループを使用した可能な回避策については、こちらをご覧ください。

Citrix Netscaler は Direct Server Return（DSR）と連動しない

Seesaw の前に Netscaler ロードバランサを実行する場合は、MAC ベースの転送（MBF）をオフにする必要があります。Citrix のドキュメントをご覧ください。

Seesaw ロードバランサをアップグレードできない場合がある

DHCP モードや、IPAM モードでは、1.8.0 からクラスタをアップグレードすることおよび、gkectl upgrade loadbalancer を使用してバージョン 1.8.0 の Seesaw ロードバランサのパラメータを更新することはできません。今後のバージョンで修正が発表されるのを待ってアップグレードしてください。