古いソフトウェアに起因するセキュリティ脆弱性や安定性のリスクを回避するため、クラスターをタイムリーにアップグレードすることが不可欠です。 クラスターのアップグレードは、主にコントロールプレーンのアップグレードとノードプールのアップグレードの 2 つのフェーズで構成されます。
続行する前に、クラスタをアップグレードするの全プロセスを確認して、使用可能なメソッド、互換性要件、およびベストプラクティスについて学習してください。
アップグレード手順
最初にコントロールプレーンをアップグレードし、次にノードプールをアップグレードできます。ただし、ノードの kubelet とコンテナーランタイムのバージョンが、ターゲットのコントロールプレーンのバージョンと互換性があることを確認して、障害やサービスの中断を回避してください。
例：
コントロールプレーンがバージョン 1.32 で、ノードが 1.31 の場合、コントロールプレーンを 1.33 にアップグレードする前に、最初にノードを 1.32 にアップグレードする必要があります。
手順
ACK コンソール にログインします。左側のナビゲーションウィンドウで、[クラスタ] をクリックします。
[クラスタ] ページで、目的のクラスタを見つけて、その名前をクリックします。左側のペインで、 を選択します。
[クラスタのアップグレード] ページで、アップグレードの [ターゲットバージョン] を選択し、画面の指示に従ってアップグレードを完了します。
ステップ 1：コントロールプレーンをアップグレードする
1. 事前チェック
アップグレードする前に、事前チェックを実行して潜在的なリスクを特定します。これには以下が含まれます。
非推奨の API の使用
コンポーネントの互換性
クラスタ全体の正常性
Kubernetes 1.20 以降を実行しているクラスタの場合、システムは 非推奨の API をチェックします。これはアップグレードをブロックするものではありませんが、アップグレード後のスムーズな運用を確保するために、事前に問題を解決することをお勧めします。
事前チェックを実行する方法
[クラスタのアップグレード] ページで、事前チェック をクリックします。
スキャンが完了したら、[事前チェックの結果] セクションで結果を確認します。
例:
結果 | アクション |
正常 | アップグレードを続行します。 |
異常 | コンソールのガイダンスを使用して問題に対処するか、クラスタのチェック項目と修復ソリューション を参照してください。 |
2. アップグレードを実行する
期間:
ACK マネージド および Serverless Kubernetes クラスタ: アップグレードは高速で高可用性です。
専用クラスター: Master ノードは 1 つずつアップグレードされ、ノードごとに約 8 分かかります。
事前チェックの問題が解決したら、次の手順を実行します。
[今すぐアップグレード] をクリックします。
プロンプトに従って、コントロールプレーンのアップグレードを完了します。
アップグレード後、スケーリング中に追加された新しいノードは、アップグレードされたバージョンを自動的に使用します。
3. アップグレード後の検証
コントロールプレーンがアップグレードされたら、以下を確認します。
チェック項目 | 予期される結果 |
クラスタのバージョン | [クラスタ] ページでターゲットバージョンに更新されています。 |
API サーバーとコアコンポーネント | ステータスは正常です。 |
ビジネス アプリケーション | 期待どおりに実行されています。 |
Pod の作成 | 新しい Pod を正常に作成できます。 |
ノードの追加 | 問題なく新しいノードを追加できます。 |
ステップ 2：ノードプールをアップグレードする
コントロールプレーンをアップグレードした後、影響を最小限に抑えるために、オフピーク時にノードプールをアップグレードします。
ノードプールのアップグレードにより、各ノードの kubelet とコンテナーランタイムが更新されます。
1. 事前チェック
事前チェックでは以下を評価します。
ノードのステータス
システムリソース
ディスクの正常性
ネットワーク環境
事前チェックを実行する方法
[ノードプールのアップグレード] ページで、ターゲットのノードプールを見つけて、[アクション] 列の [アップグレード] をクリックします。
ページの下部にある [事前チェック] をクリックします。
[事前チェックの結果] セクションで結果を確認します。
結果 | アクション |
正常 | アップグレードを続行します。 |
異常 | コンソールのガイダンスを使用して問題に対処するか、クラスタのチェック項目と修復ソリューション を参照してください。 |
2. アップグレードポリシーを設定して開始する
期間:
インプレースアップグレード: バッチごとに約 5 ～ 10 分。
システムディスクの交換 (スナップショットなし): バッチごとに約 8 分。
ノードのドレイン時間も合計時間に影響します。
スナップショットが有効になっている場合、アップグレードはスナップショットの作成後にのみ開始されます (時間はデータ量によって異なります)。
アップグレード構成
構成項目 | 説明 |
バージョン情報 | kubelet とコンテナーランタイムの現在のバージョンと使用可能なバージョンが表示されます。 |
[アップグレードするノード] | すべてのノードをアップグレードするか、最初にサブセットをアップグレードして検証してから残りをアップグレードするかを選択します。 |
アップグレード方法 |
|
[バッチアップグレードポリシー] |
|
[今すぐアップグレード] をクリックし、プロンプトに従って開始します。
3. アップグレード後の検証
ノードプールのアップグレード後、以下を確認します。
チェック項目 | 予期される結果 |
ノードのバージョン | ノードの詳細ページで、kubelet と containerd のバージョンがターゲットと一致します。 |
Pod のスケジューリング | Pod は正常にスケジュールされています。 |
ビジネス アプリケーション | 期待どおりに機能します。 |
参照
ACK のリリースノート: Kubernetes バージョンのサポートポリシー
クラスタを自動的にアップグレードする: 自動アップグレードで O&M の労力を削減する
Kubernetes 1.24 以降では、Docker はコンテナーランタイムとしてサポートされなくなりました。 1.24+ にアップグレードする場合は、ノードのコンテナーランタイムを Docker から containerd に移行する必要があります。
Kubernetes 1.30 以降では、CentOS と Alibaba Cloud Linux 2 はサポートされなくなりました。サポートされている オペレーティングシステム を使用してください。