ACK 専用クラスターから ACK マネージド Pro クラスターへのホットマイグレーション - Container Service for Kubernetes

ACK 専用クラスターを ACK マネージド Pro クラスターに移行するために、ホットマイグレーションを実行できます。ホットマイグレーションはサービスを中断せず、クラスターの通常の動作には影響しません。

ACK 専用クラスターの作成は、2024年8月21日以降、Container Service for Kubernetesで停止されました。より高い信頼性、セキュリティ、およびスケジューリング効率を実現するために、本番環境では ACK マネージド Pro クラスターを使用することをお勧めします。これにより、マネージドコントロールプレーンや高可用性など、ACK マネージド Pro クラスターの機能を活用できます。

前提条件

Kubernetes 1.18 以降を実行する ACK 専用クラスター（移行対象）が作成されていること。クラスターのアップグレード方法の詳細については、「ACK クラスターを手動でアップグレードする」をご参照ください。
クラスターの Kubernetes バージョンは、移行後も変更されません。アップグレードを伴う移行の場合は、アップグレードする前にクラスターを移行してください。
移行前に、クラスターの [基本情報] ページでタイムゾーンを設定する必要があります。これにより、移行後に ACK マネージド Pro クラスターのコントロールプレーンのタイムゾーンの一貫性が維持され、タイムゾーンの不一致によって発生する CronJob 実行時間の変更などの例外を回避できます。
移行対象の ACK クラスターのリージョンに Object Storage Service (OSS) バケットが作成されており、バケットのホットリンク保護が無効になっていること。ホットリンク保護は移行の失敗を引き起こす可能性があります。詳細については、「バケットを作成する」および「ホットリンク保護」をご参照ください。

注意事項

項目	説明
課金	クラスターを移行すると、クラスターの課金が変更されます。削除されたマスターノードに対しては課金されなくなります。クラスター管理料金が課金されます。他のクラウドリソースの課金は変更されません。バケットの作成には料金はかかりません。バケット内のオブジェクトのストレージと、オブジェクトへのアクセス時に発生するトラフィックに対してのみ課金されます。詳細については、「課金概要」をご参照ください。
インターネットアクセス	パブリックアクセス用に Elastic IP Address (EIP) を使用して API サーバーを公開しているクラスターの場合、クラスターのアクセスアドレスは移行後も変更されません。一部の ACK 専用クラスターは、インターネット接続の Server Load Balancer (SLB) インスタンスを使用して API サーバーにアクセスします。ACK 専用クラスターを ACK マネージド Pro クラスターに移行する場合は、手動で EIP モードに切り替える必要があります。つまり、EIP を API サーバーの内部接続 Classic Load Balancer (CLB) インスタンスにバインドする必要があります。詳細な操作については、「API サーバーへのパブリックアクセスを有効にする」をご参照ください。
カスタムポッド構成	ACK 専用クラスターでカスタムポッド構成が有効になっている場合、クラスターを ACK マネージド Pro クラスターに移行することはできません。移行を開始する前に terway-controlplane を停止し、移行完了後に terway-controlplane を有効にする必要があります。詳細については、「クラスターの移行前に terway-controlplane を停止する」をご参照ください。ポッド構成のカスタマイズ方法の詳細については、「各ポッドに静的 IP アドレス、個別の vSwitch、および個別のセキュリティグループを構成する」をご参照ください。
マスターノード	一部の古いマスターノードには、クラウドアシスタントクライアントがインストールされていません。手動でインストールする必要があります。詳細については、「クラウドアシスタントクライアントをインストールする」をご参照ください。クラスターの移行が完了すると、マスターノードのステータスは Not Ready に変わります。
ECS インスタンスのリリース	マスターノードを削除すると、ACK はすべての従量課金 ECS インスタンスとそのデータディスクをリリースします。サブスクリプションインスタンスは手動でリリースする必要があります。サブスクリプション ECS インスタンスは手動でリリースする必要があります。詳細については、「ApsaraDB for MySQL インスタンスをリリースまたはサブスクライブ解除する」をご参照ください。

ステップ 1：ホットマイグレーションを実行して ACK 専用クラスターを ACK マネージド Pro クラスターに移行する

開始する前に、すべての前提条件が満たされていること、および注意事項を読んで理解していることを確認してください。ACK マネージド Pro クラスターに移行した後、ACK 専用クラスターにロールバックすることはできません。

ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、移行する ACK クラスターの [アクション] 列にある [詳細] > [Pro に移行] を選択します。
[Pro に移行] ダイアログボックスで、事前チェックと Resource Access Management (RAM) 承認を完了し、ホットマイグレーション用に作成した OSS バケットを選択して、[OK] をクリックします。
事前チェックの完了方法を表示する
[事前チェック] をクリックして、Container Intelligence Service コンソールにログインします。[移行チェック] ページで [開始] をクリックします。次に、表示されるパネルでチェック項目を確認し、[内容を確認し、同意します] を選択して、[開始] をクリックします。
クラスターが事前チェックに合格しない場合は、ページの指示に従って問題を修正してください。
RAM 承認の完了方法を表示する
1. [RAM コンソール] をクリックして、RAM 承認を完了します。後続のステップで使用される OSS バケットの名前を取得します。
2. 名前が k8sMasterRolePolicy で始まるポリシーをクリックします。ポリシー詳細ページの [ポリシードキュメント] タブで、[ポリシードキュメントの変更] をクリックします。次に、[JSON] エディターの [ステートメント] フィールドに次の内容を追加し、[OK] をクリックします。
  <YOUR_BUCKET_NAME> を [Pro に移行] ダイアログボックスで指定された OSS バケットの名前に置き換えます。山かっこ（<>）は削除する必要があります。
```
,
        {
            "Action": [
                "oss:PutObject",
                "oss:GetObject"
            ],
            "Effect": "Allow",
            "Resource": [
                "acs:oss:*:*:<YOUR_BUCKET_NAME>/*"  
            ]
        }
```
移行が完了すると、[Pro に移行] ダイアログボックスにメッセージが表示されます。ACK クラスターのタイプとマスターノードのステータスを確認できます。
- クラスタータイプ：[クラスター] ページに戻ります。[タイプ] 列のクラスタータイプが ACK 専用クラスター から ACK マネージド に変更されます。[クラスター仕様] 列に プロフェッショナル と表示されます。
- マスターノードのステータス：[クラスター] ページで、クラスターの [アクション] 列にある [詳細] をクリックします。左側のナビゲーションウィンドウで、[ノード] > [ノード] を選択します。マスターノードの [ロール/ステータス] 列に不明と表示されている場合、マスターノードはクラスターから切断されています。ステップ 2：ホットマイグレーション完了後に ACK 専用クラスターからマスターノードを削除するを参照して、ホットマイグレーション完了後にマスターノードを削除できます。

ステップ 2：ホットマイグレーション完了後に ACK 専用クラスターからマスターノードを削除する

ホットマイグレーションが完了したら、コンソールを使用するか、kubectl コマンドを実行して、ACK 専用クラスターからマスターノードを削除できます。

ACK コンソールの使用

ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、変更するクラスターの名前をクリックします。左側のナビゲーションウィンドウで、[ノード] > [ノード] を選択します。
[ノード] ページで、マスターノードの [アクション] 列にある [詳細] > [削除] を選択するか、1 つ以上のマスターノードを選択し、下部にある [一括削除] をクリックします。表示されるダイアログボックスで、パラメーターを設定し、[OK] をクリックします。

kubectl の使用

コマンドを実行する前に、kubectl を使用してクラスターに接続していることを確認してください。詳細については、「クラスターの kubeconfig ファイルを取得し、kubectl を使用してクラスターに接続する」をご参照ください。

削除するマスターノードの名前をクエリして記録します。
```
kubectl get node | grep control-plane
```
マスターノードを削除します。<MASTER_NAME> をマスターノードの名前に置き換えます。
```
kubectl delete node <MASTER_NAME>
```
一度に複数のマスターノードを削除するには、<MASTER_NAME> をマスターノードの名前に置き換えます。たとえば、マスターノード cn-hangzhou.192.xx.xx.65 と cn-hangzhou.192.xx.xx.66 を同時に削除するには、次のコマンドを実行します。
```
kubectl delete node cn-hangzhou.192.xx.xx.65 cn-hangzhou.192.xx.xx.66
```

(オプション) 手順 3: コンポーネントを処理する

ACK 専用クラスターに Application Load Balancer (ALB) Ingress コントローラーまたは ack-virtual-node がインストールされているかどうかを確認します。インストールされている場合は、コンポーネントを再インストールまたは移行する必要があります。

[クラスター] ページで、管理するクラスターを見つけ、その名前をクリックします。左側のペインで、[操作] > [アドオン] を選択します。
[アドオン] ページで、ACK 専用クラスターに ALB Ingress コントローラーまたは ack-virtual-node がインストールされているかどうかを確認します。
ALB Ingress コントローラーを再インストールする
ACK 専用クラスターに ALB Ingress コントローラーがインストールされている場合は、移行が完了した後に再インストールする必要があります。 ALB Ingress コントローラーのインストール方法の詳細については、「コンポーネントを管理する」をご参照ください。
インストールが完了したら、次のコマンドを実行して元のアプリケーションを削除し、kubectl を使用してアプリケーションがクラスターに接続されていることを確認します。詳細については、「クラスターの kubeconfig ファイルを取得し、kubectl を使用してクラスターに接続する」をご参照ください。
```
kubectl delete deployment alb-ingress-controller -n kube-system
```
ACK Virtual Node コンポーネントを再インストールする
ACK 専用クラスターに ACK Virtual Node コンポーネントがインストールされている場合、ビジネスの中断なしに移行するには、移行の完了後に ACK マネージド Pro クラスターに ACK Virtual Node コンポーネントを手動で再インストールする必要があります。
1. ACK コンソールにログインします。左側のナビゲーションペインで、[クラスター] をクリックします。
2. [クラスター] ページで、管理するクラスターを見つけ、その名前をクリックします。左側のナビゲーションペインで、[操作] > [アドオン] を選択します。
3. [アドオン] ページで、ACK Virtual Node コンポーネントを見つけてインストールします。
4. ACK Virtual Node コンポーネントがインストールされたら、次のコマンドを順番に実行して、元のコンポーネントと構成を削除します。
```
# 元の vk-webhook サービス、ack-virtual-node-controller デプロイメント、仮想ノードに関連する ClusterRoleBindings、および仮想ノード ServiceAccounts を順番に削除します。
kubectl -n kube-system delete service vk-webhook
kubectl -n kube-system delete deployment ack-virtual-node-controller
kubectl -n kube-system delete clusterrolebinding virtual-kubelet
kubectl -n kube-system delete serviceaccount virtual-kubelet
```
5. 移行が完了したら、ポッドを作成してクラスターが正常に動作するかどうかを確認します。

次の手順

ACK マネージド Pro クラスタに移行した後、ノードのセキュリティを強化するために、クラスタ内のノードが偽装するワーカー RAM ロールの権限を手動で制限する必要があります。詳細については、「ACK マネージドクラスターのワーカー RAM ロールの権限を手動で制限する」をご参照ください。
ACK 専用クラスターに cGPU Basic Edition がインストールされている場合、ACK マネージド Pro クラスタに移行した後、cGPU Basic Edition を cGPU Professional Edition にアップグレードする必要があります。詳細については、「ACK Pro クラスタで cGPU Basic Edition を cGPU Professional Edition にアップグレードする」をご参照ください。

よくある質問

サービスは ACK マネージドベーシッククラスター移行中に影響を受けるものは何ですか?

移行中、ACK 専用クラスターのコントロールプレーンコンポーネントは休止状態になります。実行中のサービスは影響を受けません。

移行プロセスにはどのくらいの時間がかかりますか?

クラスターの移行には、コントロールプレーンがスリープモードになる、etcd データがバックアップされる、マネージドコンポーネントが起動される、という 3 つの段階があります。プロセス全体は 10 ～ 15 分かかると予想されます。この間、API サーバーは 5 ～ 10 分利用できない状態になると予想されます。

クラスターの移行後、アクセスリンクは変更されますか?

移行後、API サーバーの SLB インスタンスの IP アドレスは変更されません。 kubeconfig ファイルを使用してクラスターにアクセスする場合、クラスターの IP アドレスは変更されません。

事前チェック中に ACK Virtual Node の環境変数構成で障害が発生した場合はどうすればよいですか?

ACK 仮想ノードコンポーネントが ACK 専用クラスターにインストールされている場合は、移行を開始する前に kube-apiserver の内部エンドポイントを手動で構成する必要があります。そのためには、次の手順を実行します。

[クラスター情報] ページで、kube-apiserver の内部エンドポイントを取得します。
[デプロイメント] ページで、kube-system 名前空間を選択し、ack-virtual-node-controller という名前のデプロイメントを見つけて、デプロイメントの spec.template.spec.containers[0].env フィールドに次の環境変数を追加します。
- KUBERNETES_APISERVER_HOST: kube-apiserver のプライベート IP アドレス。
- KUBERNETES_APISERVER_PORT: kube-apiserver のプライベートポート。ほとんどの場合、6443 に設定されています。