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

このページでは、バージョン 1.29 の非高可用性管理クラスタから高可用性（HA）管理クラスタに移行する方法について説明します。

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

移行前と移行後、管理クラスタには次の 3 つのノードがあります。

非 HA 管理クラスタには 1 つのコントロールプレーンノードと 2 つのアドオンノードがあります。
HA 管理クラスタには 3 つのコントロールプレーンノードがあり、アドオンノードはありません。そのため、可用性が大幅に向上します。

移行を準備する

管理クラスタのバージョンが 1.29.0～1.29.600 または 1.30.0～1.30.100 であり、バージョン 1.14 以前の管理クラスタで Secret の常時暗号化が有効になっていた場合は、移行を開始する前に暗号鍵をローテーションする必要があります。そうしないと、新しい HA 管理クラスタは Secret を復号できません。

古い暗号鍵がクラスタで使用されている可能性があるかどうかを確認するには:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secret -n kube-system admin-master-component-options -o jsonpath='{.data.data}' | base64 -d | grep -oP '"GeneratedKeys":\[.*?\]'

次の例のように、空の鍵が出力に表示される場合、暗号鍵をローテーションする必要があります。

"GeneratedKeys":[{"KeyVersion":"1","Key":""}]

必要に応じて暗号鍵をローテーションする

前のセクションの手順で、暗号鍵をローテーションする必要があるとわかった場合は、次の手順で操作します。

管理クラスタ構成ファイルで keyVersion の値をインクリメントします。
管理クラスタを更新します。
```
gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config ADMIN_CLUSTER_CONFIG
```
これにより、新しいバージョン番号と一致する新しい鍵が作成され、各 Secret が再暗号化されて、古い Secret が安全に消去されます。後続のすべての新しい Secret は、新しい暗号鍵を使用して暗号化されます。

手順の概要

移行の主な手順は次のとおりです。

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

メモ

移行中、ユーザークラスタのワークロードはダウンタイムなしで実行されます。
移行中、管理クラスタのコントロールプレーンでダウンタイムが発生します（Google のテストではダウンタイムは 18 分未満ですが、実際の長さは個々のインフラストラクチャ環境によって異なります）。
HA 管理クラスタの要件は、非 HA から HA への移行でも引き続き適用されます。たとえば、HA 管理クラスタは Seesaw をサポートしていないため、非 HA 管理クラスタに Seesaw ロードバランサを使用している場合は、まず MetalLB に移行してから HA 管理クラスタに移行する必要があります。
移行が正常に完了した後、非 HA 管理マスター VM などの残ったリソースは、障害復旧のために意図的に保持されます。

移行前と移行後

次の表に、移行前と移行後におけるクラスタの主な違いを示します。

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

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

次の 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 アドレスごとに、ロードバランサで次のマッピングを構成します。

(old controlPlaneVIP:443) -> (NEW_NODE_IP_ADDRESS:old 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 管理クラスタへのアクセスに使用することもできます。