ACK 専用クラスターから ACK Pro マネージドクラスターへのホット移行 - Container Service for Kubernetes

ACK 専用クラスターを ACK マネージド Pro 版クラスターにホットマイグレーションできます。このプロセスでは、お使いのワークロードを中断することなくクラスターを移行します。

Container Service for Kubernetes (ACK) は、2024 年 8 月 21 日に ACK 専有クラスターの提供を停止しました。本番環境では、より高い信頼性、セキュリティ、およびスケジューリング効率を提供する ACK マネージド Pro クラスターの使用を推奨します。ACK マネージド Pro クラスターは、マネージド型のコントロールプレーン、高可用性、およびその他の高度な機能を特長としています。

前提条件

Kubernetes バージョン 1.18 以降の ACK 専用クラスター (移行対象のクラスター) があるものとします。クラスターをアップグレードする必要がある場合は、「手動でクラスターをアップグレードする」をご参照ください。
移行後もクラスターの Kubernetes バージョンは変更されません。移行とアップグレードの両方が必要な場合は、先にクラスターを移行し、その後「upgrading the cluster version」を実行することを推奨します。
移行の前に、クラスターの[基本情報] ページでタイムゾーンを設定する必要があります。これにより、移行後のACK マネージド Pro クラスターのコントロールプレーンが元のクラスターと同じタイムゾーンを使用するようになり、CronJob 実行時間の予期せぬ変更などの問題を回避できます。
移行対象クラスターと同じリージョンに、Standard ストレージクラスの Object Storage Service (OSS) バケットを作成していること。バケットのホットリンク保護が無効になっていることを確認してください。有効になっていると移行に失敗する可能性があります。詳細については、「Create a bucket」および「Hotlink protection」をご参照ください。

注意事項

項目	説明
課金	移行が成功すると、課金対象の項目が変わります。削除されたマスターノードの料金は発生しなくなります。代わりに、ACK から cluster management fees が請求されます。その他のクラウドリソースの課金は変更されません。 OSS バケットの作成は無料です。バケットにアップロードしたオブジェクトのストレージと、これらのオブジェクトへのアクセスによって生成されるトラフィックに対してのみ課金されます。詳細については、「Billing overview」をご参照ください。
パブリックアクセス	EIP を使用して API サーバーをパブリックに公開している場合、移行後もクラスターのアクセスアドレスは変わりません。以前の ACK 専有クラスターの一部では、パブリック向きの Server Load Balancer (SLB) インスタンスを使用して API サーバーにアクセスします。このようなクラスターを ACK マネージド Pro クラスターに移行した後、 API サーバーの内部向き Classic Load Balancer (CLB) インスタンスに EIP をバインドして、手動で EIP モードに切り替える必要があります。詳細については、「クラスターの API サーバーへのパブリックアクセスを制御する」をご参照ください。
カスタム Pod 設定	ACK 専用クラスターでカスタム Pod 設定が有効になっている場合、クラスターを ACK マネージド Pro 版クラスターに直接移行することはできません。移行前に `terway-controlplane` を停止し、移行後に再度有効化する必要があります。詳細については、「ACK 専用クラスターの移行時に `terway-controlplane` を停止する」をご参照ください。 Pod 設定をカスタマイズする方法については、「Pod の静的 IP アドレス、個別の vSwitch、および個別のセキュリティグループを設定する」をご参照ください。
マスターノード	一部の旧クラスターでは、Cloud Assistant エージェントがマスターノードにデフォルトでインストールされていません。手動でインストールする必要があります。詳細については、「Install the Cloud Assistant Agent」をご参照ください。移行後、マスターノードのステータスは `Not Ready` に変わります。
ECS インスタンスの解放	移行後に元のマスターノードを削除すると、ACK は従量課金の ECS インスタンスとそのデータディスクのみを自動的に解放します。サブスクリプションの ECS インスタンスは手動で解放する必要があります。詳細については、「Release an instance」をご参照ください。

ステップ 1: ACK 専用クラスターをACK マネージド Pro クラスターにホット移行する

前提条件を完了し、注意事項を確認したら、移行を開始できます。ホット移行後、 ACK マネージド Pro クラスターを ACK 専用クラスターにロールバックすることはできません。

ACKコンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
クラスターリスト ページで、移行するクラスターを見つけ、Actions 列の詳細>Professional 版マネージド Kubernetes に移行 を選択します。
Professional 版マネージド Kubernetes に移行 ダイアログボックスで、事前チェックと RAM 承認を完了し、ホットマイグレーション用に準備した OSS バケットを選択し、注意事項をよく読み、移行の確認 をクリックします。
事前チェック
事前チェック をクリックして Container Intelligence Service コンソールを開き、移行チェックを実行します。パネルでチェック項目を確認し、私はそれを理解し、同意します を選択してから、チェックを実行する をクリックします。
事前チェックに失敗した場合は、画面の指示に従って問題を解決してください。
RAM 認可
1. [Go to RAM console] をクリックして、ホット移行に必要な権限を付与します。また、OSS バケット名を取得します。次の手順でポリシーを変更する際に必要です。
2. 名前が k8sMasterRolePolicy で始まるポリシーをクリックします。詳細ページで、ポリシーの内容 タブをクリックし、次に ポリシードキュメントの編集 をクリックします。JSON で、Statement フィールドに次の内容を追加し、OK をクリックします。
  以下のコードで、<YOUR_BUCKET_NAME> を準備したバケットの名前に置き換えます。この名前は、Professional 版マネージド Kubernetes に移行 ダイアログボックスで指定したものと一致させる必要があります。山括弧 (<>) は含めないでください。
```
,
        {
            "Action": [
                "oss:PutObject",
                "oss:GetObject"
            ],
            "Effect": "Allow",
            "Resource": [
                "acs:oss:*:*:<YOUR_BUCKET_NAME>/*"  
            ]
        }
```
移行が完了すると、Professional 版マネージド Kubernetes に移行 ダイアログボックスにメッセージが表示されます。その後、クラスタータイプと Professional 版マネージド Kubernetes に移行 のステータスを確認できます。
- クラスタータイプ： クラスターリスト ページに戻ります。クラスタータイプ 列で、タイプが ACK 専用クラスター から ACK マネージドクラスター に変更されたこと、および クラスターの仕様 列に Professional と表示されていることを確認します。
- マスターノードのステータス: クラスターリスト ページで、対象クラスターの アクション 列の詳細をクリックします。左側のナビゲーションペインで、ノード>ノード を選択します。「ノード」ページで、[ロール/ステータス] 列を確認します。元のマスターノードのステータスが不明に変わります。このステータスは、マスターノードがクラスターから切断され、使用されなくなったことを示します。その後、それらを削除できます。詳細については、「ステップ 2: 元のマスターノードを削除する」をご参照ください。

手順 2: ホットマイグレーション後、ACK dedicated クラスターからマスターノードを削除する

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

コンソール

ACKコンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターの名前をクリックします。左側のナビゲーションウィンドウで、[ノード] > [ノード] を選択します。
ノード ページで、削除するマスターノードを探し、Actions 列で詳細>削除を選択します。複数のマスターノードを削除する場合は、それらを選択してページ下部の削除をクリックします。表示されたダイアログボックスで設定を構成し、注意事項をよくお読みいただいてから OK をクリックします。

kubectl

コマンドを実行する前に、kubectl を使用してクラスターに接続します。詳細については、「Obtain the kubeconfig of a cluster and use kubectl to connect to the cluster」をご参照ください。

削除するマスターノードの名前を取得して記録します。
```
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 専用クラスターに ALB Ingress コントローラーまたは ACK Virtual Node コンポーネントがインストールされているかどうかを確認します。インストールされている場合は、クラスターの移行が完了した後に、コンポーネントを再インストールまたは移行する必要があります。

クラスターリスト ページで、対象のクラスター名をクリックします。左側のナビゲーションペインで、操作 > アドオン管理を選択します。
アドオン管理 ページで、ALB Ingress controller または ACK Virtual Node コンポーネントを確認します。いずれかがインストールされている場合は、以降のセクションの説明に従って対処してください。
ALB Ingress コントローラーの再インストール
ACK 専用クラスターに ALB Ingress controller がインストールされている場合は、移行後に再インストールする必要があります。ALB Ingress controller のインストール方法の詳細については、「アドオンの管理」をご参照ください。
インストール後、次のコマンドを実行して元のアプリケーションを削除します。kubectl を使用してクラスターに接続していることを確認してください。詳細については、「Obtain the kubeconfig of a cluster and use kubectl to connect to the cluster」をご参照ください。
```
kubectl delete deployment alb-ingress-controller -n kube-system
```
ACK Virtual Node のマネージド版への移行
ACK Virtual Node コンポーネントが ACK 専用クラスターにインストールされている場合は、ワークロードをシームレスに移行するため、クラスター移行後にマネージド版へ移行する必要があります。
1. ACKコンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
2. [クラスター] ページで、管理するクラスターの名前をクリックします。左側のナビゲーションウィンドウで、[操作] > [アドオン] を選択します。
3. アドオン管理 ページで、ACK Virtual Node コンポーネントをインストールします。
4. ACK Virtual Node コンポーネントをインストールした後、次のコマンドを順番に実行して、古いコンポーネントと設定を削除します。
```
# 古い vk-webhook Service、ack-virtual-node-controller Deployment、virtual-kubelet ClusterRoleBinding、および virtual-kubelet ServiceAccount を順番に削除します。
kubectl -n kube-system delete service vk-webhook
kubectl -n kube-system delete deployment ack-virtual-node-controller
kubectl delete clusterrolebinding virtual-kubelet
kubectl -n kube-system delete serviceaccount virtual-kubelet
```
5. 移行が完了したら、新しい Pod を作成して、クラスターが想定どおりに動作しているかどうかをテストできます。

次のステップ

ACK マネージド型 Pro クラスターに移行した後、ノードのセキュリティを向上させるために、ワーカー RAM ロールの権限を手動で制限する必要があります。詳細については、「ACK マネージド型クラスターのワーカー RAM ロール権限を手動で制限する」をご参照ください。
cGPU 基本版が ACK 専用クラスターにインストールされている場合、ACK マネージド Pro 版クラスターに移行した後、cGPU プロフェッショナル版にアップグレードする必要があります。詳細については、「ACK Pro 版クラスターで cGPU 基本版から cGPU プロフェッショナル版にアップグレードする」をご参照ください。
超大規模クラスターや高並列のバーストが発生するシナリオでは、コントロールプレーンのパフォーマンスを予測可能にするため、コントロールプレーンリソースを事前に割り当てて専有することを推奨します。詳細については、「ACK Pro preset control plane」をご参照ください。ACK Pro のコントロールプレーンは、Pro XL、Pro 2XL、Pro 4XL の 3 つの事前定義ティアで提供されます。コントロールプレーンの容量は、API リクエストの同時実行数 (seats)、Pod スケジューリングレート (pods/second)、etcd データベースサイズ (GB) などのメトリクスで定義されます。

よくある質問

移行中にACK 専用クラスター上のサービスは影響を受けますか？

ACK 専用クラスターのコントロールプレーンコンポーネントは移行中にスリープモードに入りますが、実行中のワークロードは影響を受けません。

移行にかかる時間

移行プロセスには 10～15 分かかり、コントロールプレーンのスリープ、etcd データのバックアップ、マネージドコンポーネントの起動の 3 つのステージで構成されます。この期間中、API サーバーは 5～10 分間利用できなくなることが想定されます。

アクセスパスは変わりますか？

いいえ。API サーバー用の CLB インスタンスの IP アドレスは変更されません。kubeconfig を使用してクラスターにアクセスする場合、クラスターアドレスは変更されません。

ACK Virtual Node の事前チェック失敗

ACK Virtual Node コンポーネントが 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)。

ACK 専用クラスターのマスターノードを誤って削除した場合、どのように復旧すればよいですか？

復旧方法はクラスターのバージョンによって異なります：

クラスターバージョン 1.20 以降：コンソールを使用して新しいマスターノードをスケールアウトし、クラスターを復旧します。
クラスターバージョン 1.20 より前：このトピックの手順 1 に従って、専用クラスターを ACK Pro マネージドクラスターにホット移行します。システムは移行前に自動的に事前チェックを実行し、安全性を確保します。