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

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

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

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

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

Controlplane V2 には次の利点があります。

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

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

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

要件

ユーザー クラスタをコントロール プレーン V2 に移行するには、ユーザー クラスタが次の要件を満たしている必要があります。

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

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

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

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

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

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

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

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

  3. ユーザー クラスタ コントロール プレーン ノードの静的 IP アドレスを network.controlPlaneIPBlock.ips セクションに追加します。管理クラスタの IP ブロック ファイルから kubeception ユーザー クラスタ コントロール プレーン ノードの IP アドレスを削除します。

  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 アドレスで更新します。

  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)

クラスタを更新します。

次のコマンドを実行して、クラスタをコントロール プレーン V2 に移行します。

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

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

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

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