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

ユーザークラスタを推奨機能に移行する

概要

このページでは、バージョン 1.30 以降のユーザークラスタを次の推奨機能に移行する方法について説明します。

Container Network Interface（CNI）として Dataplane V2 に移行する。
kubeception を使用するユーザークラスタを Controlplane V2 に移行する。
次のようにロードバランサの構成を移行する。
- 統合型 F5 BIG-IP ロードバランサの構成から ManualLB
  
  または
- バンドルされた Seesaw ロードバランサから MetalLB

このページは、基盤となる技術インフラストラクチャのライフサイクルを管理する IT 管理者と運用担当者を対象としています。Google Cloud のコンテンツで使用されている一般的なロールとタスク例については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。

ベストプラクティス

最初に、テストなどの重要度の低い環境を移行することをおすすめします。移行が成功したことを確認したら、このプロセスを環境ごとに繰り返し、最後に本番環境を移行します。これにより、各移行の成功を確認し、ワークロードが正しく実行されていることを確認してから、次のより重要な環境の移行に進むことができます。

Controlplane V2 を有効にして新しいユーザークラスタを作成し、kubeception クラスタとのアーキテクチャの違いを確認することをおすすめします。新しいクラスタはワークロードに影響しません。ただし、移行に失敗するような最悪の場合でも、ワークロード用のクラスタは準備されています。

移行計画の詳細については、推奨機能へのクラスタの移行を計画するをご覧ください。

要件

この移行の場合:

ユーザークラスタはバージョン 1.30 以降である必要があります。
すべてのノードプールはユーザークラスタと同じバージョンである必要があります。
クラスタで Seesaw ロードバランサを使用している場合は、次のセクションで説明するように、クライアント IP の保持に Seesaw を使用していないことを確認してください。

Seesaw クライアント IP の保持

externalTrafficPolicy を確認するには、次のコマンドを実行します。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get svc -A -o yaml | grep "externalTrafficPolicy: Local"

この問題が発生した場合は、Google サポートにお問い合わせください。

所要時間を見積もり、メンテナンスの時間枠を計画する

クラスタを更新すると、デフォルトではすべてのノードプールが並列で更新されます。ただし、各ノードプール内でノードは順番に更新されます。したがって、更新にかかる合計時間は、最大規模のノードプール内のノード数によって異なります。各更新の大まかな所要時間を計算するには:

Seesaw から MetalLB に移行する場合、更新で MetalLB ロードバランサのノードプールが選択されるまでに 15 分ほどかかります。この更新では、選択したノードプールのみが更新されます。
移行プロセスの他の更新の場合は、「15 分 x ノードプール内のノード数」で計算します。

所要時間を計算するには、クラスタを更新する必要がある回数をカウントします。次の大まかな手順は、gkectl update cluster を実行してクラスタを更新する必要がある場合を示しています。

ユーザークラスタで Secret の常時暗号化を使用している場合は、この機能を無効にして gkectl update cluster を実行します。
ユーザークラスタで enableDataplaneV2 が未設定または false に設定されている場合は、構成を変更してから gkectl update cluster を実行して Dataplane V2 に移行します。
ロードバランサとコントロールプレーンの移行を準備します。
1. 管理クラスタで自動修復が有効になっている場合は、無効にします。その後、gkectl update admin を実行します。この更新は、管理クラスタノードを再作成しないため、すぐに完了します。
2. ユーザークラスタで Seesaw を使用している場合は、MetalLB ロードバランサが使用するノードプールを選択し、gkectl update cluster を実行します。この更新では、選択したノードプール内のノードのみ更新されます。
ロードバランサを更新して Controlplane V2 に移行するために必要な構成変更をすべて行います。その後、gkectl update cluster を実行します。
移行後に Secret の常時暗号化を無効にした場合は、この機能を再度有効にして gkectl update cluster を実行します。

移行の合計時間は、gkectl cluster update を実行する必要がある回数によって異なります。これは構成に依存します。たとえば、Dataplane V2、ControlPlane V2、MetalLB に移行するとします。また、最大のノードプールに 10 個のノードがあり、MetalLB が使用するノードプールに 3 個のノードがあるとします。移行時間を計算するには、次を追加します。

Dataplane V2 への移行に 150 分（15 分 * 最大プールの 10 ノード = 150 分）。
MetalLB で使用されるノードプールの場合、15 分 × ノードプール内の 3 ノード = 45 分。
Controlplane V2 と MetalLB の更新に 150 分（15 分 * 最大プールの 10 ノード = 150 分）。

移行にかかる合計時間は約 345 分（5 時間 45 分）です。

必要に応じて、移行を段階的に行うことができます。前の例では、1 つのメンテナンスの時間枠で Dataplane V2 への移行を行い、残りの移行を 1 つまたは 2 つのメンテナンスの時間枠で行うことができます。

移行中のダウンタイムを計画する

移行を計画する際は、次の種類のダウンタイムを計画してください。

コントロールプレーンのダウンタイム: 移行中、Kubernetes API サーバーへのアクセスは影響を受けます。Controlplane V2 に移行する場合、loadBalancer.vips.controlPlaneVIP が移行されるため、kubeception ユーザークラスタのコントロールプレーンでダウンタイムが発生します。通常、ダウンタイムは 10 分未満ですが、ダウンタイムの長さはインフラストラクチャによって異なります。
ワークロードのダウンタイム: LoadBalancer タイプの Service で使用される仮想 IP（VIP）を使用できません。これは、Seesaw から MetalLB への移行中にのみ発生します。MetalLB の移行プロセスでは、LoadBalancer タイプの Kubernetes Service のユーザークラスタ内ですべての VIP へのネットワーク接続が約 2～10 分間停止します。移行が完了すると、接続が再び機能するようになります。

次の表に、移行の影響を示します。

移行元	移行先	Kubernetes API アクセス	ユーザーワークロード
Calico を使用する Kubeception クラスタ。`enableDataplaneV2` が未設定または `false` に設定されている	Dataplane V2 を使用した Kubeception クラスタ	影響なし	影響なし
`enableControlplaneV2` が未設定か、`MetalLB` または `ManualLB` で `false` に設定されている kubeception クラスタ	同じ種類のロードバランサを使用する ControlPlane V2 クラスタ	影響あり	影響なし
`loadBalancer.kind: "F5BigIP"` を使用した kubeception クラスタ	手動ロードバランサ構成の Controlplane V2 クラスタ	影響あり	影響なし
`loadBalancer.kind: "Seesaw"` を使用した kubeception クラスタ	MetalLB を使用した Controlplane V2 クラスタ	影響あり	影響あり

影響あり: 移行中にサービスが停止します。
影響なし: サービスが停止しないか、ほとんど気づきません。

移行を準備する

移行を正常に完了するには、次のセクションの手順を実施します。

新しい IP アドレスを割り振る

ControlPlane V2 に移行する場合は、ワーカーノード（ノードプールのノード）と同じ VLAN に新しい静的 IP アドレスを割り振ります。

loadBalancer.vips.controlPlaneVIP には 1 つの IP アドレスが必要です。
コントロールプレーンノードごとに 1 つの IP アドレスを割り振ります。割り振る必要がある IP アドレスの数は、ユーザークラスタが高可用性（HA）か HA 以外かによって異なります。
- HA 以外: 1 つの IP アドレス
- HA: 3 つの IP アドレス

ファイアウォールルールを更新する

Controlplane V2 に移行する場合は、ユーザークラスタのファイアウォールルールを更新します。ユーザークラスタノードのファイアウォールルールで説明されているように、ユーザークラスタのコントロールプレーンノードに新しく割り振られた IP アドレスが、必要なすべての API やその他の宛先に到達できるようにします。

クラスタとノードプールのバージョンを確認する

すべてのノードプールがユーザークラスタと同じバージョンを使用していることを確認します。バージョンは 1.30 以降である必要があります。そうでない場合は、移行を続行する前に、ユーザークラスタ構成ファイルで gkeOnPremVersion にノードプールをアップグレードします。バージョンを確認するには、次のコマンドを実行します。

gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details

ADMIN_CLUSTER_KUBECONFIG は、管理クラスタ kubeconfig ファイルのパスに置き換えます。

クラスタの正常性を確認する

クラスタの正常性を確認し、gkectl diagnose cluster コマンドで報告された問題を修正します。

gkectl diagnose cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name <var>USER_CLUSTER_NAME</var>

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

ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。
USER_CLUSTER_NAME : ユーザークラスタの名前。

管理クラスタで自動修復を無効にする

ユーザークラスタを Controlplane V2 を使用するように移行し、管理クラスタで自動修復が有効になっている場合は、自動修復を無効にします。管理クラスタ構成ファイルの autoRepair.enabled フィールドを確認します。このフィールドが未設定または true に設定されている場合は、次の操作を行います。

管理クラスタ構成ファイルで、autoRepair.enabled を false に設定します。次に例を示します。
```
autoRepair:
  enabled: true
```

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

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

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

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

移行が完了したら、管理クラスタで自動修復を再度有効にしてください。

Secret の常時暗号化に関する問題を確認する

ユーザークラスタを Controlplane V2 を使用するように移行する場合は、Secret の常時暗号化に関する問題を確認します。

ユーザークラスタで Secret の常時暗号化が有効になっている場合は、移行を開始する前に、Secret の常時暗号化を無効にして Secret を復号するの手順に沿って操作する必要があります。そうしないと、新しい Controlplane V2 クラスタは Secret を復号できません。

移行を開始する前に、次のコマンドを実行して、Secret の常時暗号化が有効になったことがあるかどうかを確認します。

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  get onpremusercluster USER_CLUSTER_NAME \
  -n USER_CLUSTER_NAME-gke-onprem-mgmt \
  -o jsonpath={.spec.secretsEncryption}

前のコマンドの出力が空の場合、Secret の常時暗号化は有効になっていないため、移行を開始できます。

前述のコマンドの出力が空でない場合、Secret の常時暗号化が以前に有効にされていました。移行する前に、次のセクションの手順に沿って、新しい Controlplane V2 クラスタが Secret を復号できるようにする必要があります。

次の例は、空でない出力を示しています。

{"generatedKeyVersions":{"keyVersions":[1]}}

必要に応じて、Secret の常時暗号化を無効にして Secret を復号する

Secret の常時暗号化を無効にして Secret を復号するには、次の操作を行います。

ユーザークラスタの構成ファイルで、Secret の常時暗号化を無効にするには、secretsEncryption セクションに disabled: true フィールドを追加します。
```
secretsEncryption:
    mode: GeneratedKey
    generatedKey:
        keyVersion: KEY_VERSION
        disabled: true
```
クラスタを更新します。
```
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG
```
次のように置き換えます。
- ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス
- USER_CLUSTER_CONFIG: ユーザークラスタの構成ファイルのパス

次のように、特定の DaemonSet でローリングアップデートを行います。

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  rollout restart statefulsets kube-apiserver \
  -n USER_CLUSTER_NAME

ユーザークラスタ内のすべての Secret のマニフェストを YAML 形式で取得します。
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  get secrets -A -o yaml > SECRETS_MANIFEST.yaml
```
すべての Secret が平文として etcd に保存されるように、ユーザークラスタ内のすべての Secret を再適用します。
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  apply -f SECRETS_MANIFEST.yaml
```
これで、Controlplane V2 への移行を開始できます。移行が完了したら、クラスタで Secret の常時暗号化を有効にできます。

MetalLB で使用されるノードプールを有効にする

バンドルされた Seesaw ロードバランサから MetalLB に移行する場合は、このセクションの手順を実施します。ユーザークラスタの構成ファイルに loadBalancer.kind: Seesaw が含まれている場合、クラスタは Seesaw を使用しています。統合 F5 BIG-IP 構成を移行する場合は、次のセクションの Dataplane V2 に移行するに進みます。

ノードプールを選択し、MetalLB で使用できるように有効にします。移行では、そのノードプール内のノードに MetalLB がデプロイされます。

ユーザークラスタ構成ファイルの nodePools セクションで、ノードプールを選択するか、新しいノードプールを追加して enableLoadBalancer を true に設定します。次に例を示します。
```
nodePools:
  - name: pool-1
    replicas: 3
    enableLoadBalancer: true
```

クラスタを更新します。

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

MetalLB の詳細については、MetalLB によるバンドルされたロードバランシングをご覧ください。

Dataplane V2 に移行する

移行する前に、次のコマンドを実行して、クラスタで DataPlane V2 が有効になっているかどうかを確認します。

kubectl —kubeconfig ADMIN_CLUSTER_KUBECONFIG get onpremusercluster USER_CLUSTER_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt -o yaml | grep enableDataplaneV2

Dataplane V2 がすでに有効になっている場合は、次のセクションのロードバランサの移行の準備に進んでください。

Dataplane V2 に移行する手順は次のとおりです。NetworkPolicy 仕様の一時的な削除について懸念がある場合は、Google サポートにお問い合わせください。

クラスタで NetworkPolicy を使用している場合は、次のようにクラスタからその仕様を一時的に削除します。

クラスタにシステム以外の NetworkPolicy が適用されているかどうかを確認します。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkpolicy -A -o wide | grep -v kube-system

前の手順の出力が空でない場合、各 NetworkPolicy 仕様をファイルに保存します。
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkpolicy NETWORK_POLICY_NAME -n NETWORK_POLICY_NAMESPACE -o yaml > NETWORK_POLICY_NAME.yaml
```
次のように置き換えます。
- NETWORK_POLICY_NAME: 保存する NetworkPolicy の名前。
- NETWORK_POLICY_NAMESPACE: NetworkPolicy の Namespace。

次のコマンドを使用して NetworkPolicy を削除します。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete networkpolicy NETWORK_POLICY_NAME -n NETWORK_POLICY_NAMESPACE

次の手順で Dataplane V2 に移行します。

ユーザークラスタの構成ファイルで、enableDataplaneV2 を true に設定します。

DataPlane V2 を有効にするには、クラスタを更新します。

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

前の手順でシステム以外の NetworkPolicy 仕様を削除した場合は、更新が完了したら、次のコマンドで再適用します。
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f NETWORK_POLICY_NAME.yaml
```

これらの手順を完了すると、Dataplane V2 が有効になります。次に、推奨されるロードバランサと Controlplane V2 にクラスタを移行する準備を行います。

ロードバランサの移行を準備する

ユーザークラスタで Seesaw ロードバランサまたは統合 F5 BIG-IP を使用している場合は、このセクションの手順に沿って、必要なユーザークラスタ構成ファイルの変更を行います。それ以外の場合は、次のセクションの Controlplane V2 への移行の準備に進みます。

F5 BIG-IP

クラスタで統合 F5 BIG-IP 構成を使用している場合は、ユーザークラスタ構成ファイルに次の変更を行い、ManualLB への移行を準備します。

loadBalancer.kind を "ManualLB" に変更します。
loadBalancer.vips.ingressVIP フィールドの値は同じにします。
Controlplane V2 に移行する場合は、loadBalancer.vips.controlPlaneVIP フィールドの値を割り振り済みの IP アドレスに変更します。それ以外の場合は、同じ値を維持できます。
loadBalancer.f5BigIP セクション全体を削除します。

次のユーザークラスタ構成ファイルの例は、これらの変更を示しています。

loadBalancer:
vips:
  controlPlaneVIP: 192.0.2.5
  ingressVIP: 198.51.100.20
kind: "f5BigIP" "ManualLB"
f5BigIP:
  address: "203.0.113.2"
  credentials:
  fileRef:
    path: "my-config-folder/user-creds.yaml"
    entry: "f5-creds"
  partition: "my-f5-user-partition"

Seesaw

ユーザークラスタで Seesaw ロードバランサを使用している場合は、次のセクションの手順に沿って MetalLB への移行を準備します。

アドレスプールを指定する

MetalLB コントローラが Service の IP アドレス管理を行います。そのため、アプリケーションデベロッパーが、ユーザークラスタに LoadBalancer タイプの Service を作成する際に、Service の IP アドレスを手動で指定する必要はありません。代わりに、MetalLB コントローラは、指定されたアドレスプールから IP アドレスを選択します。

ユーザークラスタでアクティブになる可能性のある LoadBalancer Service の最大数を考慮します。次に、ユーザークラスタ構成ファイルの loadBalancer.metalLB.addressPools セクションで、それらの Service に対応する十分な IP アドレスを指定します。

アドレスプールを指定する場合は、ユーザークラスタの Ingress VIP をいずれかのプールに含めます。これは、Ingress プロキシが LoadBalancer タイプの Service によって公開されるためです。

アドレスは CIDR 形式または範囲形式にする必要があります。個々のアドレスを指定する場合は、198.51.100.10/32 のように /32 CIDR を使用します。

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

クラスタ構成ファイルを更新して、Seesaw セクションを削除し、MetalLB セクションを追加します。

loadBalancer.kind を "MetalLB" に設定します。
loadBalancer.vips.ingressVIP フィールドの値は同じにします。
上り（内向き）VIP を MetalLB アドレスプールに追加します。
Controlplane V2 に移行する場合は、loadBalancer.vips.controlPlaneVIP フィールドの値を割り振り済みの IP アドレスに変更します。それ以外の場合は、同じ値を維持できます。
loadBalancer.seesaw セクションを削除します。
loadBalancer.metalLB セクションを追加します。

ユーザークラスタ構成ファイルの次の部分は、これらの変更と、次の MetalLB 構成を示しています。

MetalLB コントローラのアドレスプール。ここから選択して LoadBalancer タイプの Service に割り当てます。Ingress VIP（この例では 198.51.100.10）は範囲形式の表記（198.51.100.10/32）で、このプール内に存在します。
ユーザークラスタの Kubernetes API サーバーに指定された VIP。
Ingress プロキシ用に構成した Ingress VIP。
MetalLB の使用が有効になっているノードプール。移行では、このノードプールのノードに MetalLB がデプロイされます。

loadBalancer:
  vips:
    controlPlaneVIP: "198.51.100.50"
    ingressVIP: "198.51.100.10"
  kind: "MetalLB" "Seesaw"
  seesaw:
    ipBlockFilePath: "user-cluster-2-ipblock.yaml"
    vrid: 1
    masterIP: ""
    cpus: 4
    memoryMB: 3072
  metalLB:
  addressPools:
    - name: "address-pool-1"
      enableLoadBalancer: true
      addresses:
      - "198.51.100.10/32"
      - "198.51.100.80 - 198.51.100.89"

Controlplane V2 への移行を準備する

クラスタで Controlplane V2 が有効になっていない場合:

ユーザークラスタの構成ファイルを更新します。
クラスタで手動ロードバランシング（loadBalancer.kind: "ManualLB"）を使用している場合は、ロードバランサの構成も更新します。

以下では、この違いについて説明します。

クラスタで Controlplane V2 がすでに有効になっている場合は、ユーザークラスタを移行するセクションに進みます。

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

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

enableControlplaneV2 を true に設定します。
必要に応じて、Controlplane V2 ユーザークラスタのコントロールプレーンを高可用性（HA）にします。非 HA クラスタから HA クラスタに変更するには、masterNode.replicas を 1 から 3 に変更します。
ユーザークラスタコントロールプレーンノードの静的 IP アドレスを network.controlPlaneIPBlock.ips セクションに追加します。コントロールプレーンノードの IP アドレスは、ワーカーノードと同じ VLAN に存在する必要があります。
network.controlPlaneIPBlock セクションに netmask と gateway を入力します。
network.hostConfig セクションが空白の場合は、入力します。
loadBalancer.vips.controlPlaneVIP フィールドに、コントロールプレーン VIP の新しい IP アドレスが設定されていることを確認します。IP アドレスは、コントロールプレーンノードの IP アドレスと同じ VLAN に存在する必要があります。
ユーザークラスタで手動ロードバランシングを使用している場合は、loadBalancer.manualLB.controlPlaneNodePort と loadBalancer.manualLB.konnectivityServerNodePort を 0 に設定します。Controlplane V2 が有効になっている場合は必要ありませんが、値は 0 にする必要があります。
ユーザークラスタで手動ロードバランシングを使用する場合は、次のセクションで説明するようにロードバランサを構成します。

必要に応じてロードバランサのマッピングを調整する

ユーザークラスタですでに手動ロードバランシングを使用している場合は、ロードバランサでマッピングを構成する必要があります。統合 F5 BIG-IP 構成から手動ロードバランシングに移行する場合は、ロードバランサの構成を変更する必要はありません。次のセクションのユーザークラスタを移行するに進むことができます。

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

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

これらのマッピングは、ユーザークラスタ内のすべてのノード（コントロールプレーンノードとワーカーノードの両方）に必要です。NodePort がクラスタに構成されているため、Kubernetes はすべてのクラスタノードで NodePort を開き、クラスタ内の任意のノードがデータプレーントラフィックを処理できるようにします。

マッピングを構成すると、ロードバランサは標準の HTTP ポートと HTTPS ポートで、ユーザークラスタの Ingress VIP に構成した IP アドレスでトラフィックをリッスンします。ロードバランサは、クラスタ内の任意のノードにリクエストをルーティングします。リクエストがクラスタノードの 1 つにルーティングされると、内部 Kubernetes ネットワークがリクエストを宛先 Pod に転送します。

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

まず、ユーザークラスタ構成ファイルに加えたすべての変更を慎重に確認します。移行のためにクラスタを更新する場合を除き、ロードバランサと Controlplane V2 の設定はすべて不変です。

クラスタを更新するには、次のコマンドを実行します。

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

Controlplane V2 への移行

Controlplane V2 の移行中に、更新は次のアクションを実行します。

ControlPlane V2 を有効にして、新しいクラスタのコントロールプレーンを作成します。
kubeception クラスタの Kubernetes コントロールプレーンを停止します。
kubeception クラスタの etcd スナップショットを作成します。
kubeception クラスタのユーザークラスタコントロールプレーンノードをパワーオフします。移行が完了するまでノードは削除されません。これは、その kubeception クラスタにフォールバックすることで障害復旧を可能にするためです。
前の手順で作成した etcd スナップショットを使用して、新しいコントロールプレーンでクラスタデータを復元します。
kubeception クラスタのノードプールノードを新しいコントロールプレーンに接続します。新しい controlPlaneVIP を使用してアクセスできます。
復元されたユーザークラスタを調整して、ControlPlane V2 が有効になっているクラスタの最終状態を満たします。

次の点にご注意ください。

移行中、ユーザークラスタのワークロードでダウンタイムは発生しません。
移行中、ユーザークラスタのコントロールプレーンでダウンタイムが発生します。具体的には、kubeception クラスタの Kubernetes コントロールプレーンを停止してから、kubeception クラスタのノードプールノードを新しいコントロールプレーンに接続するまで、コントロールプレーンは使用できません（テストではこのダウンタイムは 7 分未満でしたが、実際の長さはインフラストラクチャによって異なります）。
移行が完了すると、kubeception クラスタのユーザークラスタコントロールプレーンノードが削除されます。管理クラスタで network.ipMode.type が "static" に設定されている場合、未使用の静的 IP アドレスの一部をリサイクルできます。kubectl get nodes -o wide を使用して管理クラスタノードオブジェクトを一覧取得し、使用中の IP アドレスを確認できます。これらの IP アドレスをリサイクルするには、管理クラスタの構成ファイルから IP アドレスを削除して gkectl update admin を実行します。

移行後

更新が完了したら、次の操作を行います。

ユーザークラスタが実行されていることを確認します。

kubectl get nodes --kubeconfig var>USER_CLUSTER_KUBECONFIG

出力は次のようになります。

cp-vm-1       Ready    control-plane,master   18m
cp-vm-2       Ready    control-plane,master   18m
cp-vm-3       Ready    control-plane,master   18m
worker-vm-1   Ready                           6m7s
worker-vm-2   Ready                           6m6s
worker-vm-3   Ready                           6m14s

Controlplane V2 に移行した場合は、管理クラスタのファイアウォールルールを更新して、kubeception ユーザークラスタのコントロールプレーンノードを削除します。
Secret の常時暗号化を無効にした場合は、この機能を再度有効にします。
1. ユーザークラスタの構成ファイルで、disabled: true フィールドを削除します。
2. ユーザークラスタを更新します。
```
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG
```
管理クラスタで自動修復を無効にした場合は、この機能を再度有効にします。
1. 管理クラスタ構成ファイルで、autoRepair.enabled を true に設定します。
2. クラスタを更新します。
```
gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG
```

ロードバランサの移行

ロードバランサを移行した場合は、ロードバランサコンポーネントが正常に実行されていることを確認します。

MetalLB の移行

MetalLB に移行した場合は、MetalLB コンポーネントが正常に実行されていることを確認します。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pods \
    --namespace kube-system --selector app=metallb

出力には、MetalLB コントローラとスピーカーの Pod が表示されます。次に例を示します。

metallb-controller-744884bf7b-rznr9   1/1     Running
metallb-speaker-6n8ws                 1/1     Running
metallb-speaker-nb52z                 1/1     Running
metallb-speaker-rq4pp                 1/1     Running

移行が正常に完了したら、ユーザークラスタがパワーオフ状態の Seesaw VM を削除します。Seesaw VM 名は、構成ディレクトリの seesaw-for-[USERCLUSTERNAME].yaml ファイルの vmnames セクションにあります。

F5 BIG-IP の移行

手動ロードバランシングに移行した後も、クラスタへのトラフィックは中断されません。これは、次のコマンドを実行するとわかるように、既存の F5 リソースがまだ存在するためです。

kubectl --kubeconfig CLUSTER_KUBECONFIG \
api-resources --verbs=list -o name | xargs -n 1 kubectl --kubeconfig
CLUSTER_KUBECONFIG get --show-kind --ignore-not-found
--selector=onprem.cluster.gke.io/legacy-f5-resource=true -A

想定される出力は次のようになります。


Warning: v1 ComponentStatus is deprecated in v1.19+
NAMESPACE     NAME                        TYPE     DATA   AGE
kube-system   secret/bigip-login-sspwrd   Opaque   4      14h
NAMESPACE     NAME                              SECRETS   AGE
kube-system   serviceaccount/bigip-ctlr         0         14h
kube-system   serviceaccount/load-balancer-f5   0         14h
NAMESPACE     NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   deployment.apps/k8s-bigip-ctlr-deployment   1/1     1            1           14h
kube-system   deployment.apps/load-balancer-f5            1/1     1            1           14h
NAME                                                                                ROLE                                       AGE
clusterrolebinding.rbac.authorization.k8s.io/bigip-ctlr-clusterrole-binding         ClusterRole/bigip-ctlr-clusterrole         14h
clusterrolebinding.rbac.authorization.k8s.io/load-balancer-f5-clusterrole-binding   ClusterRole/load-balancer-f5-clusterrole   14h
NAME                                                                 CREATED AT
clusterrole.rbac.authorization.k8s.io/bigip-ctlr-clusterrole         2024-03-25T05:16:40Z
clusterrole.rbac.authorization.k8s.io/load-balancer-f5-clusterrole   2024-03-25T05:16:41Z