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


このページでは、Google Kubernetes Engine(GKE)Autopilot クラスタでの自動アップグレードの仕組みについて説明します。関連するタスクや設定の詳細情報へのリンクも含まれています。この情報を使用すると、ワークロードの中断を最小限に抑えながら、クラスタの安定性とセキュリティを最新の状態に保つことができます。

クラスタとノードプールのアップグレードの仕組み

このセクションでは、自動アップグレード中にクラスタ内で行われる処理について説明します。Google は、自動アップグレードを開始して、すべての GKE クラスタ全体で自動アップグレードをモニタリングし、問題が発生していた場合は介入します。

クラスタは、そのノードの前にアップグレードされます。

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

このセクションでは、Google がお客様のクラスタを自動アップグレードしたときの動作について説明します。Autopilot モードで作成されたクラスタは、リージョン クラスタです。リージョン クラスタにはコントロール プレーンの複数のレプリカがあり、未定義の順序で一度に 1 つずつレプリカがアップグレードされます。アップグレード中は、クラスタが高可用性を維持します。各コントロール プレーン レプリカは、そのアップグレード中にのみ使用不可になります。

メンテナンスの時間枠または除外を構成した場合には、それが可能な限り尊重されます。

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

Autopilot クラスタとそのノードプールは、同じバージョンの GKE を実行します。このセクションでは、Google がお客様のノードプールを自動アップグレードしたときの動作について説明します。

ノードプールは一度に 1 つずつアップグレードされます。ノードプール内では、未定義の順序でノードが一度に 1 つずつアップグレードされます。

このプロセスには、ノード数とそのワークロード構成に応じて数時間かかることがあります。ノードのアップグレード速度を低下させる可能性がある構成は次のとおりです。

メンテナンスの時間枠または除外を構成した場合には、それが可能な限り尊重されます。

ノードがアップグレードされると、次の動作が発生します。

  1. サージ アップグレードはデフォルトで有効になっているため、GKE はアップグレードされたバージョンで新しいサージノードを作成し、そのノードがコントロール プレーンに登録されるまで待機します。
  2. GKE は、既存のノード(ターゲット ノード)を選択してアップグレードします。GKE によりターゲット ノードが遮断され、空にされます。この時点では、GKE はターゲット ノードで新しい Pod をスケジュールできません。
  3. ターゲット ノード上の Pod は、他のノードに再スケジュールされます。Pod が再スケジュールできない場合、再スケジュールできるようになるまでその Pod は PENDING になります。
  4. ターゲット ノードが削除されます。
  5. GKE フリート全体で、特定のバージョンへのノードの自動アップグレードで異常なノードが大量に発生した場合は、問題を調査する間、そのバージョンへのアップグレードが中止されます。

自動アップグレード

Autopilot クラスタを作成すると、デフォルトでクラスタとそのノードプールの自動アップグレードが有効になります。新しい GKE バージョンが自動アップグレード用として選択されている場合は、Google がお客様のクラスタをアップグレードします。

自動アップグレードを発生させる(または発生させない)タイミングを制御するには、メンテナンスの時間枠と除外を構成します。

Autopilot クラスタはリリース チャンネルに自動的に登録されるため、クラスタのコントロール プレーンのアップグレードが完了して特定のノードプールのアップグレードが開始されるまでの短期間を除き、常にクラスタ自体と同じバージョンの GKE がノードで実行されます。

バージョンが自動アップグレードで選択される仕組み

新しい GKE バージョンは定期的にリリースされますが、その直後に自動アップグレード用としてバージョンが選択されるわけではありません。ある GKE バージョンが安定性を証明するのに十分なクラスタ使用量を達成したら、Google はそのバージョンを、旧バージョンのサブセットを実行するクラスタ向けの自動アップグレード ターゲットとして選択します。

新しい自動アップグレード ターゲットはリリースノートで発表されます。クラスタ自動アップグレード対象のバージョンとノード自動アップグレード対象のバージョンが別々の週に選択される場合があります。

通常は、新しいマイナー バージョンが一般公開されるとすぐに、使用可能な最も古いマイナー バージョンがサポートされなくなります。サポートされないマイナー バージョンを実行しているクラスタは、その次のマイナー バージョンに自動的にアップグレードされます。

1 つのマイナー バージョン(v1.14.x など)の中で、クラスタが新しいパッチリリースに自動アップグレードされることがあります。

自動アップグレードの発生のタイミングを構成する

デフォルトでは、自動アップグレードはいつでも発生する可能性があります。特にリージョン クラスタでは、自動アップグレードが問題になることはほとんどありません。ただし、一部のワークロードでは細かい制御が必要になる場合があります。メンテナンスの時間枠と除外を構成すると、自動アップグレードを発生させる(または発生させない)タイミングを管理できます。

サージ アップグレード

サージ アップグレードを使用すると、GKE が一度にアップグレードできるノード数と、更新がワークロードに与える影響の度合い制御できるようになります。Autopilot クラスタは、サージ アップグレードを使用するように自動的に構成されており、オーバーライドできません。

サージアップ グレードの動作は、次の 2 つの設定によって決まります。

max-surge-upgrade
アップグレード中にノードプールに追加可能なノードの数。デフォルトは 1 です。
max-unavailable-upgrade

アップグレード中に同時に使用不可になるノードの数。デフォルトは 0 です。

同時にアップグレードされるノードの数は、max-surge-upgrademax-unavailable-upgrade の合計です。

デフォルトのサージ アップグレードは maxSurge=1 maxUnavailable=0. に設定されています。アップグレード中にノードプールにサージノードが 1 つしか追加できないため、一度にアップグレードされるノードは 1 つだけです。

割り当てとの関係

ノードの再作成に Compute Engine リソースの追加は不要ですが、ノードのサージ アップグレードでは必要です。リソース割り当ては Compute Engine の割り当ての対象になります。構成によっては、この割り当てによって同時アップグレード数が制限されることや、アップグレードが失敗することがあります。

割り当ての詳細については、ノードのアップグレードと割り当てをご覧ください。

アップグレードの通知を受信する

GKE は Pub/Sub にアップグレードの通知を公開し、クラスタに関する情報を GKE から受け取るためのチャネルをユーザーに提供します。

詳細については、クラスタのアップグレード通知の受信をご覧ください。

次のステップ