すべてのプロダクト
Search

このプロダクト

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

    ドキュメントセンター

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

    最終更新日:Jan 14, 2026

    古いクラスターバージョンに関連するセキュリティおよび安定性のリスクを回避し、最新の Kubernetes 機能とテクニカルサポートを利用するために、クラスターバージョンをタイムリーにアップグレードしてください。Container Service for Kubernetes (ACK) は、アップグレード前のチェック、設定可能なアップグレードポリシーとペース調整、およびアップグレード進捗のモニタリングを提供し、スムーズなクラスターアップグレードを保証します。

    アップグレードの理由

    ACK では、Kubernetes の最新 3 つのマイナーバージョンを使用してクラスターを作成できます。たとえば、ACK が Kubernetes 1.31、1.32、1.33 をサポートしている場合、バージョン 1.30 を使用するクラスターは作成できなくなります。また、期限切れのパッチバージョンを使用するクラスターも作成できません。詳細については、「バージョンガイド」をご参照ください。

    古いバージョンを実行しているクラスターには、セキュリティと安定性のリスクがあります。クラスターバージョンが期限切れになると、新しい Kubernetes バージョンの機能やバグ修正の恩恵を受けられなくなります。また、タイムリーで効果的なテクニカルサポートを受けられなくなり、パッチが適用されていないセキュリティ脆弱性のリスクにさらされます。

    重要

    クラスターをアップグレードする際、ACK は事前チェックを実行します。ただし、これらのチェックでは、互換性のないすべての機能設定や API を検出できるわけではありません。責任共有モデルに基づき、ヘルプドキュメントの確認や、コンソールおよび内部メッセージの監視を通じて、バージョンリリースに関する情報を常に把握する責任はお客様にあります。クラスターをアップグレードする前に、新しいバージョンのリリースノートを確認してください。

    アップグレードの影響

    ACK は、クラスターのアップグレード中にアプリケーション Pod の継続性と安定性を確保するために、段階的およびバッチ式のアップグレードポリシーを提供します。

    • 事前チェック：コントロールプレーンまたはノードプールをアップグレードする前に、ACK は事前チェックを実行し、非推奨 API、互換性のないコンポーネントバージョン、ノードやディスクのステータスに関する問題など、潜在的な互換性リスクを特定します。ACK は、これらの問題を解決するための提案も提供します。事前チェックは、クラスターのサービスに影響を与えません。

    • コントロールプレーン：

      • ACK マネージドクラスター：API Server は ACK によって管理されており、アップグレード中にローリング方式で再起動されます。このプロセスは通常、実行中のアプリケーションに影響を与えません。アプリケーションが API Server に強く依存している場合、一時的な切断により接続をリトライする必要がある場合があります。

      • ACK 専用クラスター：アップグレード中、ACK は各マスターノードを順次インプレースアップグレードします。このプロセスは通常、実行中のアプリケーションに影響を与えません。アプリケーションが API Server に強く依存している場合、一時的な切断により接続をリトライする必要がある場合があります。

    • ノードプール：サービスの継続性を確保するため、ノードはバッチでアップグレードされます。バッチごとの最大ノード数やバッチ間の間隔などを指定して、バッチアップグレードポリシーをカスタマイズし、サービスへの影響を制御できます。

      • インプレースアップグレード中、ディスクは交換されず、ノードも再初期化されません。アプリケーション Pod は実行を継続し、サービスは中断されません。

      • システムディスク置換アップグレードでは、ノードのドレイン、システムディスクの交換、ノードの再初期化が行われます。以下の影響にご注意ください：

        • システムディスク置換アップグレード中、ACK はノードをドレインします。ノード上の Pod は、Pod Disruption Budget (PDB) に従って、他の利用可能なノードに退避されます。高可用性を確保するため、マルチレプリカのデプロイメント戦略を使用し、ワークロードを複数のノードに分散させ、重要なサービスには PDB を設定して、同時に中断される可能性のある Pod の数を制御してください。これにより、ノードのメンテナンス操作中のサービスの継続性が維持されます。

        • システムディスク置換アップグレード中、ACK はノードプールの現在の設定に基づいてノードを再初期化します。この設定には、ノードのログイン方法、OS イメージ、コンテナランタイムバージョンなどが含まれます。ノードプールを編集して、ノードプールの設定を更新してください。他の方法でノードに加えられた変更は、アップグレード中に上書きされます。

        • ノード上の Pod がシステムディスクを指す HostPath を参照している場合、システムディスク置換アップグレード後に HostPath ディレクトリ内のデータは失われます。

    アップグレードプロセス

    ACK クラスターのアップグレードには、コントロールプレーンとノードプールのアップグレードが含まれます。開始前に事前チェックを実行し、影響を最小限に抑えるためにオフピーク時間にアップグレードをスケジュールしてください。コントロールプレーンのアップグレードが完了したら、クラスターの動作状態を注意深く確認します。その後、コントロールプレーンのバージョンに合わせてノードプールをアップグレードします。

    image

    1. 事前準備

    • ACK リリースノートに基づいて、アップグレードのターゲットバージョンを決定します。ACK は一度に 1 つのマイナーバージョンのみのアップグレードをサポートしています。バージョンをスキップしたり、以前のバージョンにロールバックしたりすることはできません。

    • ターゲットバージョンのバージョンガイドを注意深くお読みください。アップグレード後の互換性の問題を避けるため、アップグレードの考慮事項、主な変更点、非推奨の機能を必ず理解してください。

    • クラスターのメンテナンスウィンドウを計画します。事前に事前チェックを実行して潜在的なリスクを特定し、オフピーク時間にアップグレードを実行してください。

    2. コントロールプレーンのアップグレード

    1. 事前チェックの実行：アップグレード前に事前チェックを実行します。すべてのチェック項目に合格するか、特定されたすべての問題が修正された後にのみ、アップグレードを進めてください。

      事前チェックでは、非推奨 API (バージョン 1.20 以降)、コンポーネントの互換性、機能設定の互換性、クラスターのステータス、コントロールプレーンコンポーネントのステータスなどの項目を検査します。

    2. アップグレードの実行：事前チェックに合格した後、アップグレードを実行します。

      • ACK マネージドクラスターおよびACK Serverless クラスター：ACK がアップグレードを管理します。これには kube-apiserver、kube-controller-manager、kube-scheduler、kube-proxy などのコントロールプレーンコンポーネントのアップグレードが含まれます。

      • ACK 専用クラスター：サービスの継続性を最大化し、データ移行や設定調整のリスクを低減するために、インプレースアップグレードが使用されます。

        プロセスを表示するにはクリック

        1. ACK がクラスターの etcd とコンテナランタイムのアップグレードが必要であると検出すると、マスターノード上でそれらを 1 つずつアップグレードします。

        2. マスターノードが 1 つずつ選択され、アップグレードされます。現在アップグレード中のマスターノードの ID が表示されます。

        3. kube-apiserver、kube-controller-manager、kube-scheduler、kube-proxy などのマスターコンポーネントをアップグレードします。

        4. マスターノード上の kubelet をアップグレードします。

    3. アップグレード後のチェック：クラスターバージョンが更新され、コアコンポーネント、アプリケーション、Pod の作成、ノードの追加がすべて期待どおりに機能していることを確認します。

    3. ノードプールのアップグレード

    ノードプールのアップグレードには、kubelet とコンテナランタイムのアップグレードが含まれます。

    1. 事前チェックの実行：アップグレード前に事前チェックを実行します。すべてのチェック項目に合格するか、特定されたすべての問題が修正された後にのみ、アップグレードを進めてください。

      事前チェックでは、ノードのステータス、システムリソース、ディスクのステータス、ネットワーク環境などの項目を検査します。

    2. アップグレードポリシーの設定とアップグレードの実行：アップグレード方法 (インプレースまたはディスク置換) を選択し、バッチアップグレードポリシーを設定します。これには、バッチごとの最大ノード数の指定や、スナップショットを自動的に作成するかどうかの設定が含まれます。

    3. アップグレード後のチェック：kubelet とコンテナランタイムのバージョンが更新され、Pod のスケジューリングとアプリケーションが期待どおりに機能していることを確認します。

    4. その他の手順

    • OS イメージの変更：ノードプールの OS イメージをアップグレードしたり、OS タイプを切り替えたりする (例：Alibaba Cloud Linux 2 から Alibaba Cloud Linux 3 へ) 場合は、「オペレーティングシステムの変更」をご参照ください。

    • クラスターコンポーネント：ACK はコントロールプレーンと kube-proxy などのコアコンポーネントのみをアップグレードします。他のクラスターコンポーネントは、オフピーク時間に [アドオン] ページから手動でアップグレードする必要があります。バージョンの互換性要件については、「コンポーネントの概要とリリースノート」をご参照ください。

    アップグレードの考慮事項

    コントロールプレーン

    • ACK クラスターの Kubernetes バージョンは、サポートされているバージョンを順次アップグレードする必要があります。ロールバックはサポートされていません。複数のアップグレードを実行する場合は、各アップグレード後にクラスターのサービスが安定していることを確認してから、次のアップグレードを開始してください。

    • アップグレードする前に、「クラスターのアップグレード」で概要を確認してください。各バージョンのバージョンガイドとリリースノートを確認してください。後のバージョンでの機能変更による互換性の問題を避けるため、バージョンの詳細、非推奨 API、アップグレードの考慮事項を必ず理解してください。

    • コントロールプレーンのアップグレードは、実行中のアプリケーションに影響を与えません。アップグレード中に API Server はローリング方式で再起動されます。ご利用のアプリケーションが API Server に強く依存している場合は、接続をリトライできる必要があります。

    • Kubernetes 1.24 以降では、組み込みのコンテナランタイムとして Docker はサポートされていません。クラスターを 1.22 から 1.24 以降にアップグレードする場合、「ノードのコンテナランタイムを Docker から containerd に移行する」必要があります。

    • コントロールプレーンのアップグレード中は、クラスターに対する操作とメンテナンス (O&M) を避けてください。

    ノードプール

    • ノードの自動スケーリング

      • クラスターでノードの自動スケーリングが有効になっている場合、クラスターのアップグレード後に cluster-autoscaler コンポーネントは自動的に最新バージョンに更新されます。これにより、ノードの自動スケーリング機能が期待どおりに動作します。クラスターのアップグレード後、cluster-autoscaler コンポーネントが期待されるバージョンに更新されていることを確認してください。詳細については、「ノードの自動スケーリングを有効にする」をご参照ください。

      • クラスターのアップグレード中に、[高速] [スケーリングモード] のノードはシャットダウンされるため、アップグレードに失敗することがあります。アップグレードされなかった [高速スケーリングモード] のノードがある場合は、アップグレードの完了後に手動で削除してください。

    • クラスターをバージョン 1.18 にアップグレードした後、ACK はデフォルトでノードリソースの予約を設定します。クラスターにリソース予約が設定されておらず、ノードのリソース使用率が高い場合、Pod が退避された後に迅速にスケジュールされない可能性があります。これを防ぐために、ノードのリソースを予約してください。CPU 使用率は 50% 以下、メモリ使用率は 70% 以下にすることを推奨します。詳細については、「ノードリソース予約ポリシー」をご参照ください。

    • バージョン 1.24 以前のクラスターで、ワークロードの Pod に startup probe のみが設定されている場合、kubelet の再起動後に Pod が短時間 NotReady 状態になることがあります。ノードが再起動した場合に十分な Pod が利用可能であることを保証するため、マルチレプリカのデプロイメントポリシーを使用し、ワークロードを複数のノードに分散させることを推奨します。

    • Pod が LoadBalancer タイプの Service の SLB アドレスを介して同じノード上の別の Pod にアクセスし、Service の externalTrafficPolicy が Local に設定されている場合、ノードのローテーション後に 2 つの Pod が同じノード上に存在しなくなる可能性があります。これにより、ネットワーク接続の問題が発生する可能性があります。

    • ACK はカスタムオペレーティングシステムイメージを厳密に検証しないため、アップグレードが成功することを保証できません。

    • クラスターのアップグレードには、yum が必要なソフトウェアパッケージをダウンロードする必要があります。ノードのネットワーク設定を変更した場合や、カスタム OS イメージを使用している場合は、ノード上で yum が実行できることを確認してください。yum makecache コマンドを実行してこれを確認できます。

    • SWAP パーティションの有効化や、コマンドラインを使用した kubelet またはランタイム設定の変更など、クラスター設定を変更した場合、クラスターのアップグレードが失敗し、カスタム設定が上書きされる可能性があります。

    • システムディスクを交換してノードをアップグレードする場合、ACK はノードをドレインします。このプロセスは、Pod を他の利用可能なノードに退避させ、Pod Disruption Budget (PDB) に準拠します。高可用性を確保するため、マルチレプリカのデプロイメントポリシーを使用することを推奨します。ワークロードを複数のノードに分散させ、重要なサービスには PDB を設定して、同時に中断される可能性のある Pod の数を制御してください。

      ノードのドレインのデフォルトのタイムアウト期間は 30 分です。タイムアウト期間内に Pod の移行が完了しない場合、ACK はサービスの安定性を確保するためにアップグレードを停止します。

    • システムディスクを交換してノードをアップグレードする場合、ACK は現在のノードプールの設定に基づいてノードを再初期化します。これらの設定には、ログイン方法、ラベル、Taint、OS イメージ、ランタイムバージョンが含まれます。ノードプールの設定は、ノードプールを編集することによってのみ更新してください。他の方法でノード設定に加えられた変更は、アップグレード中に上書きされます。

    • ノード上の Pod がシステムディスクを指す HostPath を参照している場合、アップグレード中にシステムディスクが交換された後、HostPath ディレクトリ内のデータは失われます。

    • ノードプールのアップグレード中は、スケールアウト操作のみがサポートされます。スケールイン操作はサポートされていません。

    • ワーカーノードがどのノードプールにも管理されていない (未割り当てのノード) 場合は、まずそれをノードプールに移行する必要があります。詳細については、「未割り当てのノードをノードプールに移行する」をご参照ください。

    アップグレード方法

    インプレースアップグレードとシステムディスク置換

    コントロールプレーンのアップグレードについては、ACK マネージドクラスターおよびACK Serverless クラスターでは ACK がプロセスを管理します。ACK 専用クラスターは、インプレースアップグレードを使用してアップグレードされます。

    ノードプールのアップグレードには、ACK はインプレースアップグレードとシステムディスク置換アップグレードの 2 つの方法を提供します。

    • インプレースアップグレード：システムディスクの交換やノードの再初期化を行わずに、既存のノード上で直接アップグレードが実行されます。元のノードデータは影響を受けません。IP アドレスやディスクマウントなど、ECS インスタンス関連の設定は変更されません。ただし、containerd や kubelet など、ACK が管理するコンポーネントの設定は、コンポーネントのバージョン間の違いに基づいて調整される場合があります。

      containerd または kubelet の設定をカスタマイズするには、「ノードプールの kubelet 設定をカスタマイズする」および「ノードプールの containerd 設定をカスタマイズする」をご参照ください。

    • システムディスク置換アップグレード：この方法では、システムディスクを交換し、ノードを再初期化します。IP アドレスとデータディスクのマウントは変更されませんが、システムディスク上のすべてのデータは削除されます。続行する前に、ディスクスナップショットを有効にし、システムディスクをバックアップしてください。

      ノードにアタッチされているデータディスクは影響を受けません。

    特殊なケース

    以下のシナリオでは、システムディスク置換アップグレードが必要です：

    代替案：新しいノードプールによるローリングアップグレード

    既存のノードをアップグレードする代わりに、ターゲット設定で新しいノードプールを作成することでローリングアップグレードを実行できます。古いノードプールをスケジュール不可に設定するか、ワークロードのスケジューリングを更新することで、アプリケーションを段階的に移行します。移行が検証されたら、古いノードプールを削除します。

    両方のノードプールが共存している間は両方に課金されます。コストを管理するために、移行後速やかに古いプールを削除してください。

    よくある質問

    • クラスターを手動でアップグレードするにはどうすればよいですか？

      詳細については、「クラスターの手動アップグレード」をご参照ください。まず、事前チェックを完了します。その後、アップグレードを実行し、結果が期待どおりであることを確認します。

    • クラスターをアップグレードするためのベストプラクティスは何ですか？

      • 定期的なアップグレード頻度の維持：バージョンガイド、ヘルプドキュメント、公式通知を監視して、定期的なアップグレード頻度を維持してください。継続的なサポートとセキュリティを確保するために、速やかにアップグレードしてください。

      • アップグレード計画の作成：アップグレードには API の非推奨化などの大きな変更が含まれるため、クラスターのサイズとビジネスニーズに基づいて詳細なアップグレード計画を作成してください。オフピーク時間にメンテナンスウィンドウを確保し、本番環境に適用する前にテスト環境でアップグレードを検証してください。

      • 自動アップグレードの使用：クラスターの自動アップグレード機能を使用できます。ACK は事前にアップグレード計画を生成し、事前チェックをトリガーし、指定されたメンテナンスウィンドウ内でクラスターをアップグレードします。これにより、バージョン管理の運用保守 (O&M) ワークロードが削減されます。

        また、インテリジェントホスティングモードで ACK マネージドクラスターを作成することもできます。 クラスターバージョンは ACK によって自動的にアップグレードされます。

    • クラスターのスペックアップにはどのくらいの時間がかかりますか？

      • コントロールプレーン：ACK マネージドクラスターおよびACK Serverless クラスターの場合、アップグレードは ACK によって管理され、約 5 分かかります。ACK 専用クラスターの場合、マスターノードは順次アップグレードされ、ノードあたり約 8 分かかります。

      • ノードプール：所要時間はノードのバッチ設定によって異なります。インプレースアップグレードは、バッチあたり約 5～10 分かかります。スナップショットなしのシステムディスク置換アップグレードは、バッチあたり約 8 分かかりますが、実際の所要時間はノードのドレインプロセスに影響されます。スナップショットの作成を選択した場合、アップグレードプロセスはスナップショットが作成されるのを待ちます。スナップショットの作成に必要な時間は、データ量によって異なります。

    • 1つのバージョンを永続的に使用し、クラスターをアップグレードしないことは可能ですか？

      いいえ、できません。古いバージョンに存在する潜在的なセキュリティリスクは、ご利用のクラスターだけでなく、Alibaba Cloud 全体のセキュリティにも影響を与える可能性があります。ACK は、クラスターが長期間古い状態のままであることを許可せず、安全で安定したバージョンに移行するための強制アップグレードを実行します。

      クラスターバージョンを速やかにアップグレードすることを推奨します。詳細については、「クラスターの手動アップグレード」をご参照ください。これにより、最新の機能の恩恵を受け、ACK からより良いテクニカルサポートを受けることができます。アップグレードする前に、ターゲットバージョンのリリースノートを参照して、その機能の変更点と重要な注意事項を理解してください。クラスターの自動アップグレード機能を有効にして、クラスターが自動的かつ定期的にアップグレードされるようにしてください。

    • ACK はアップグレード時にマイナーバージョンをスキップすることをサポートしていますか？

      いいえ、サポートしていません。クラスターは一度に 1 つのマイナーバージョンずつアップグレードする必要があります。また、クラスターのコントロールプレーンをアップグレードする前に、クラスターノードのバージョンがコントロールプレーンのバージョンと同じであることを確認してください。

    • クラスターのバージョンが非常に古いです。どうすれば迅速にアップグレードできますか？

      以下のいずれかのソリューションを使用できます。

      • ソリューション 1：クラスターを一度に 1 つのマイナーバージョンずつアップグレードします。各アップグレード後、クラスター内のビジネスアプリケーションが期待どおりに動作することを確認してから、次のアップグレードに進んでください。詳細については、「クラスターの手動アップグレード」をご参照ください。

      • ソリューション 2：最新バージョンを実行するクラスターを作成し、アプリケーションを徐々に新しいクラスターに移行してから、古いクラスターを非公開にします。クラスターの作成と設定については、「ACK マネージドクラスターの作成」をご参照ください。

    • クラスターをバージョン 1.22 から 1.24 にアップグレードする際に、Docker から containerd に切り替えるにはどうすればよいですか？

      ACK はバージョン 1.24 以降、組み込みのコンテナランタイムとして Docker をサポートしなくなりました。ノードのコンテナランタイムを Docker から containerd に移行する必要があります。

      ノードプールのアップグレード機能を使用して元のノードプールでランタイムを切り替えるか、新しい containerd ノードプールを作成してワークロードを移行することができます。詳細については、「ノードのコンテナランタイムを Docker から containerd に移行する」をご参照ください。

    • ACK はクラスターのアップグレード中にどのように安定性を確保しますか？

      ACK クラスターは、コントロールプレーンとノードプールで構成されています。

      • コントロールプレーンのアップグレード：ACK は、非推奨 API、コンポーネントの互換性、機能設定の互換性、コントロールプレーンコンポーネントを検査するアップグレード前チェック機能を提供します。チェック結果は、クラスター内のアプリケーションの正常な動作に影響を与えません。チェックに失敗した場合、コンソールに修正提案が表示されます。詳細については、「クラスターの手動アップグレード」をご参照ください。

      • ノードプールのアップグレード：ノードプールのアップグレードには、kubelet と containerd のアップグレードが含まれます。ACK は、ノードのステータス、システムリソース、ディスクのステータス、ネットワーク環境を検査するアップグレード前チェック機能を提供します。チェック結果は、クラスター内のアプリケーションの正常な動作に影響を与えません。チェックに失敗した場合、コンソールに修正提案が表示されます。

        また、アップグレードポリシーを設定してアップグレードのペースを制御することもできます。たとえば、アップグレードするノードを指定したり、各バッチでアップグレードできるノードの最大数を設定したり、アップグレードの一時停止ポリシーを設定したりできます。ノードのシステムディスクに重要なビジネスデータが含まれている場合は、ノードプールのアップグレード前にノードのスナップショットを作成することもできます。詳細については、「ノードプールのアップグレード」をご参照ください。

    • クラスターをアップグレードする前に知っておくべきことは何ですか？

      クラスターのアップグレードはロールバックできません。検証後、まずテスト環境をアップグレードし、次に本番環境をアップグレードしてください。また、アップグレードプロセス中に検証のために特定のノードを先にアップグレードすることもできます。

      サポートされているコンポーネントのバージョン、機能、非推奨の機能は Kubernetes のバージョンによって異なります。詳細については、さまざまなバージョンのリリースノートをご参照ください。

      コントロールプレーンのアップグレードに関する注意点を確認してください。

      ノードプールのアップグレードに関する注意点を確認してください。

    • バージョンが期限切れのクラスターは、引き続き正常に使用できますか？

      はい。ただし、古いクラスターはセキュリティと安定性のリスクをもたらします。できるだけ早くメンテナンスされているバージョンにアップグレードしてください。

      ACK クラスターはマネージドアーキテクチャを使用しているため、これらのセキュリティリスクはご利用のクラスターに影響を与えるだけでなく、Alibaba Cloud 全体のセキュリティにも影響を与える可能性があります。そのため、ACK はクラスターが長期間古い状態のままであることを許可せず、安全で安定したバージョンへの強制アップグレードを実行します。詳細については、「古いバージョンの強制アップグレード」をご参照ください。

    • クラスターアップグレード後のバージョンロールバックはサポートされていますか？

      いいえ。アップグレード後のコントロールプレーン、kubelet、またはコンテナランタイムのバージョンのロールバックはサポートされていません。

      ノードプールのアップグレード中に、重要なサービスデータがノードのシステムディスクに保存されている場合は、アップグレード前にノードのスナップショットを作成して、ノードデータをバックアップおよび復元してください。

    • クラスターをスペックアップしてコンテナサービス ACK Pro マネージドクラスターに移行する場合、どちらの操作を先に実行する必要がありますか？

      アップグレードを開始する前に、クラスターの移行を完了してください。サービスが安定していることが確認されたら、バージョンの更新に進んでください。

    • 事前チェックで非推奨 API が報告された場合はどうすればよいですか？

      Kubernetes 1.20 以降では、ACK は非推奨 APIに関する通知を提供します。これらはアップグレードをブロックしませんが、新しいバージョンとのアプリケーションの互換性を確保するために、事前にこれらの問題を修正してください。

    • 事前チェックで「component version too low」という警告を解決するにはどうすればよいですか？

      ACK はコントロールプレーンと kube-proxy のような一部のコアコンポーネントのみをアップグレードします。コンソールの [アドオン] ページで更新が必要な他のコンポーネントを特定します。アップグレードが必要なコンポーネントを表示できます。続行する前に、コンポーネントの概要とリリースノートを確認して、バージョンの互換性を確認してください。サービスへの影響を最小限に抑えるため、これらのコンポーネントのアップグレードをオフピーク時間にスケジュールしてください。

    • 「the aliyun service is not running on the instance」というエラーでアップグレードが失敗した場合の解決方法を教えてください。

      このエラーは、クラウドアシスタントが利用できないためにアップグレードコマンドが失敗したことが原因で発生します。クラウドアシスタントを開始または再起動してから、クラスターのアップグレードを再試行してください。詳細については、「クラウドアシスタントエージェントの開始、停止、またはアンインストール」をご参照ください。

    • ノードで「PLEG not healthy」エラーが発生した場合の解決方法を教えてください。

      このエラーは、コンテナまたはコンテナランタイムが応答していないことを示します。ノードを再起動してから、アップグレードを再試行してください。

    • クラスターのアップグレード時に invalid object doesn't have additional properties エラーが発生した場合はどうすればよいですか？

      クラスターをアップグレードした後は、ローカルの kubectl バージョンもアップグレードする必要があります。速やかにアップグレードしないと、ローカルの kubectl のバージョンがクラスターの API Server バージョンと異なるため、invalid object doesn't have additional properties のようなエラーが発生する可能性があります。kubectl のインストールまたはアップグレード方法の詳細については、「kubectl のインストールと設定」をご参照ください。互換性の問題を避けるために、kubectl のバージョンをクラスター API サーバーのバージョンと同期させることが重要です。