すべてのプロダクト
Search

このプロダクト

    Container Service for Kubernetes:ACK Lingjun クラスターのアップグレード

    ドキュメントセンター

    Container Service for Kubernetes:ACK Lingjun クラスターのアップグレード

    最終更新日:Mar 27, 2026

    ACK Lingjun クラスターでは、インプレース更新を用いて Kubernetes のバージョンを 1.20 から 1.22 までアップグレードできます。クラスター全体を一度にアップグレードするか、コントロールプレーンとノードプールを個別にアップグレードするかを選択できます。

    仕組み

    ACK Lingjun クラスターのアップグレードは、以下の手順で実行されます。

    1. 事前チェックを実行します。 ACK は、変更を加える前にクラスターをスキャンし、互換性に関する問題を検出します。報告されたすべての問題を修正してから、次のステップに進んでください。

    2. コントロールプレーンをアップグレードします。 ACK は kube-apiserver、kube-controller-manager、および kube-scheduler を更新します。また、kube-proxy などの Kubernetes コンポーネントも更新されます。このステップ以降に追加される新規ノードは、新しい Kubernetes バージョンで実行されます。

    3. ノードプールをアップグレードします。 ACK は、既存のノード上の kubelet およびコンテナランタイムをバッチ単位で更新します。複数のノードプールがある場合、1 つのノードプールずつ順次アップグレードされます。

    4. 検証を行います。 クラスターのバージョン、ノードプールのステータス、およびアプリケーションの健全性を確認します。

    Upgrade procedure overview

    前提条件

    開始する前に、以下の条件を満たしていることを確認してください。

    注意事項

    Kubernetes バージョンの互換性

    アップグレードを実行する前に、ACK コンソールのContainer Service for Kubernetes コンソールクラスターページのバージョン列を確認し、現在の Kubernetes バージョンを特定してください。Helm チャートで非推奨の API リソースが使用されている場合は、アップグレード前にそれらのマニフェストを更新してください。非推奨 API の詳細については、「非推奨の API」および該当するリリースノートをご参照ください。

    Kubernetes 1.20 以降を実行しているクラスターでは、事前チェック時に非推奨 API の使用状況もスキャンされます。この結果は参考情報であり、アップグレードをブロックしません。

    機能ごとの考慮事項

    クラスターで以下の機能のいずれかを使用している場合は、アップグレード前に各機能に関する考慮事項を確認してください。

    機能 アップグレード時の動作 必要な操作
    FlexVolume FlexVolume 1.11.2.5 以前でマウントされた Object Storage Service (OSS) ボリュームが再マウントされます。 アップグレード後に OSS ボリュームを使用する Pod を再作成します。可能な場合は、FlexVolume から CSI へ移行します。詳細については、「FlexVolume から CSI への移行」をご参照ください。
    オートスケーリング Cluster Autoscaler が自動的に最新バージョンに更新されます。 Cluster Autoscaler が期待通りのバージョンで実行されていることを確認してください。「ノードのオートスケーリング」をご参照ください。
    リソース予約 Kubernetes 1.18 へのアップグレード後、ACK が自動的にリソース予約を設定します。ノードのリソース使用量が高い場合、終了した Pod が再スケジュールされない可能性があります。 アップグレード前に、各ノードで CPU の少なくとも 50%、メモリの少なくとも 70% を予約してください。「リソース予約ポリシー」をご参照ください。
    externalTrafficPolicy: Local トラフィックはノードローカルの Pod にのみ転送されます。アプリケーション Pod が他のノード上にある場合、到達不能になります。 Server Load Balancer (SLB) インスタンスで externalTrafficPolicy: Local が設定されていないか確認してください。「クラスターが LoadBalancer サービスによって公開された SLB インスタンスの IP アドレスにアクセスできない場合の対処方法」をご参照ください。
    API サーバー依存型アプリケーション コントロールプレーンのアップグレード中に、API サーバーが一時的に中断される可能性があります。list-and-watch 操作を使用するアプリケーションに影響が出ます。 アプリケーションが切断時に監視操作を自動的に再試行するよう設定してください。API サーバーにアクセスしないアプリケーションには影響ありません。
    kubectl アップグレード後、ローカルマシン上の kubectl が新しい API サーバーのバージョンと互換性を持たなくなり、invalid object doesn't have additional properties エラーが発生する可能性があります。 クラスターのアップグレード後に kubectl を更新してください。「kubectl のインストール」をご参照ください。

    カスタム構成に関する考慮事項

    項目 考慮事項
    ネットワーク アップグレードでは yum を使用してパッケージをダウンロードします。クラスターでカスタムネットワーク構成を使用している場合は、yum makecache を実行して yum が正しく動作することを確認してください。
    OS イメージ カスタム OS イメージは ACK によって検証されていません。カスタム OS イメージを使用するクラスターでは、アップグレードが成功する保証はありません。
    その他のカスタム構成 スワップパーティション、CLI 経由で変更された kubelet 設定、またはその他の非標準構成により、アップグレードが失敗したり、これらの設定が失われたりする可能性があります。

    クラスターのアップグレード

    重要

    ACK は各アップグレードの前に事前チェックを実行しますが、このチェックでは互換性のない API、機能、または構成をすべて検出できるとは限りません。共有責任モデルに基づき、アップグレードを実行する前に、関連するすべてのリリースノートおよびアップグレードガイドを確認してください。

    ビジネスへの影響を最小限に抑えるため、ピーク時間帯を避けてアップグレードを実行してください。

    ステップ 1：コントロールプレーンのアップグレード

    1. ACK コンソール にログインします。左側のナビゲーションウィンドウで、クラスター をクリックします。

    2. クラスター ページで、アップグレード対象のクラスター名をクリックします。左側のウィンドウで、操作 > クラスターのアップグレード を選択します。

    3. クラスターのアップグレード ページで、アップグレード後のバージョン を設定し、事前チェック をクリックします。事前チェックが完了したら、事前チェック結果 セクションで結果を確認します。

      • 問題なし： クラスターは事前チェックを通過しました。次のステップに進んでください。

      • 問題が検出されました： クラスターは引き続き正常に稼働します。コンソールの提案に基づいて報告された問題を修正し、再度事前チェックを実行してください。「クラスターの確認項目および問題の修正方法」をご参照ください。

    4. 更新の開始 をクリックし、画面上の指示に従ってください。クラスターのアップグレード ページの右上隅で、アップグレード履歴を確認できます。コントロールプレーンのアップグレードが完了したら、クラスター ページに戻り、バージョン 列で Kubernetes のバージョンを確認してください。

    コントロールプレーンのアップグレード中に ACK が実行する処理：

    • コントロールプレーンのコンポーネント（kube-apiserver、kube-controller-manager、kube-scheduler）を更新します。

    • kube-proxy などの Kubernetes コンポーネントを更新します。

    ステップ 2：ノードプールのアップグレード

    コントロールプレーンのアップグレードが完了したら、できるだけ早期に既存のノードプールをアップグレードしてください。まだアップグレードされていないノードプール内のノードは、引き続き前の Kubernetes バージョンで実行されます。

    詳細な手順については、「ノードプールの更新」および「Lingjun ノードプールの更新」をご参照ください。

    ノードプールのアップグレード中に ACK が実行する処理：

    • 各ノード上の kubelet およびコンテナランタイムを更新します。

    • Docker から containerd への移行： コンテナランタイムを Docker から containerd に切り替える場合、ACK は各ノードのシステムディスクを置き換えます。これにより、OS も更新され、アプリケーションが再インストールされます。このようなタイプのアップグレードを開始する前に、システムディスク上のデータをバックアップしてください。

    • その他のすべてのシナリオでは、ACK はインプレース更新を実行します。

    バッチ更新のルール：

    • 複数のノードプールがある場合、1 つのノードプールずつ順次アップグレードされます。

    • 1 つのノードプール内で、ノードはバッチ単位でアップグレードされます。最初のバッチでは 1 台のノード、その後の各バッチでは倍増（1 → 2 → 4 → 8…）します。

    • ノードプールのアップグレード ページで、最大バッチサイズを設定できます。推奨値は 10 です。

    • 一時停止したアップグレードを再開した後も、バッチングポリシーは継続して適用されます。

    アップグレードの検証

    両方のフェーズが完了した後、以下の内容を確認してください。

    • クラスター ページのバージョン 列に、新しい Kubernetes バージョンが表示されていること。

    • すべてのノードプールは実行中で、正常です。

    • クラスター内のアプリケーションワークロードが想定通りに機能していること。

    • アップグレード済みノードの kubelet バージョンを確認し、ノードプールのアップグレードが完了していることを検証すること。

    トラブルシューティング

    「the aliyun service is not running on the instance」というエラーでアップグレードが失敗する

    クラウドアシスタントエージェントが利用不可のため、アップグレードコマンドをノードに送信できません。クラウドアシスタントクライアントを起動または再起動し、アップグレードを再試行してください。「クラウドアシスタントエージェントの起動、再起動、停止、またはアンインストール」をご参照ください。

    PLEG not healthy エラー

    ノード上のコンテナまたはコンテナランタイムが応答していません。影響を受けたノードを再起動し、再度アップグレードを開始してください。

    次のステップ