Container Service for Kubernetes:ノードプールのアップグレード

注意事項

• クラスターで Auto Scaling 機能が有効になっている場合、自動スケーリング機能への影響を防ぐため、アップグレードが正常に完了した後、クラスターは自動的に Cluster Autoscaler を最新バージョンに更新します。クラスターのアップグレード後に、Cluster Autoscaler のバージョンが正常であることを確認してください。詳細については、「ノードの自動スケーリングの有効化」をご参照ください。

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

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

• Pod が LoadBalancer 型の Service の SLB アドレスを介して同一ノード上の別の Pod にアクセスし、その Service の externalTrafficPolicy が Local に設定されている場合、ノードのローテーション後に両方の Pod が同一ノード上に存在しなくなる可能性があり、ネットワークが利用不可になります。

• カスタム OS イメージは ACK により厳密に検証されません。ACK はアップグレードの成功を完全に保証できません。

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

• SWAP パーティションの有効化、kubelet 構成またはランタイム構成の黒画面操作による変更など、クラスターに対して構成変更を行った場合、クラスターのアップグレードが失敗する可能性や、カスタム構成が上書きされる可能性があります。

• ディスク交換アップグレードによるノードのアップグレードでは、ACK は Pod Disruption Budget (PDB) の要件に従い、ノードのドレイン操作を実行し、Pod を他の利用可能なノードへエビクションします。サービスの高可用性を確保するため、ワークロードを複数のノードに分散させるマルチレプリカデプロイメント戦略を採用し、重要なサービスに対しては PDB を設定して、同時に中断される Pod の数を制御することを推奨します。

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

• ディスク交換アップグレードによるノードのアップグレードでは、ACK はノードプールの現在の構成（ノードログイン方法、ラベル、Taint、OS イメージ、ランタイムバージョンなど）に基づいてノードを再初期化します。通常、ノードプール構成を更新するには、「ノードプールの作成と管理」を使用する必要があります。他の方法でノードに変更を加えた場合、これらの変更はアップグレード中に上書きされます。

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

• ノードプールのアップグレード中は、拡張操作のみがサポートされ、スケーリング操作はサポートされません。

• ノードがデタッチされたノード（つまり、ノードプールによって管理されていない Worker ノード）である場合、「フリーノードをノードプールに追加」を参照して、移行を完了してください。

• ACK クラスターのバージョンアップグレード中は、Lingjun ノードプールのアップグレードは一時的にサポートされていません。

操作手順

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

3. [ノードプール] リストで、対象のノードプールの [操作] 列から ＞ [Kubelet のアップグレード] を選択し、以下の内容に従って構成を完了します。

   構成項目		説明
   kubelet アップグレード情報		現在の kubelet バージョンを確認し、アップグレード先のバージョンを選択します。
   ランタイムアップグレード情報		現在のランタイムバージョンを確認し、アップグレード先のランタイムバージョンを選択します。 Docker から containerd へのアップグレードでは、ノードプールのノードはディスク交換およびリセット（ノードのシステムディスクの交換）によりアップグレードされます。アップグレードプロセスでは、システムディスク上のすべてのコンテンツがクリアされます。詳細については、「コンテナーランタイムを Docker から containerd へ移行」をご参照ください。 クラスターのバージョンが 1.22 であり、インストール済みの containerd バージョンが 1.6.34（比較的新しい）の場合、アップグレードは一時的にサポートされていません。
   ノードのアップグレード		アップグレード対象のノード（全ノードまたは一部のノード）を指定します。
   アップグレード方法		アップグレード方法を選択してください。インプレースアップグレード および ディスク交換アップグレード の両方がサポートされています。「リファレンス：インプレースアップグレードとディスク交換アップグレード」を参照して、アップグレードのロジックおよびプロセスについてご確認ください。 インプレースアップグレード：チェック後に、必要なコンポーネントが元のノード上で直接更新・置き換えられます。インプレースアップグレードではシステムディスクは交換されず、ノードも再初期化されません。元のノードのデータには影響ありません。 ディスク交換アップグレード：チェック後に、ノードのシステムディスクを交換することでノードが再初期化されます。ノードのインスタンス属性（ノード名、インスタンス ID、IP アドレスなど）は変更されませんが、ノードのシステムディスク上のデータは削除されます。ノードに追加マウントされたデータディスクには影響ありません。
   警告レベルのチェック項目を無視		ノードプールレベルの警告レベルのチェック項目を無視してアップグレードを続行するかどうかを指定します。警告レベルのチェック項目の一例として、ノードプール内の Pod がシステムディスクを指す HostPath を使用していることが挙げられます。
   バッチアップグレード戦略	バッチあたりの最大ノード数	アップグレードプロセスでは、設定された最大並列数に従ってノードをバッチ単位でアップグレードします。アップグレードプロセスの詳細については、下記の「リファレンス：インプレースアップグレードとディスク交換アップグレード」をご参照ください。
   	自動一時停止戦略	ノードアップグレードプロセス中の一時停止戦略です。
   	バッチ間の間隔時間	自動一時停止戦略で一時停止しない場合、各アップグレードバッチ間に間隔時間を設けるかどうか、またはその間隔時間の長さを選択できます。選択可能な範囲は 5～120 分です。
   	自動スナップショット	ノードのシステムディスクに重要なビジネスデータがある場合、ノードプールのアップグレード前にノードの スナップショット を作成して、ノードデータのバックアップおよび復元を行うことができます。スナップショットの作成には課金が発生します（「スナップショットの課金」をご参照ください）。作成進捗状況 は動的に変化します。アップグレード後にスナップショットが不要になった場合は、速やかに 削除 してください。 説明 アップグレード方法としてディスク交換アップグレードを選択する場合は、自動スナップショットを有効化することを推奨します。スナップショットの作成にはリソース料金が発生します。課金の詳細については、「スナップショットの課金」をご参照ください。

4. 構成が完了したら、事前チェック をクリックし、事前チェックが通過した後にページの指示に従ってアップグレード操作を開始します。

   説明

   事前チェックの実行に失敗した場合や警告項目がある場合は、「チェック項目失敗時の解決策」を参照するか、ページの指示に従って チェックレポート を確認し、トラブルシューティングおよび是正処置を行ってください。

   アップグレード中は、ページの指示に従って以下の操作を実行できます。

   • 一時停止：クラスターの一時停止状態は、ノードプールアップグレードの途中状態です。この期間中はクラスターに対する操作を避けて、できるだけ早くアップグレードプロセスを完了することを推奨します。途中状態のクラスターは、7 日後にアップグレードプロセスを終了し、すべてのアップグレード関連イベントおよびログ情報をクリーンアップします。

     一時停止後、アップグレードが完了したノードの kubelet およびコンテナーランタイムは、バージョンロールバックをサポートしません。

   • キャンセル：アップグレードをキャンセルします。キャンセル をクリックすると、アップグレードが完了したノードの kubelet およびコンテナーランタイムは、バージョンロールバックをサポートしません。

   アップグレード後は、ノード ページでノード名をクリックし、基本情報 タブで、ノードの kubelet バージョン、コンテナーランタイムバージョンなどの情報が期待通りであるかを確認できます。

リファレンス：インプレースアップグレードとディスク交換アップグレード

よくある質問

関連ドキュメント

• クラスターの自動アップグレード機能を有効化することで、バージョンの運用保守負荷を軽減できます。「クラスターの自動アップグレード」をご参照ください。

• containerd の変更履歴については、「containerd ランタイムのリリースノート」をご参照ください。

• ACK のマネージドノードプールでは、オペレーティングシステムの CVE 脆弱性を自動修復する機能が提供されています。「OS の CVE 脆弱性を自動パッチ適用（推奨）」をご参照ください。

• Kubernetes 1.24 では、Docker を組み込みコンテナーランタイムとして使用できなくなります。ノードのコンテナーランタイムを Docker から containerd へ移行してください。「コンテナーランタイムを Docker から containerd へ移行」をご参照ください。

  Docker および containerd のコマンドラインツールは異なります。一般的なコマンドの比較については、「Docker Engine および containerd が提供する一般的なコマンドの比較」をご参照ください。

• オペレーティングシステムのイメージバージョンを適宜更新することを推奨します。「オペレーティングシステムの変更」をご参照ください。