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

注意事項

• 事前チェック

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

  • ACK はカスタム OS イメージを厳密に検証しないため、アップグレードの成功を保証できません。

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

  • クラスターをバージョン 1.18 にアップグレードした後、ACK はデフォルトでノードリソース予約ポリシーを設定します。リソース予約が設定されておらず、ノードのリソース使用量が高い場合、エビクション後に Pod がすぐにスケジュールされない可能性があります。ノードのリソースを予約し、CPU 使用率を 50 % 以下、メモリ使用率を 70 % 以下に維持してください。

  • バージョン 1.24 以前のクラスターで、ワークロードの Pod に Startup Probe のみが設定されている場合、kubelet 再起動後に Pod が一時的に NotReady 状態になります。ノード間で複数のレプリカを持つワークロードをデプロイすることで、ノード再起動時にも十分な Pod が利用可能になります。

  • ディスク領域の 20 % 以上を空けてください。これにより、アップグレード中にディスク容量不足による Pod のエビクションを防げます。

• ノードプールアップグレードの制約

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

  • ノードプールに属さないマネージド外のワーカーノードがある場合は、移行してください。詳細については、「マネージド外ノードをノードプールに移行する」をご参照ください。

  • ACK クラスターのアップグレード中は、Lingjun ノードプールのアップグレードはサポートされていません。

  • ディスク置き換えによるノードアップグレードを行うと、ACK は現在のノードプール構成に基づいてノードを再初期化します。これにはログイン方法、ラベル、Taint、OS イメージ、ランタイムバージョンが含まれます。ノードプール構成を更新するには、「ノードプールの編集」をご参照ください。その他の方法でノードを変更した場合、アップグレードによって変更内容が上書きされます。

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

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

• ノードスケーリングとスケジューリング

  • クラスターでノードスケーリング機能が有効になっている場合、アップグレード成功後にcluster-autoscalerが最新バージョンに自動更新され、自動スケーリング機能への影響を回避します。クラスターのアップグレード後は、cluster-autoscalerのバージョンが正しいことを確認してください。詳細については、「ノードの自動スケーリングを有効化する」をご参照ください。

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

• ネットワークとサービス可用性

  • Pod が同一ノード上の別の Pod にアクセスするためにLoadBalancer サービスの SLB アドレスを使用しており、かつそのサービスのexternalTrafficPolicyがLocalに設定されている場合、ノードローテーション後に両方の Pod が同一ノード上に存在しなくなる可能性があります。これにより、ネットワーク接続が失敗する可能性があります。

  • ディスク置き換えによるノードアップグレードを行うと、ACK はノードのドレインを実行します。このプロセスでは、Pod Disruption Budget (PDB) を尊重しながら、Pod を他のアクティブなノードにエビクトします。高可用性を確保するには、ノード間で複数のレプリカを持つワークロードをデプロイしてください。また、重要なサービスに対して PDB を設定し、同時に中断可能な Pod 数を制御します。

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

機能

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

• Kubelet アップグレード：各ノードプールノード上の kubelet がコントロールプレーンのバージョンに合わせてアップグレードされます。デフォルトの方法：インプレースアップグレード。

• コンテナランタイムのアップグレード：新しいバージョンが利用可能な場合、ノード上のコンテナランタイムをアップグレードします。

  • Docker から containerd への移行は、ノードプールノードのシステムディスクを置き換えるため、システムディスク上のすべてのデータが消去されます。アップグレード前に重要なデータをバックアップしてください。「ノードのコンテナランタイムを Docker から containerd に移行する」をご参照ください。

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

    重要

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

    • コンテナランタイムのアップグレード中、Pod プローブおよびライフサイクルフックが失敗し、Pod がその場で再起動する可能性があります。

  • Kubernetes 1.24 以前のクラスターで Docker をアップグレードする場合、デフォルトでノードプールノードのシステムディスクが置き換えられ、システムディスク上のすべてのデータが消去されます。アップグレード前に重要なデータをバックアップしてください。

操作手順

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

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

3. ［ノードプール］ページで、対象のノードプールを見つけ、［アクション］列の アイコンをクリックし、［Kubelet の更新］を選択します。次のパラメーターを設定します。

   パラメーター		説明
   Kubelet のアップグレード情報		現在の kubelet バージョンを確認し、対象バージョンを選択します。
   ランタイムのアップグレード情報		現在のコンテナランタイムバージョンを確認し、対象バージョンを選択します。 Docker から containerd への移行は、ノードプールノードのシステムディスクを置き換えるため、システムディスク上のすべてのコンテンツが消去されます。「ノードのコンテナランタイムを Docker から containerd に移行する」をご参照ください。 containerd 1.6.34 を使用するバージョン 1.22 のクラスターは、ランタイムのアップグレードをサポートしていません。
   ノードのアップグレード		アップグレードするノードを選択します：すべてまたは特定のノード。
   アップグレード方法		インプレースアップグレードまたは交換用ディスクのアップグレードを選択します。「リファレンス：インプレースアップグレードとシステムディスク置き換えによるアップグレード」をご参照ください。 インプレースアップグレード：ACK は既存ノード上で直接コンポーネントを更新します。インプレースアップグレードではシステムディスクが置き換えられず、ノードも再初期化されないため、データは影響を受けません。 交換用ディスクのアップグレード：ACK はシステムディスクを置き換えることでノードを再初期化します。インスタンスの名前、ID、IP アドレスなどの属性は変更されませんが、システムディスクのデータは削除されます。接続されたデータディスクは影響を受けません。
   警告レベルのチェック項目を無視		事前チェックで警告が報告された場合に続行するかどうかを指定します。たとえば、Pod がシステムディスクを指すhostPathを使用している場合などです。
   一括更新ポリシー	バッチごとに実行されるノードの最大数	この最大値までノードをバッチでアップグレードします。「リファレンス：インプレースアップグレードとシステムディスク置き換えによるアップグレード」をご参照ください。
   	自動一時停止ポリシー	アップグレードプロセスの一時停止ポリシーです。
   	バッチごとの時間間隔	自動一時停止が設定されていない場合のバッチ間の間隔です。有効値：5～120 分。
   	自動スナップショット	ノードのシステムディスクに重要なデータが含まれている場合は、ノードプールのアップグレード前にスナップショットを作成してください。スナップショットには料金が発生します（「スナップショットの課金」をご参照ください）。また、作成進捗は動的に変化します。アップグレード後は、不要なスナップショットを削除してください。 説明 システムディスク置き換えによるアップグレードを選択する場合は、自動スナップショット作成を有効にしてください。スナップショットにはコストが発生します。「スナップショットの課金」をご参照ください。

4. 事前チェックをクリックします。事前チェックが成功したら、画面の指示に従ってアップグレードを開始します。

   説明

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

   アップグレード中は、以下の操作が可能です。

   • 一時停止：ノードプールを中間状態にします。他のクラスター操作を避け、速やかにアップグレードを完了してください。7 日以上一時停止されたアップグレードは自動的に終了し、関連イベントおよびログはクリアされます。

     すでにアップグレードされたノードの kubelet またはコンテナランタイムのバージョンをロールバックすることはできません。

   • キャンセル：アップグレードをキャンセルします。キャンセルをクリックした後は、すでにアップグレードされたノードの kubelet またはコンテナランタイムのバージョンをロールバックすることはできません。

   検証するには、ノードページに移動し、ノード名をクリックして、基本情報タブで kubelet およびコンテナランタイムのバージョンを確認します。

インプレースアップグレードと置き換えアップグレード

よくある質問

echo 2 > /proc/sys/vm/drop_caches

参照

• メンテナンスのオーバーヘッドを軽減するために、自動クラスターアップグレードを有効にしてください。

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

• ACK マネージドノードプールは、自動 OS CVE パッチ適用をサポートしています。

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

  Docker と containerd では異なるコマンドラインツールを使用します。「Docker と containerd の一般的なコマンド比較」をご参照ください。

• OS イメージを最新の状態に保ってください。「オペレーティングシステムの変更」をご参照ください。