Container Service for Kubernetes:ノードプールの更新

注記

• ノードスケーリング

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

  • クラスター更新中に、スケーリングモード が スウィフト に設定されているノードはシャットダウンされるため、更新に失敗する可能性があります。スウィフト モードのノードがクラスター更新完了後も更新されていない場合は、手動でそのノードを削除することを推奨します。

• Kubernetes 1.18 にクラスターを更新した後、ACK はデフォルトでノードリソース予約を構成します。リソース予約が構成されておらず、ノードのリソース使用量が高い場合、Pod がエビクトされた後に再スケジュールが迅速に行われない可能性があります。そのため、ノードにリソースを予約することを推奨します。最適なパフォーマンスを得るには、CPU 使用率を 50 % 以下、メモリ使用率を 70 % 以下に抑えてください。詳細については、「ノードリソース予約ポリシー」をご参照ください。

• Kubernetes 1.24 以前を実行しているクラスターでは、ワークロード内の Pod がスタートアッププローブのみで構成されている場合、kubelet 再起動後に短時間 NotReady 状態になる可能性があります。そのため、ワークロードを複数ノードに分散させるマルチレプリカデプロイメント戦略を使用することを推奨します。これにより、ノード再起動中も十分な Pod が利用可能になります。

• ある Pod が、LoadBalancer サービスによって公開された SLB インスタンスの IP アドレスを使用して同一ノード上の別の Pod にアクセスしており、かつそのサービスの externalTrafficPolicy が Local に設定されている場合、ノード置き換え後に両方の Pod が同一ノード上に存在しなくなる可能性があります。これにより、ネットワークが中断されることがあります。

• カスタムオペレーティングシステム (OS) イメージは ACK によって厳密に検証されません。カスタム OS イメージを使用するクラスターについて、ACK は更新の成功を保証できません。

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

• SWAP パーティションを有効にするなど、クラスターに対してカスタム構成変更を加えている場合、またはコマンドラインから kubelet やコンテナランタイムの構成を変更している場合、更新プロセスが失敗するか、カスタム構成が上書きされる可能性があります。

• システムディスクを置き換えてノードを更新する際、ACK はノードドレインを実行します。Pod は、構成済みの PodDisruptionBudget (PDB) に従って、他の利用可能なノードにエビクトされます。サービス可用性を確保するため、ワークロードを複数ノードに分散させるマルチレプリカデプロイメント戦略を使用することを推奨します。また、重要なサービスに対して PDB を構成し、同時に中断できる Pod の数を制御してください。

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

• システムディスクを置き換えてノードを更新する際、ACK はノードプールの現在の構成（ノードログイン方法、ラベル、Taint、OS イメージ、コンテナランタイムバージョンなど）に基づいてノードを再初期化します。通常、ノードプールの構成はノードプールの編集によって更新します。他の方法でノードを変更している場合、これらの変更は更新時に上書きされます。

• ノード上の Pod がシステムディスクを指す HostPath ボリュームを使用している場合、システムディスク置き換えによる更新後にそのディレクトリ内のデータは失われます。

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

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

• ACK クラスターを更新する際、Lingjun ノードプールは更新できません。

• バージョン 1.31 以前のクラスターでノードプールをアップグレードする際、NVIDIA Device Plugin も同時にアップグレードされ、標準外の構成がリセットされます。

機能

ノードプールの更新には、kubelet およびコンテナランタイムの更新が含まれます。

• kubelet 更新：ノードプール内のノード上の kubelet をコントロールプレーンと同じバージョンにアップグレードします。デフォルトでは、ACK はインプレース更新を実行します。

• コンテナランタイム更新：新しいコンテナランタイムバージョンがリリースされた場合、ノード上のコンテナランタイムを最新バージョンにアップグレードできます。

  • コンテナランタイムを Docker から containerd に移行する際、ノードプール内のノードはシステムディスクの交換によって更新されます。これにより、システムディスクのすべての内容が消去されます。更新を開始する前に、システムディスクから重要なデータをすべてバックアップしてください。詳細については、「ノードのコンテナランタイムを Docker から containerd に移行する」をご参照ください。

  • ContainerOS ノードを除き、containerd のあるバージョンから新しいバージョンへのアップグレード時は、デフォルトでインプレース更新が実行されます。ノード上の /etc/containerd/config.toml ファイルは、ACK が提供する新しいバージョンに置き換えられます。

    重要

    • ContainerOS ノードは containerd のインプレース更新をサポートしていません。システムディスクを置き換える方法でのみ更新できます。アップグレード手順については、「3.4 より前の ContainerOS バージョンを最新バージョンにアップグレードする」をご参照ください。

    • コンテナランタイム更新中、Pod プローバーやライフサイクルフックが失敗する可能性があります。また、Pod がその場で再起動する場合もあります。

  • Kubernetes 1.24 以前を実行しているクラスターで Docker を新しいバージョンに更新する際、ACK はデフォルトでシステムディスクを置き換えることでノードプール内のノードを更新します。これにより、システムディスクのすべての内容が消去されます。更新を開始する前に、システムディスクから重要なデータをバックアップしてください。

操作手順

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

2. クラスターリスト ページで、ご利用のクラスター名をクリックします。左側のナビゲーションウィンドウで、ノード > ノードプール をクリックします。

3. ［ノードプール］ページで、更新するノードプールを見つけ、アクション列で > Kubelet の更新を選択します。次の表の説明に従って、パラメーターを設定します。

   パラメーター		説明
   Kubelet のアップグレード情報		現在の kubelet バージョンを表示し、ターゲットバージョンを選択します。
   ランタイムのアップグレード情報		現在のランタイムバージョンを表示し、ターゲットランタイムバージョンを選択します。 ノードコンテナランタイムを Docker から containerd に移行する際、ノードプール内のノードはシステムディスクを置き換えることで更新されます。このプロセスにより、システムディスク上のすべての内容が消去されます。 クラスターが Kubernetes 1.22 を実行しており、インストールされている containerd バージョンが 1.6.34（比較的新しいバージョン）の場合、更新はサポートされません。
   ノードのアップグレード		更新するノードを指定します：すべてのノードまたは特定のノード。
   更新方法		更新方法を選択します。インプレースアップグレード および 交換用ディスクのアップグレード がサポートされています。更新ロジックおよびプロセスの詳細については、「参考情報：インプレース更新とシステムディスク置き換えによる更新」をご参照ください。 インプレースアップグレード：既存ノード上で必要なコンポーネントを更新します。この方法ではシステムディスクは置き換えられず、ノードも再初期化されないため、ノード上のデータに影響はありません。 交換用ディスクのアップグレード：システムディスクを置き換えることでノードを再初期化します。ノードのインスタンスプロパティ（名前、ID、IP アドレスなど）は変更されませんが、システムディスク上のすべてのデータは消去されます。別途マウントされたデータディスク上のデータは影響を受けません。
   警告レベルのチェック項目を無視		事前チェックで警告が報告された場合に、更新を続行するかどうかを指定します。警告レベルの項目の例として、ノードプール内の Pod がシステムディスクを指す hostPath を使用している場合があります。
   一括更新ポリシー	バッチごとに実行されるノードの最大数	ACK は、指定した同時更新可能なノード数の最大値に基づいて、ノードをバッチで更新します。更新プロセスの詳細については、「参考情報：インプレース更新とシステムディスク置き換えによる更新」をご参照ください。
   	自動一時停止ポリシー	ノード更新プロセスの一時停止ポリシーです。
   	バッチごとの時間間隔	自動一時停止ポリシーを「設定しない」にした場合、更新バッチ間の時間間隔を指定できます。有効値は 5～120 分です。
   	自動スナップショット	ノードのシステムディスクに重要な業務データが含まれている場合、ノードプール更新前にノードのスナップショットを作成して、ノードデータをバックアップおよび復元できます。スナップショット作成には料金が発生します。詳細については、「スナップショットの料金」をご参照ください。作成進捗はリアルタイムで更新されます。更新後にスナップショットが不要になった場合は、速やかに削除してください。 説明 更新方法として「システムディスク置き換えによるアップグレード」を選択した場合は、自動スナップショットを有効にすることを推奨します。スナップショット作成には料金が発生します。詳細については、「スナップショットの料金」をご参照ください。

4. 構成が完了したら、事前チェック をクリックします。事前チェックが通過したら、画面の指示に従って更新を開始します。

   説明

   事前チェックが失敗した場合や警告が返された場合は、「チェック項目失敗時の対処方法」をご参照いただくか、プロンプトに従って 事前チェックレポート を確認し、問題をトラブルシューティングしてください。

   更新中は、プロンプトに従って次の操作を実行できます。

   • 一時停止：クラスター更新の一時停止は中間状態です。この間はクラスターに対して他の操作を行わず、できるだけ早く更新プロセスを完了することを推奨します。更新が 7 日以上一時停止された場合、ACK は自動的にプロセスを終了し、関連するすべてのイベントおよびログをクリアします。

     更新を一時停止した後、すでに更新済みのノードの kubelet およびコンテナランタイムバージョンをロールバックすることはできません。

   • キャンセル：更新をキャンセルします。キャンセル をクリックした後、すでに更新済みのノードの kubelet およびコンテナランタイムバージョンをロールバックすることはできません。

   更新後は、ノード ページに移動し、ノード名をクリックしてから 基本情報 タブをクリックして、kubelet およびコンテナランタイムバージョンが正しいことを確認できます。

インプレース更新とシステムディスク置き換え

よくある質問

関連トピック

• 運用管理負荷を軽減するために、自動クラスター更新を有効にすることもできます。詳細については、「クラスターを自動的にアップグレードする」をご参照ください。

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

• ACK マネージドノードプールは、OS の共通脆弱性識別子 (CVE) に対する自動パッチ適用を提供します。詳細については、「自動 CVE パッチ適用（推奨）」をご参照ください。

• Kubernetes 1.24 以降では、Docker がビルトインコンテナランタイムとしてサポートされなくなりました。ノードコンテナランタイムを Docker から containerd に移行する必要があります。詳細については、「ノードコンテナランタイムを Docker から containerd に移行する」をご参照ください。

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

• OS イメージを最新バージョンに速やかに更新することを推奨します。詳細については、「オペレーティングシステムの変更」をご参照ください。