ユーザー クラスタを Controlplane V2 に移行する

このドキュメントでは、kubeception を使用してバージョン 1.29 以降のユーザー クラスタを Controlplane V2 に移行する方法について説明します。

1.29: プレビュー
1.28: 提供なし
1.16: 提供なし

ユーザー クラスタ コントロール プレーンについて

Google Distributed Cloud バージョン 1.13 より前は、ユーザー クラスタのコントロール プレーンは管理クラスタ内の 1 つ以上のノードで実行されていました。この種類のコントロール プレーンは kubeception と呼ばれます。バージョン 1.13 では、新しいユーザー クラスタ用に Controlplane V2 が導入されました。Controlplane V2 が有効になっている場合、ユーザー クラスタのコントロール プレーンはユーザー クラスタ自体で実行されます。

Controlplane V2 には、次のメリットがあります。

  • 障害の分離。管理クラスタの障害は、ユーザー クラスタに影響しません。

  • 運用上の分離。管理クラスタのアップグレードでユーザー クラスタのダウンタイムは発生しません。

  • デプロイの分離。管理クラスタとユーザー クラスタを、異なる障害発生ドメインまたは地理的な場所に配置できます。たとえば、エッジ ロケーションのユーザー クラスタが、管理クラスタとは地理的に異なる場所に存在する場合があります。

要件

ユーザー クラスタを Controlplane V2 に移行するには、ユーザー クラスタが次の要件を満たしている必要があります。

  • ユーザー クラスタはバージョン 1.29 以降である必要があります。管理クラスタとノードプールは、ユーザー クラスタより 1 つまたは 2 つ前のマイナー バージョンにする必要があります。必要に応じて、クラスタをアップグレードします。

  • ユーザー クラスタで Dataplane V2 が有効になっている必要があります。このフィールドは不変です。クラスタで Dataplane V2 が有効になっていない場合、Controlplane V2 に移行することはできません。

  • ユーザー クラスタは、MetalLB または手動ロードバランサを使用するように構成する必要があります。ユーザー クラスタで SeeSaw ロードバランサを使用している場合は、MetalLB に移行できます。

  • IP アドレス計画のドキュメントを確認し、ユーザー クラスタのコントロール プレーン ノードに十分な IP アドレスがあることを確認します。コントロール プレーン ノードには静的 IP アドレスが必要です。新しいコントロール プレーン仮想 IP（VIP）には追加の IP アドレスが必要になります。

ユーザー クラスタの構成ファイルを更新する

ユーザー クラスタ構成ファイルを次のように変更します。

  1. enableControlplaneV2 を true に設定します。

  2. 必要に応じて、Controlplane V2 ユーザー クラスタのコントロール プレーンを高可用性（HA）にします。非 HA クラスタから HA クラスタに変更するには、masterNode.replicas を 1 から 3 に変更します。

  3. ユーザー クラスタ コントロール プレーン ノードの静的 IP アドレスを network.controlPlaneIPBlock.ips セクションに追加します。

  4. network.controlPlaneIPBlock セクションにネットマスクとゲートウェイを入力します。

  5. network.hostConfig セクションが空白の場合は、入力します。

  6. ユーザー クラスタが手動ロード バランシングを使用する場合は、データプレーン トラフィックにコントロール プレーン ノードの IP を含めるようにロードバランサを構成します。

    • (ingressVIP:80) -> (CP_NODE_IP_ADDRESSES:ingressHTTPNodePort)
    • (ingressVIP:443) -> (CP_NODE_IP_ADDRESSES:ingressHTTPSNodePort)

  7. loadBalancer.vips.controlPlaneVIP フィールドを更新して、コントロール プレーン VIP の新しい IP アドレスを指定します。コントロール プレーン ノードの IP アドレスと同じ VLAN に存在する必要があります。

  8. 移行のためにクラスタを更新する場合を除き、以前のフィールドはすべて不変です。すべての設定を再度確認してください。

  9. gkectl diagnose cluster を実行し、コマンドで検出された問題を修正します。

    gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
      --cluster-name=USER_CLUSTER_NAME

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

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

    • CLUSTER_NAME : ユーザー クラスタの名前。

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

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

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

  • (ingressVIP:80) -> (NEW_NODE_IP_ADDRESS:ingressHTTPNodePort)
  • (ingressVIP:443) -> (NEW_NODE_IP_ADDRESS:ingressHTTPNodePort)

クラスタを更新する

次のコマンドを実行して、クラスタを Controlplane V2 に移行します。

gkectl update cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG

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

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

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

このコマンドは、次のことを行います。

  1. ControlPlane V2 を有効にして、新しいクラスタのコントロール プレーンを作成します。

  2. kubeception クラスタの Kubernetes コントロール プレーンを停止します。

  3. kubeception クラスタの etcd スナップショットを作成します。

  4. kubeception クラスタのユーザー クラスタ コントロール プレーン ノードをオフにします。障害復旧（Kubeception クラスタへのフォールバック）のため、移行が完了するまでノードは削除されません。

  5. 前述の etcd スナップショットを使用して、新しいコントロール プレーンでクラスタデータを復元します。

  6. kubeception クラスタのノードプール ノードを新しいコントロール プレーンに接続します。新しい controlPlaneVIP を使用してアクセスできます。

  7. 復元されたユーザー クラスタを調整して、ControlPlane V2 が有効になっているクラスタの最終状態を満たします。

注

  • 移行中、ユーザー クラスタのワークロードはダウンタイムなしで実行されます。

  • 移行中、ユーザー クラスタのコントロール プレーンでダウンタイムが発生します。具体的には、ステップ 2 からステップ 6 の完了まで、コントロール プレーンは使用できません（Google のテストではダウンタイムは 7 分未満ですが、実際の長さはインフラストラクチャによって異なります）。

  • 移行が完了すると、kubeception クラスタのユーザー クラスタ コントロール プレーン ノードが削除されます。管理クラスタで network.ipMode.type が static に設定されている場合、管理クラスタの構成ファイルから未使用の静的 IP を削除して gkectl update admin を実行すると、未使用の静的 IP の一部をリサイクルできます。kubectl get nodes -o wide を使用して管理クラスタ ノード オブジェクトを一覧表示し、使用中の IP を確認できます。