バージョン 1.8このバージョンは、Anthos バージョンサポートポリシーに記載されているようにサポートされており、Anthos clusters on VMware（GKE On-Prem）に影響を与えるセキュリティの脆弱性、露出、問題に関する最新のパッチとアップデートが提供されます。詳細については、リリースノートをご覧ください。これは最新バージョンではありません。

利用可能なバージョン: 1.11 1.10 1.9 以前のバージョン

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

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

Anthos clusters on VMware が提供するバンドル型ロードバランサは、Seesaw ロードバランサです。

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

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

このドキュメントでは、管理クラスタと 1 つの関連するユーザークラスタに対してバンドル型ロードバランシングを構成する方法について説明します。

バンドル型負荷分散モードの利点

バンドル型負荷分散モードには、手動負荷分散モードに比べて次のような利点があります。

単一のチームがクラスタの作成とロードバランサの構成の両方を担当できます。たとえば、クラスタ管理チームは、事前にロードバランサの取得、実行、構成を別のネットワーキングチームに頼む必要はありません。
Anthos clusters on VMware は、ロードバランサ上で仮想 IP アドレス（VIP）を自動的に構成します。クラスタの作成時に、Anthos clusters on VMware は Kubernetes API サーバー、Ingress サービス、クラスタアドオンの VIP を使用してロードバランサを構成します。クライアントが LoadBalancer タイプの Service を作成すると、Anthos clusters on VMware はロードバランサ上に Service の VIP を自動的に構成します。
組織、グループ、管理者の間の依存関係が軽減されます。特に、クラスタを管理するグループは、ネットワークを管理するグループにあまり依存しないようになります。

Virtual Router Redundancy Protocol

Seesaw ロードバランサは、単一の VM で実行することも、2 つの VM を使用する高可用性（HA）モードで実行することもできます。HA モードでは、Seesaw ロードバランサは Virtual Router Redundancy Protocol（VRRP）を使用します。その 2 つの VM は、マスターとバックアップと呼ばれます。各 Seesaw VM には、任意の仮想ルーター ID（VRID）を指定します。

VLAN の計画

この演習では、管理クラスタと 1 つのユーザークラスタを作成します。バンドル型負荷分散モードでは、クラスタを別々の 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

仮想 IP アドレスの確保

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

管理クラスタ VIP

管理クラスタの Kubernetes API サーバー用に VIP を確保します。管理クラスタの構成ファイルでは、これを controlPlaneVIP とします。この VIP は、管理クラスタノードと、管理クラスタ用 Seesaw VM と同じ VLAN 上にある必要があります。

管理クラスタ内のアドオン用に VIP を確保します。管理クラスタの構成ファイルでは、これを addonsVIP と呼びます。この VIP は、管理クラスタノードと、管理クラスタ用 Seesaw VM と同じ VLAN 上にある必要があります。

ユーザークラスタ VIP

ユーザークラスタの Kubernetes API サーバー用に VIP を確保します。ユーザークラスタの構成ファイルでは、これを controlPlaneVIP と呼びます。この VIP は、管理クラスタノードと、管理クラスタ用 Seesaw VM と同じ VLAN 上にある必要があります。これは、ユーザークラスタの Kubernetes API サーバーが管理クラスタ内のノードで実行されるためです。

ユーザークラスタに Ingress 用の VIP を確保します。ユーザークラスタの構成ファイルでは、これを ingressVIP と呼びます。この VIP は、ユーザークラスタノードと、ユーザークラスタ用 Seesaw VM と同じ VLAN 上にある必要があります。

ノード IP アドレスの確保

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

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

Seesaw VM の IP アドレスの確保

次に、Seesaw ロードバランサを実行する VM の IP アドレスを確保します。

確保するアドレスの数は、HA Seesaw ロードバランサか非 HA Seesaw ロードバランサを作成するかによって異なります。

ケース 1: HA Seesaw ロードバランサ

管理クラスタでは、Seesaw VM のペア用に 2 つの IP アドレスを確保します。また、管理クラスタでは、Seesaw VM のペア用に単一のマスター IP アドレスを確保します。これら 3 つのアドレスはすべて、管理クラスタノードと同じ VLAN 上にある必要があります。

ユーザークラスタでは、ペアの Seesaw VM 用に IP アドレスを 2 つ確保します。また、Seesaw VM のペアに、マスター IP アドレスを 1 つ確保します。この 3 つのアドレスはすべて、ユーザークラスタノードと同じ VLAN 上になければなりません。

ケース 2: 非 HA Seesaw ロードバランサ

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

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

ポートグループの計画

Seesaw VM ごとに 2 つのネットワークインターフェースがあります。マスター Seesaw VM の場合、そうしたネットワークインターフェースの 1 つは VIP で構成され、もう 1 つのネットワークインターフェースは指定した IP ブロックファイルから取得した IP アドレスで構成されます。バックアップ Seesaw VM の場合、IP ブロックファイルから取得した IP アドレスで 1 つのインターフェースが構成され、他のネットワークインターフェースには何も構成されません。

個々の Seesaw VM では、2 つのネットワークインターフェースを同じ vSphere ポートグループに接続することも、別々のポートグループに接続することもできます。ポートグループが別々の場合は、同じ VLAN 上にある必要があります。

このトピックでは、次の 2 つのポートグループを参照します。

ロードバランサポートグループ: Seesaw VM の場合、VIP で構成されたネットワークインターフェースがこのポートグループに接続されます。
クラスタノードポートグループ: Seesaw VM の場合、IP ブロックファイルから取得された IP アドレスで構成されるネットワークインターフェースがこのポートグループに接続されます。クラスタノードも、このポートグループに接続されます。

ロードバランサポートグループとクラスタノードポートグループは同じものにできます。ただし、これらは別々にすることを強くおすすめします。

次の図では、Seesaw 負荷分散の推奨ネットワーク構成を示します。

Seesaw ロードバランサのネットワークを示す図。 ^{VLAN 上の VM とクラスタノード}

上の図は、1 つのクラスタ（管理クラスタまたはユーザークラスタ）を示しています。各クラスタは独自の VLAN に配置することをおすすめします。

この図では、次のネットワークの特性を確認できます。

2 つの Seesaw VM、1 つのマスターと 1 つバックアップがあります。
Seesaw VM はクラスタノードと同じ VLAN 上にあります。
バックアップ Seesaw VM には、ネットワークインターフェースが 2 つあります。一方のインターフェースは、Seesaw IP ブロックファイルから取得した IP アドレスで構成されます。もう一方のインターフェースには、IP アドレスは構成されません。
マスター Seesaw VM には、ネットワークインターフェースが 2 つあります。一方のインターフェースは、Seesaw IP ブロックファイルから取得した IP アドレスで構成されます。他のインターフェースは VIP で構成されます。
各 Seesaw VM では、1 つのネットワークインターフェースがロードバランサのポートグループに接続されています。図の他のすべてのネットワークインターフェースが、クラスタノードポートのグループに接続されています。

図に示されているネットワークインターフェースで構成されているすべての IP アドレス（VIP を含む）は、VLAN にルーティング可能である必要があります。

管理クラスタの場合、Seesaw マスター VM 上の VIP インターフェースは、次の IP アドレスで構成されます。

管理クラスタのマスター Seesaw VM の VIP
管理クラスタのアドオン VIP
管理クラスタのコントロールプレーン VIP
ユーザークラスタのコントロールプレーン VIP
管理クラスタで実行されている LoadBalancer タイプの Service の VIP

ユーザークラスタの場合、Seesaw マスター VM 上の VIP インターフェースは、次の IP アドレスで構成されます。

ユーザークラスタのマスター Seesaw VM の VIP
ユーザークラスタの上り（内向き）VIP
ユーザークラスタで実行されている LoadBalancer タイプの Service の VIP

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

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

blocks:
  - netmask: "255.255.255.0"
    gateway: "172.16.20.1"
    ips:
    - ip: "172.16.20.18"
      hostname: "seesaw-vm-1"
    - ip: "172.16.20.19"
      hostname: "seesaw-vm-2"

構成ファイルの入力

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

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

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

loadBalancer:
  kind: Seesaw
  seesaw:
    ipBlockFilePath:
    vrid:
    masterIP:
    cpus:
    memoryMB:
    vCenter:
      networkName:
    enableHA:
    disableVRRPMAC:

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

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）	100	500
最大ノード数（N）	100	100
最大ヘルスチェック数	S * N <= 10K	N + L * N <= 10K、L はトラフィックのローカルサービス数

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

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

クラスタをアップグレードすると、ロードバランサは自動的にアップグレードされます。ロードバランサをアップグレードするために別のコマンドを実行する必要はありません。

必要な場合は、完全にアップグレードせずに 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 VM への SSH 接続の確立

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

SSH 認証鍵の取得

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

クラスタから 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 ファイルのパスに置き換えます。
鍵のファイルに適切な権限を設定します。
```
chmod 0600 /tmp/seesaw-ssh-key
```

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

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

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

また、gkectl create loadbalancer でグループファイルの場所が表示されます。
ファイルで credentials.ssh.privateKey の値を取得し、base64 でデコードします。デコードした鍵を一時ファイルに保存します。
```
cat seesaw-for-CLUSTER_NAME-IDENTIFIER.yaml  | grep privatekey | sed 's/    privatekey: //g' \
| base64 -d > /tmp/seesaw-ssh-key
```
鍵のファイルに適切な権限を設定します。
```
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: クラスタ用のグループファイルのパス。

既知の問題

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

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

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

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

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

バンドル型負荷分散モードの利点

おすすめのバージョン

Virtual Router Redundancy Protocol

VLAN の計画

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

仮想 IP アドレスの確保

管理クラスタ VIP

ユーザー クラスタ VIP

ノード IP アドレスの確保

Seesaw VM の IP アドレスの確保

ケース 1: HA Seesaw ロードバランサ

ケース 2: 非 HA Seesaw ロードバランサ

ポートグループの計画

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

構成ファイルの入力

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

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

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

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

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

管理クラスタを作成する

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

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

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

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

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

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

スケーリングの上限

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

Seesaw のログの表示

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

Seesaw 指標を表示する

ロードバランサの削除

トラブルシューティング

Seesaw VM への SSH 接続の確立

SSH 認証鍵の取得

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

既知の問題

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

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

ユーザークラスタ VIP

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

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

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

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

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

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