古いバージョンに関連するセキュリティおよび安定性のリスクを軽減するため、クラスターを速やかにアップグレードしてください。コントロールプレーンとノードプールをアップグレードして、クラスター全体が新しいバージョンで実行されるようにします。
クラスターをアップグレードする前に、「クラスターのアップグレード」を参照し、アップグレードのプロセス、方法、および重要な考慮事項を理解してください。
操作のエントリーポイント
最初にコントロールプレーンをアップグレードし、次にノードプールをアップグレードします。バージョン 1.30 以降を実行しているクラスターでは、サポートされているコントロールプレーンの最大バージョンは、すべてのノードの中で最も低い kubelet バージョンよりも 2 マイナーバージョン高くすることができます。たとえば、すべてのノードの中で最も低い kubelet バージョンが 1.30 の場合、コントロールプレーンは最大で 1.32 までアップグレードできます。
ACKコンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターの名前をクリックします。 左側のウィンドウで、 を選択します。
クラスターのアップグレード ページで、利用可能な 対象バージョン を選択し、画面の指示に従ってアップグレードプロセスを完了します。
コントロールプレーンのアップグレード
1. 事前チェック
コントロールプレーンのアップグレードの事前チェックでは、非推奨 API などの項目をスキャンし、コンポーネントの互換性やクラスター全体のステータスを確認します。
バージョン 1.20 以降を実行しているクラスターでは、事前チェックで非推奨 API がスキャンされます。スキャン結果はアップグレード プロセスには影響しません。これらは参考情報です。新しいクラスター バージョンが期待どおりに動作するように、アップグレード前に問題を解決してください。
コントロールプレーンのアップグレード タブで 事前チェック をクリックして、アップグレード前の潜在的なリスクをスキャンします。スキャンが完了したら、事前チェックの結果 セクションで結果を確認します。次の図に例を示します。
正常：アップグレードチェックは成功です。アップグレードを続行できます。
異常：この結果は、現在のクラスターの操作やステータスには影響しません。提供された解決策に基づいて問題を解決してください。詳細については、「クラスターのチェック項目と解決策」をご参照ください。
2. アップグレードの実行
所要時間：ACK マネージドクラスターと ACK サーバーレスクラスターの場合、アップグレードは ACK によって管理され、約 5 分かかります。ACK 専用クラスターの場合、マスターノードは順番に 1 つずつアップグレードされます。各ノードには約 8 分かかります。
事前チェックの問題を解決した後、アップグレード をクリックし、画面の指示に従ってコントロールプレーンをアップグレードします。アップグレード中は、ビジネス アプリケーションのデプロイや変更、クラスターのスケーリングやノードプールの管理などの運用保守操作を行わないでください。このような操作は、アップグレードを中断させたり、サービスの中断を引き起こしたりする可能性があります。
コントロールプレーンがアップグレードされると、スケールアウトによって追加されたノードもコントロールプレーンと同じバージョンで実行されます。
3. アップグレード後の検証
コントロールプレーンがアップグレードされた後、次の項目を確認します：
コントロールプレーンがアップグレードされました。クラスターのバージョンは [クラスター] ページで更新されます。
API サーバーとコアコンポーネントが [正常] な状態です。
ビジネス アプリケーションが期待どおりに動作します。
Pod を正常に作成できます。
ノードを正常に追加できます。
4. (オプション) コントロールプレーンの継続的なアップグレード
コントロールプレーンをより新しいバージョンに移行するには、手順 1 から 3 を繰り返して、コントロールプレーンの事前チェック、アップグレードの実行、結果の検証を行います。コントロールプレーンがクラスターで利用可能な最新バージョンに達するまで、このサイクルを繰り返します。
ノードプールのアップグレード
コントロールプレーンがアップグレードされた後、オフピーク時にできるだけ早くノードプールをアップグレードしてください。ノードプールのアップグレードには、ノード上の kubelet とコンテナランタイムのアップグレードが含まれます。
1. 事前チェック
ノードプールのアップグレードの事前チェックでは、ノードのステータス、システム リソース、ディスクの状態、およびネットワーク環境をスキャンします。
ノードプールのアップグレード ページで、リストから対象のノードプールを見つけ、アップグレード 列の アップグレード をクリックします。次に、ページ下部の 事前チェック をクリックして、アップグレードプロセス中の潜在的なリスクをスキャンします。スキャンが完了したら、事前チェックの結果 セクションで結果を確認します。
正常：アップグレードチェックは成功です。アップグレードを続行できます。
異常：この結果は、現在のクラスターの操作やステータスには影響しません。提供された解決策に基づいて問題を解決してください。詳細については、「クラスターのチェック項目と解決策」をご参照ください。
2. アップグレードポリシーの設定とアップグレードの実行
所要時間：所要時間はノードのバッチ処理方法によって異なります。インプレースアップグレードは、バッチごとに約 5〜10 分かかります。スナップショットなしのシステムディスクの交換によるアップグレードには約 8 分かかります。具体的な所要時間は、ノードのドレイン時間の影響を受けます。スナップショットを作成する場合、アップグレードはスナップショットが作成された後に開始されます。スナップショットの作成に必要な時間は、データ量によって異なります。
Update a node pool タブで、ノードプール リストから対象のノードプールを見つけ、今すぐアップグレードする をクリックします。
アップグレードポリシーの設定 パネルで、アップグレード情報を確認し、次の表の説明に従ってアップグレード ポリシーを設定してから、更新の開始 をクリックして、プロンプトに従ってノードプールのアップグレードを完了します。
設定項目 | 説明 |
バージョン情報 | kubelet とコンテナランタイムの現在および利用可能なバージョン。 |
[ノードのアップグレード] | すべてのノード をアップグレードするか、指定されたノード を選択してそれらのノードのみをアップグレードします。 |
[アップグレードの方法] |
|
[警告レベルのチェック項目を無視] | 自動的に実行される事前チェックで警告項目が返された場合に、ノードプールのアップグレードを続行するかどうかを指定します。 |
[一括更新ポリシー] |
|
3. アップグレード後の検証
ノードプールがアップグレードされた後、次の項目を確認します：
ノードがアップグレードされました。kubelet と containerd のバージョンはノード詳細ページで更新されます。
Pod のスケジューリングが正常に機能しています。
ビジネス アプリケーションが期待どおりに動作します。
関連ドキュメント
クラスターのアップグレード前およびアップグレード中によくある質問への回答については、「FAQ」をご参照ください。
ACK の Kubernetes バージョン サポート ポリシーに関する情報については、「バージョンガイド」をご参照ください。
バージョン 1.24 以降、Docker は組み込みのコンテナランタイムとしてサポートされなくなりました。バージョン 1.24 以降にアップグレードする場合は、「ノードのコンテナランタイムを Docker から containerd に移行する」必要があります。
バージョン 1.30 以降、CentOS と Alibaba Cloud Linux 2 はサポートされなくなりました。サポートされている他の「オペレーティングシステム」を使用してください。
または、クラスターの自動アップグレードを有効にして、バージョン管理に関連する運用保守のワークロードを削減することもできます。詳細については、「クラスターの自動アップグレード」をご参照ください。
アップグレードする前に、「非管理対象ノードのノードプールへの移行」で説明されているように、クラスター内の孤立ノードをノードプールに追加して、すべてのノードを統一された方法で管理できるようにします。