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

このページでは、バージョン 1.29 の非 HA 管理クラスタから高可用性（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":""}]

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

前のセクションの手順で、暗号鍵をローテーションする必要があることが示された場合は、次の手順を実施します。

  1. 管理クラスタの構成ファイルで keyVersion をインクリメントします。

  2. 管理クラスタを更新します。

    gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config ADMIN_CLUSTER_CONFIG

    これにより、新しいバージョン番号と一致する新しい鍵が作成され、各 Secret が再暗号化され、古い Secret が安全に消去されます。後続のすべての新しい Secret は、新しい暗号鍵を使用して暗号化されます。

手順の概要

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

  1. 管理クラスタ構成ファイルを編集します。

  2. gkectl update admin を実行します。このコマンドは、次の処理を行います。

    • 外部クラスタ（Kind）を起動し、現在の非 HA 管理クラスタが正常な状態であることを確認します。

    • HA 仕様と新しいコントロール プレーン VIP を使用して、新しい管理クラスタ コントロール プレーンを作成します。

    • 既存の管理クラスタ コントロール プレーンをオフにします。

    • 既存の管理クラスタの etcd スナップショットを作成します。

    • 新しい HA コントロール プレーンで古い管理クラスタデータを復元します。

    • 復元された管理クラスタを調整して、HA 管理クラスタの最終状態を満たします。

メモ

  • 移行中、ユーザー クラスタのワークロードでダウンタイムは発生しません。

  • 移行中、管理クラスタのコントロール プレーンでダウンタイムが発生します。（Google のテストではダウンタイムは 18 分未満ですが、実際の長さは個々のインフラストラクチャ環境によって異なります）。

  • HA 管理クラスタの要件は、非 HA から HA への移行でも引き続き適用されます。たとえば、HA 管理クラスタは Seesaw をサポートしていないため、非 HA 管理クラスタに Seesaw ロードバランサを使用している場合は、まず MetalLB に移行してから HA 管理クラスタに移行する必要があります。

  • 移行が正常に完了すると、HA 以外の管理マスター VM などの残りのリソースは、障害復旧のために意図的に保持されます。

移行前と移行後

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

移行前移行後
コントロール プレーン ノードのレプリカ13
アドオンノード20
コントロール プレーン Pod のレプリカ
（kube-apiserver、kube-etcd など）		13
データディスク サイズ100GB * 125GB * 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 アドレスを指定する

  1. 管理クラスタの構成ファイルで、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"

  2. hostconfig セクションに入力します。管理クラスタが静的 IP アドレスを使用している場合、このセクションはすでに入力されています。次に例を示します。

    hostConfig:
  dnsServers:
  - 203.0.113.1
  - 198.51.100.1
  ntpServers:
  - 216.239.35.12

  3. loadBalancer.vips.controlPlaneVIP の値を新しい VIP に置き換えます。次に例を示します。

    loadBalancer:
 vips:
   controlPlaneVIP: "172.16.20.59"

その他の構成フィールドを更新する

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

    adminMaster:
 replicas: 3
 cpus: 4
 memoryMB: 8192

  2. vCenter.dataDisk フィールドを削除します。HA 管理クラスタの場合、コントロール プレーン ノードで使用される 3 つのデータディスクのパスは、データストアのルート ディレクトリ anthos の下に自動的に生成されます。

  3. loadBalancer.manualLB.controlPlaneNodePort の値がゼロ以外の場合は、0 に設定します。

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

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

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

（old controlPlaneVIP:443）->（NEW_NODE_IP_ADDRESS:old controlPlaneNodePort）

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

管理クラスタを更新する

フィールドは不変であるため、行った構成変更を確認します。変更が正しいことを確認したら、クラスタを更新します。

  1. 移行を開始する:

    gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG

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

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

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

  2. このコマンドは、移行の進行状況を表示します。

    指示に従って、「Y」と入力して次に進みます。

  3. 移行が完了すると、新しいコントロール プレーン VIP を使用するように管理クラスタの kubeconfig ファイルが自動的に更新されます。古いコントロール プレーン VIP は引き続き機能し、新しい HA 管理クラスタへのアクセスにも使用できます。