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

管理クラスタを HA に移行する

このドキュメントでは、非 HA 管理クラスタから高可用性（HA）管理クラスタに移行する方法について説明します。

1.29: プレビュー
1.28: 利用不可
1.16: 利用不可

HA 管理クラスタには 3 つのコントロールプレーンノードがあり、アドオンノードはありません。非 HA 管理クラスタには、1 つのコントロールプレーンノードと 2 つのアドオンノードがあります。

手順の概要

移行に関わる主な手順は次のとおりです。

管理クラスタの構成ファイルを編集します。
gkectl update admin を実行します。このコマンドは次の処理を行います。
- 外部クラスタ（Kind）を起動し、現在の HA 以外の管理クラスタが正常な状態であることを確認します。
- HA 仕様と新しいコントロールプレーン VIP を使用して、新しい管理クラスタコントロールプレーンを作成します。
- 既存の管理クラスタコントロールプレーンをオフにします。
- 既存の管理クラスタの etcd のスナップショットを作成します。
- 新しい HA コントロールプレーンに古い管理クラスタデータを復元します。
- HA 管理クラスタの最終状態に合わせて、復元された管理クラスタを調整します。

メモ

移行中、ユーザークラスタのワークロードのダウンタイムは発生しません。
移行中は、管理クラスタのコントロールプレーンでダウンタイムが発生します。（テストに基づくと、ダウンタイムは 18 分未満ですが、実際の長さは個々のインフラ環境によって異なります）。
HA 管理クラスタの要件は、非 HA から HA への移行でも当てはまります。つまり、非 HA 管理クラスタに Seesaw ロードバランサを使用している場合は、まず MetalLB に移行してから HA 管理クラスタに移行する必要があります。これは、HA 管理クラスタが Seesaw をサポートしていないためです。
移行が正常に完了すると、障害復旧のために意図的に残したリソース（非 HA 管理マスター VM など）が存在します。必要に応じて手動でクリーンアップできます。

移行前と移行後

移行前と移行後のクラスタの主な違いは次のとおりです。

	移行前	移行後
コントロールプレーンノードのレプリカ	1	3
アドオンノード	2	0
コントロールプレーン Pod レプリカ（kube-apiserver、kube-etcd など）	1	3
データディスクのサイズ	100GB * 1	25GB * 3
データディスクのパス	管理クラスタ構成ファイルの vCenter.dataDisk によって設定される	ディレクトリの下に自動生成される: `/anthos/[ADMIN_CLUSTER_NAME]/default/[MACHINE_NAME]-data.vmdk`
コントロールプレーン VIP のロードバランサ	管理クラスタ構成ファイルの loadBalancer.kind によって設定される	`keepalived` + `haproxy`
管理クラスタのコントロールプレーンノードの IP アドレスの割り振り	DHCP または静的（network.ipMode.type によって異なる）	3 個の静的 IP アドレス
kubeception ユーザークラスタコントロールプレーンノードの IP アドレスの割り振り	DHCP または静的（network.ipMode.type によって異なる）	DHCP または静的（network.ipMode.type によって異なる）
チェックポイントファイル	デフォルトで有効	不使用

管理クラスタの構成ファイルを編集する

さらに 4 つの IP アドレスを指定する必要があります。

管理クラスタのコントロールプレーンノード用の 3 つの IP アドレス
管理クラスタロードバランサの新しいコントロールプレーン VIP

また、管理クラスタ構成ファイルの他のフィールドも変更する必要があります。

IP アドレスを指定する

管理クラスタの構成ファイルで、network.controlPlaneIPBlock セクションに入力します。次に例を示します。

controlPlaneIPBlock:
 netmask: "255.255.255.0"
 gateway: "172.16.20.1"
 ips:
 – ip: "172.16.20.50"
   hostname: "admin-cp-node-1"
 – ip: "172.16.20.51"
   hostname: "admin-cp-node-2"
 – ip: "172.16.20.52"
   hostname: "admin-cp-node-3"

hostconfig セクションに入力します。管理クラスタで静的 IP アドレスを使用している場合、このセクションはすでに入力されています。次に例を示します。
```
hostConfig:
 dnsServers:
 – 203.0.113.1
 – 198.51.100.1
 ntpServers:
 – 216.239.35.12
```
loadBalancer.vips.controlPlaneVIP の値を新しい VIP に置き換えます。次に例を示します。
```
loadBalancer:
 vips:
   controlPlaneVIP: "172.16.20.59"
```

追加の構成フィールドを更新する

adminMaster.replicas を 3 に設定します。

adminMaster:
 replicas: 3
 cpus: 4
 memoryMB: 8192

vCenter.dataDisk フィールドを削除します。これは、HA 管理クラスタの場合、コントロールプレーンノードで使用される 3 つのデータディスクのパスが、データストアのルートディレクトリ anthos の下に自動的に生成されるためです。
loadBalancer.manualLB.controlPlaneNodePort にゼロ以外の値がある場合は、0 に設定します。

手動ロードバランサの構成を調整する

管理クラスタで手動ロードバランシングを使用している場合は、このセクションの手順を行います。それ以外の場合は、このセクションをスキップします。

network.controlPlaneIPBlock セクションで指定した 3 つの新しいコントロールプレーンノードの IP アドレスのそれぞれについて、ロードバランサでこのマッピングを構成します。

（以前の controlPlaneVIP:443）->（NEW_NODE_IP_ADDRESS:以前の controlPlaneNodePort）

これにより、移行中に古いコントロールプレーン VIP が機能します。

管理クラスタを更新する

移行を開始する:
```
gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG
```
次のように置き換えます。
- ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス
- ADMIN_CLUSTER_CONFIG: 管理クラスタの構成ファイルのパス
このコマンドによって移行の進行状況が表示されます。

指示に従って、「Y」と入力して次に進みます。
移行が完了すると、新しいコントロールプレーン VIP を使用するように管理クラスタの kubeconfig ファイルが自動的に更新されます。一方、古いコントロールプレーン VIP は引き続き機能し、新しい HA 管理クラスタへのアクセスにも使用できます。

必要に応じて残りのリソースを手動でクリーンアップする

移行中、gkectl は管理クラスタのコントロールプレーン VM を削除しません。vSphere から削除されず、VM がシャットダウンされるだけです。移行が正常に完了した後に古いコントロールプレーン VM を削除するには、手動で削除する必要があります。

古いコントロールプレーン VM と関連リソースを手動で削除するには:

非 HA 管理マスター VM gke-admin-master-xxx の電源がすでにオフであることを確認します。
vSphere から非 HA 管理マスター VM gke-admin-master-xxx を削除します。
非 HA 管理マスター VM テンプレート gke-admin-master-xxx-tmpl を vSphere から削除します。
HA 以外の管理データディスクと管理チェックポイントファイルを削除します。
/home/ubuntu/admin-ha-migration/[ADMIN_CLUSTER_NAME]/ に保存されている一時ファイルをクリーンアップします。

cli を使う場合は、以下の govc コマンドをご覧ください。

  // Configure govc credentials
  export GOVC_INSECURE=1
  export GOVC_URL=VCENTER_URL
  export GOVC_DATACENTER=DATACENTER
  export GOVC_DATASTORE=DATASTORE
  export GOVC_USERNAME=USERNAME
  export GOVC_PASSWORD=PASSWORD

  // Configure admin master VM name (you can find the master VM name from the "[HA Migration]" logs)
  export ADMIN_MASTER_VM=ADMIN_MASTER_VM_NAME

  // Configure datadisk path (remove ".vmdk" suffix)
  export DATA_DISK_PATH=DATADISK_PATH_WITHOUT_VMDK

  // Check whether admin master is in "poweredOff" state:
  govc vm.info $ADMIN_MASTER_VM | grep Power

  // Delete admin master VM
  govc vm.destroy $ADMIN_MASTER_VM

  // Delete admin master VM template
  govc vm.destroy "$ADMIN_MASTER_VM"-tmpl

  // Delete data disk
  govc datastore.ls $DATA_DISK_PATH
  govc datastore.rm $DATA_DISK_PATH

  // Delete admin checkpoint file
  govc datastore.ls "$DATA_DISK_PATH"-checkpoint.yaml
  govc datastore.rm "$DATA_DISK_PATH"-checkpoint.yaml