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 バージョンは移行後も変更されません。クラスターの移行とアップグレードの両方が必要な場合は、まずクラスターを移行してから、「クラスターバージョンのアップグレード」を行うことを推奨します。
移行前に、クラスターの[基本情報]ページでタイムゾーンを設定する必要があります。これは、移行後のACK マネージド Pro クラスターのコントロールプレーンが元のクラスターと同じタイムゾーンを使用するようにして、CronJob の実行時間に予期しない変更が発生するなどの問題を回避するためです。
移行対象のクラスターと同じリージョンに、Standard ストレージクラスの Object Storage Service (OSS) バケットを作成済みであること。ホットリンク防止は移行の失敗を引き起こす可能性があるため、バケットでホットリンク防止が無効になっていることを確認してください。詳細については、「バケットの作成」および「ホットリンク防止」をご参照ください。

考慮事項

項目	説明
課金	移行が成功すると、課金項目が変更されます。削除されたマスターノードに対しては課金されなくなります。代わりに、ACK によってクラスター管理料金が請求されます。他のクラウドリソースの課金は変更されません。 OSS バケットの作成は無料です。課金対象は、バケットにアップロードされたオブジェクトのストレージと、これらのオブジェクトへのアクセスによって発生するトラフィックのみです。詳細については、「課金概要」をご参照ください。
パブリックアクセス	API サーバーが EIP を使用してパブリックに公開されている場合、移行後もクラスターのアクセスアドレスは変更されません。一部の古い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、および個別のセキュリティグループを設定する」をご参照ください。
マスターノード	一部の古いクラスターでは、デフォルトでマスターノードにクラウドアシスタントエージェントがインストールされていません。手動でインストールする必要があります。詳細については、「クラウドアシスタントエージェントのインストール」をご参照ください。移行後、マスターノードのステータスは [Not Ready] に変わります。
ECS インスタンスのリリース	移行後に元のマスターノードを削除すると、ACK は従量課金の ECS インスタンスとそのデータディスクのみを自動的にリリースします。サブスクリプションの ECS インスタンスは手動でリリースする必要があります。詳細については、「インスタンスのリリース」をご参照ください。

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

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

ACKコンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
クラスターリスト ページで、移行するクラスターを探し、Actions 列で詳細 > Professional 版マネージド Kubernetes に移行 を選択します。
Professional 版マネージド Kubernetes に移行 ダイアログボックスで、事前チェックと RAM 認可を完了し、ホット移行用に準備した OSS バケットを選択し、注意事項をよく読んでから、移行の確認 をクリックします。
事前チェック
[事前チェック] をクリックして Container Intelligence Service コンソールを開き、移行チェックを実行します。表示されたパネルでチェック項目を確認し、私はそれを理解し、同意します を選択してから、チェックを実行する をクリックします。
事前チェックが失敗した場合は、画面の指示に従って問題を修正してください。
RAM 認可
1. [RAM コンソールへ移動] をクリックして、ホット移行に必要な権限を付与します。また、次のステップでポリシーを編集するために必要な OSS バケット名を取得してください。
2. 名前が k8sMasterRolePolicy で始まるポリシーをクリックします。詳細ページで、[ポリシー内容] タブをクリックし、ポリシードキュメントの編集 をクリックします。JSON で、[ステートメント] フィールドに次の内容を追加し、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] と表示されていることを確認します。
- マスターノードのステータス: クラスターリスト ページで、対象クラスターの アクション 列にある詳細をクリックします。左側のナビゲーションペインで、ノード>ノード を選択します。 Nodes ページで、[ロール/ステータス] 列を確認します。元のマスターノードのステータスが不明に変わります。このステータスは、マスターノードがクラスターから切断され、使用されなくなったことを示します。その後、それらを削除できます。詳細については、「ステップ 2: 元のマスターノードを削除する」をご参照ください。

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

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

コンソール

ACKコンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターの名前をクリックします。左側のナビゲーションウィンドウで、[ノード] > [ノード] を選択します。
ノード ページで、削除するマスターノードを探し、Actions 列で詳細 > 削除を選択します。複数のマスターノードを削除するには、対象のノードを選択し、ページの下部にある削除をクリックします。表示されるダイアログボックスで、設定を構成し、注意事項をよく読んでから、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 専用クラスターに ALB Ingress コントローラーまたは ACK Virtual Node コンポーネントがインストールされているかどうかを確認します。その場合は、クラスターの移行が完了した後に、コンポーネントを再インストールまたは移行する必要があります。

クラスターリスト ページで、対象クラスターの名前をクリックします。左側メニューで、操作 > アドオン管理 を選択します。
アドオン管理 ページで、ALB Ingress コントローラーまたは ACK 仮想ノードコンポーネントを確認してください。どちらかがインストールされている場合は、次のセクションで説明されているように対処してください。
ALB Ingress コントローラーの再インストール
ACK 専用クラスターに ALB Ingress コントローラーがインストールされている場合、移行後に再インストールが必要です。ALB Ingress コントローラーのインストール方法の詳細については、「アドオンの管理」をご参照ください。
インストール後、次のコマンドを実行して元のアプリケーションを削除します。kubectl を使用してクラスターに接続していることを確認してください。詳細については、「クラスターの kubeconfig を取得し、kubectl を使用してクラスターに接続する」をご参照ください。
```
kubectl delete deployment alb-ingress-controller -n kube-system
```
ACK 仮想ノードのマネージドバージョンへの移行
ACK 仮想ノードコンポーネントが ACK 専用クラスターにインストールされている場合は、クラスター移行後にマネージドバージョンに移行して、ワークロードのシームレスな移行を確保する必要があります。
1. ACKコンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
2. [クラスター] ページで、管理するクラスターの名前をクリックします。左側のナビゲーションウィンドウで、[操作] > [アドオン] を選択します。
3. アドオン管理 ページで、ACK 仮想ノードコンポーネントをインストールします。
4. ACK 仮想ノードコンポーネントがインストールされた後、次のコマンドを順番に実行して、古いコンポーネントと設定を削除します。
```
# 古い 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 ロールの権限を手動で制限するをご参照ください。
ACK 専用クラスターに cGPU ベーシック版がインストールされている場合、ACK Pro 版マネージドクラスターに移行した後、cGPU プロフェッショナル版にアップグレードする必要があります。詳細については、「ACK Pro クラスターで cGPU ベーシック版を cGPU プロフェッショナル版にアップグレードする」をご参照ください。
超大規模クラスターや高同時実行バーストのシナリオでは、コントロールプレーンリソースを事前に割り当てて専用化することで、予測可能なコントロールプレーンのパフォーマンスを確保できます。詳細については、「ACK Pro プリセットコントロールプレーン」をご参照ください。ACK Pro コントロールプレーンには、Pro XL、Pro 2XL、Pro 4XL の 3 つの事前定義されたティアがあります。コントロールプレーンのキャパシティは、API リクエストの同時実行数 (シート)、Pod のスケジューリングレート (Pod/秒)、etcd データベースサイズ (GB) などのメトリクスによって定義されます。

よくある質問

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

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

移行期間

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

アクセスパスは変更されますか？

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

ACK 仮想ノードの事前チェックの失敗

ACK 専用クラスターに ACK Virtual Node コンポーネントがインストールされている場合、移行前に kube-apiserver の内部エンドポイントを手動で設定する必要があります。これを行うには、次の手順を実行します。

クラスター情報 ページで、kube-apiserver の内部エンドポイントを取得します。
デプロイメント ページで、kube-system 名前空間を選択し、ack-virtual-node-controller Deployment を見つけて、その 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 クラスターにホット移行します。システムは移行前に自動的に事前チェックを実行して安全性を確保します。