制御プレーンホスティングや制御プレーンの高可用性など、ACK Proクラスターの機能を使用するには、ACK専用クラスターのみがある場合に、業務を中断することなく、ホットマイグレーションを実行してACK専用クラスターからACK Proクラスターに移行できます。
前提条件
前提条件 | 説明 |
クラスター | Kubernetes 1.18以降を実行する (移行する) ACK専用クラスターが作成されます。 クラスターを更新する方法の詳細については、「手動でACKクラスターをアップグレードする」をご参照ください。 |
OSS バケット | 移行するACKクラスターのリージョンにObject Storage Service (OSS) バケットが作成され、ホットリンク保護は移行に失敗する可能性があるため、バケットのホットリンク保護は無効になっています。 詳細については、「バケットの作成」および「ホットリンク保護」をご参照ください。 |
考慮事項
項目 | 説明 |
パブリックアクセス | 一部の古いACK専用クラスターは、インターネットに接続するServer Load Balancer (SLB) インスタンスを使用して、パブリックアクセスを介してAPIサーバーを公開します。 これらのクラスターからACK Proクラスターに移行すると、インターネットに接続されたSLBインスタンスを使用してAPIサーバーをパブリックアクセスに公開できなくなります。 APIサーバーをパブリックアクセスに公開できるように、APIサーバーの内部接続SLBインスタンスにEIP (elastic IP address) を手動で関連付ける必要があります。 EIPモードに切り替える方法の詳細については、「クラスターのAPIサーバーへのパブリックアクセスの制御」をご参照ください。 |
カスタムポッド設定 | ACK専用クラスターのカスタムポッド設定が有効になっている場合、クラスターをACK Proクラスターに移行することはできません。 移行開始前にterway-controlplaneを停止し、移行完了後にterway-controlplaneを有効にする必要があります。 詳細については、「クラスター移行前のterway-controlplaneの停止」をご参照ください。 ポッド構成をカスタマイズする方法の詳細については、「静的IPアドレス、個別のvSwitch、およびポッドごとに個別のセキュリティグループを構成する」をご参照ください。 |
マスターノード | 一部の古いマスターノードにはCloud Assistant Agentがインストールされていません。 手動でインストールする必要があります。 詳細については、「Cloud Assistant Agentのインストール」をご参照ください。 移行が完了すると、マスターノードのステータスはNot Readyに変わります。 |
ECSインスタンスのリリース | マスターノードの削除時にElastic Compute Service (ECS) インスタンスをリリースする場合、ACKはすべての従量課金ECSインスタンスとそのデータディスクをリリースします。 サブスクリプションECSインスタンスを手動でリリースする必要があります。 詳細については、「インスタンスのリリース」をご参照ください。 |
手順1: ホットマイグレーションを実行してACK専用クラスターからACK Proクラスターに移行する
開始する前に、すべての前提条件が満たされ、考慮事項を読んで理解していることを確認してください。 ACK Proクラスターに移行した後、ACK専用クラスターにロールバックできません。
ACKコンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、移行するACKクラスターの [操作] 列で、[詳細] > [プロへの移行] を選択します。
[Proに移行] ダイアログボックスで、事前チェックとResource Access Management (RAM) 権限付与を完了し、ホット移行用に作成したOSSバケットを選択して、[OK] をクリックします。
移行が完了すると、[Proに移行] ダイアログボックスにメッセージが表示されます。 ACKクラスターのタイプとマスターノードのステータスを確認できます。
クラスタータイプ: [クラスター] ページに戻ります。 [タイプ] 列のクラスタータイプがACK DedicatedからACK Proに変わります。
マスターノードのステータス: [クラスター] ページで、クラスターの [操作] 列の [詳細] をクリックします。 左側のナビゲーションウィンドウで、[ノード] > [ノード] を選択します。 マスターノードの [ロール] /[ステータス] 列に [不明] と表示された場合、マスターノードはクラスターから切断されます。 ホットマイグレーションの完了後にマスターノードを削除するには、ステップ2: ホットマイグレーションが完了した後にACK専用クラスターからマスターノードを削除するを参照してください。
手順2: ホットマイグレーションが完了した後、ACK専用クラスターからマスターノードを削除する
ホットマイグレーションが完了したら、コンソールを使用するか、kubectlコマンドを実行して、ACK専用クラスターからマスターノードを削除できます。
コンソールの使用
ACKコンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターの名前をクリックします。 左側のナビゲーションウィンドウで、 を選択します。
[ノード] ページで、マスターノードの [操作] 列で [詳細] > [削除] を選択するか、1つ以上のマスターノードを選択して下部の [一括削除] をクリックします。 表示されるダイアログボックスで、パラメーターを設定し、[OK] をクリックします。
kubectlを使う
コマンドを実行する前に、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: コンポーネントの処理
ALB Ingressコントローラの再インストール
ACK専用クラスターにALB Ingressコントローラーがインストールされている場合は、移行完了後に再インストールする必要があります。 ALB Ingressコントローラーのインストール方法の詳細については、「コンポーネントの管理」をご参照ください。 ALB Ingressコントローラーをインストールしたら、kubectlを使用して次のコマンドを実行し、元の配置を削除する必要があります。 コマンドを実行する前に、kubectlクライアントがクラスターに接続されていることを確認してください。 詳細については、「クラスターのkubeconfigファイルを取得し、kubectlを使用してクラスターに接続する」をご参照ください。
kubectl delete deployment alb-ingress-controller -n kube-system
ACK仮想ノードコンポーネントの再インストール
ACK専用クラスターにACK仮想ノードコンポーネントがインストールされている場合、業務を中断せずに移行するには、移行完了後にACK仮想ノードコンポーネントをACK Proクラスターに再インストールする必要があります。
ACKコンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターの名前をクリックします。 左側のナビゲーションウィンドウで、 を選択します。
[アドオン] ページで、ACK仮想ノードコンポーネントを見つけてインストールします。
ACK仮想ノードコンポーネントをインストールしたら、次のコマンドを順番に実行して、元のコンポーネントと設定を削除します。
# Delete the original vk-webhook Service, ack-virtual-node-controller Deployment, ClusterRoleBindings related to virtual nodes, and virtual node ServiceAccounts in sequence. 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
移行が完了したら、ポッドを作成してクラスターが正常に実行されるかどうかを確認します。
次のステップ
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専用クラスターのサービスは移行中に影響を受けますか。
クラスターの移行中、ACK専用クラスターの制御コンポーネントはスリープモードになりますが、実行中のサービスは影響を受けません。
移行プロセスにはおよそどのくらいの時間がかかりますか?
クラスターの移行には、制御プレーンのスリープモードへの移行、etcdデータのバックアップ、および管理対象コンポーネントの起動の3つの段階が含まれます。 プロセス全体には約10〜15分かかると予想され、その間、APIサーバーは約5〜10分間使用できないと予想されます。
クラスターの移行後、IPアドレスは変更されますか。
移行後も、SLB APIサーバーのIPアドレスは変わりません。 KubeConfigを介してクラスターにアクセスする場合、クラスターエンドポイントも変更されません。
事前チェック中にACK仮想ノードの環境変数設定の失敗を処理するにはどうすればよいですか。
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に設定されています。