メンテナンスの時間枠と除外

Autopilot Standard

このページでは、メンテナンスの時間枠とメンテナンスの除外について説明します。これは、Google Kubernetes Engine（GKE）クラスタで、自動アップグレードなどのクラスタメンテナンスを行える時間帯と行えない時間帯を管理するポリシーです。たとえば、小売業ではメンテナンスの時間を平日の夜のみに限定し、主要な営業時間に自動メンテナンスが実行されないようにできます。

GKE メンテナンスポリシーについて

GKE メンテナンスポリシー（メンテナンスの時間枠と除外を含む）を使用すると、クラスタアップグレードやノードの構成、クラスタのネットワークトポロジの変更など、クラスタで特定の自動メンテナンスを実行するタイミングを管理できます。

メンテナンスの時間枠は、GKE の自動メンテナンスの実行が可能な、繰り返し出現する時間枠です。

メンテナンスの除外は、GKE の自動メンテナンスの実行が禁止される、繰り返しのない時間枠です。

メンテナンスの時間枠が開始され、有効なメンテナンスの除外がない場合は、クラスタのメンテナンスポリシーに従った自動的な変更が行われます。各クラスタには、1 つの定期メンテナンスの時間枠と複数のメンテナンスの除外を構成できます。

他の種類のメンテナンス（コントロールプレーンの修復オペレーションや、GKE が依存するサービス（Compute Engine など）のメンテナンスなど）は、GKE メンテナンスポリシーには依存しません。詳細については、メンテナンスポリシーが適用されない自動メンテナンスをご覧ください。

GKE メンテナンスポリシーが適用される変更と適用されない変更

GKE メンテナンスポリシー（メンテナンスの時間枠と除外）を構成する前に、以下のセクションでは、GKE と関連サービスのポリシーの適用と非適用の詳細を確認します。

GKE メンテナンスポリシーが適用される自動メンテナンス

GKE メンテナンスポリシーを使用すると、クラスタに一時的な中断を引き起こす次の種類のイベントのタイミングを制御できます。

クラスタの自動アップグレード（コントロールプレーンのアップグレードとノードのアップグレードを含む）。これらの変更の詳細と、それによって環境が一時的に中断する可能性があることについては、Autopilot クラスタのアップグレードとStandard クラスタのアップグレードをご覧ください。
ノードの再作成やクラスタの内部ネットワークトポロジの大幅な変更を引き起こす、ユーザー主導の構成変更。詳細については、GKE メンテナンスポリシーが適用される手動での変更をご覧ください。

他のタイプの自動メンテナンスは、メンテナンスポリシーに依存しません。詳細については、メンテナンスポリシーが適用されない自動メンテナンスをご覧ください。

GKE メンテナンスポリシーが適用されない自動メンテナンス

GKE のメンテナンスの時間枠と除外は、すべてのタイプの自動メンテナンスをブロックするものではありません。GKE クラスタのメンテナンスポリシーを構成する前に、メンテナンスの時間枠と除外が適用されない変更の種類を確認してください。

Google Cloud のその他のメンテナンス

基盤となる Google Cloud サービス（主に Compute Engine）やアプリケーションをクラスタにインストールするサービス（Cloud Deploy など）の自動メンテナンスを、GKE のメンテナンスの時間枠と除外によって回避することはできません。

たとえば、GKE ノードは、GKE がクラスタのために管理する Compute Engine VM です。Compute Engine VM では、メンテナンスイベントやホストエラーなどのホストイベントが発生することがあります。これらのイベント中に VM がどのように動作するかは、VM のホストメンテナンスポリシーによって決まります。デフォルトでほとんどの VM では、ライブマイグレーションが行われます。通常、これはノードにダウンタイムがほとんどないか、まったくないことを意味し、ほとんどのワークロードでは、そのデフォルトのポリシーで十分です。一部の VM マシンファミリーでは、ホストメンテナンスイベントのモニタリングと計画や、ホストメンテナンスイベントのトリガーを GKE メンテナンスポリシーに合わせて行えます。

GPU や TPU を搭載した VM など、一部の VM では、ライブマイグレーションを実行できません。こうしたアクセラレータを使用している場合は、GPU または TPU のノードメンテナンスによる中断に対処する方法を確認してください。

ホストイベントとホストメンテナンスポリシーに関する情報を確認し、特に、ライブマイグレーションを実行できないノードでワークロードが実行されている場合は、ワークロードが中断に備えていることを確認してください。

自動修復とサイズ変更

GKE は、コントロールプレーンの自動修復を行います。自動修復には、コントロールプレーンを適切なサイズにアップスケールすることや、コントロールプレーンを再起動して問題を解決することなどのプロセスが含まれます。修復に失敗するとクラスタが機能しなくなる可能性があるため、ほとんどの修復ではメンテナンスの時間枠と除外が無視されます。

コントロールプレーンの修復は、無効にできません。ただし、Autopilot クラスタや Standard リージョンクラスタなど、ほとんどのタイプのクラスタには、コントロールプレーンの複数のレプリカがあり、メンテナンスイベント中でも Kubernetes API サーバーの高可用性を実現できます。コントロールプレーンが 1 つしかない Standard ゾーンクラスタでは、コントロールプレーンの構成変更中やクラスタのメンテナンス中に変更することはできません。これには、ワークロードのデプロイも含まれます。

ノードには自動修復機能もあり、Standard クラスタでは無効にできます。

重大なセキュリティ脆弱性のパッチ適用

メンテナンスの時間枠と除外を使用すると、セキュリティパッチが遅延する可能性があります。しかし、GKE は、重大なセキュリティの脆弱性に対してメンテナンスポリシーをオーバーライドする権限を有します。

GKE メンテナンスポリシーが適用される手動での変更

ノードやネットワーク構成を変更すると、新しい構成を適用するためにノードの再作成が必要になる場合があります。これには、次のような変更が該当します。

これらの変更には、GKE メンテナンスポリシーが適用されます。つまり、GKE では、メンテナンスの時間枠の開始を待ち、ノードメンテナンスを禁止する有効なメンテナンスの除外がなくなるまで待ちます。変更をノードに手動で適用するには、Google Cloud CLI を使用して gcloud container clusters upgrade コマンドを呼び出します。その際、ノードプールで動作している GKE バージョンを指定した --cluster-version フラグを渡します。

メンテナンスの時間枠

メンテナンスの時間枠を使用すると、コントロールプレーンとノードの自動アップグレード実行のタイミングの管理が可能になり、ワークロードの一時的な中断を軽減できます。メンテナンスの時間枠は、次のような場合に役立ちます。

オフピーク時: 自動アップグレードをトラフィックが減少するオフピーク時にスケジュールすることにより、ダウンタイムの可能性を最小限に抑えたい。
オンコール: アップグレードをモニタリングして予期せぬ問題を管理できるように、アップグレードを勤務時間中に実行したい。
複数クラスタのアップグレード: 異なるリージョンの複数のクラスタに、指定した間隔で一度に 1 つずつアップグレードをロールアウトしたい。

自動アップグレードに加えて、Google は他のメンテナンスタスクを行うこともあります。その場合は、可能な限りクラスタのメンテナンスの時間枠を尊重します。

タスクがメンテナンスの時間枠を超えて実施されると、GKE はタスクを一時停止し、次のメンテナンスの時間枠で再開しようとします。

GKE は、メンテナンスの時間枠の外で、予定外の緊急アップグレードをロールアウトする権限を有します。また、メンテナンスの時間枠の外で、非推奨のソフトウェアや古いソフトウェアからの必須のアップグレードが自動的に行われることがあります。

新規または既存のクラスタに対してメンテナンスの時間枠を設定する方法については、メンテナンスの時間枠の構成をご覧ください。

メンテナンスの時間枠のタイムゾーン

メンテナンスの時間枠を構成および表示する場合、使用しているツールによって表示される時間が異なります。

メンテナンスの時間枠を構成する場合

時間は常に UTC で保存されます。しかし、メンテナンスの時間枠を構成する場合は、UTC またはローカルタイムゾーンのいずれかを使用します。

より一般的な --maintenance-window フラグを使用してメンテナンスの時間枠を構成する場合は、タイムゾーンを指定できません。gcloud CLI や API を使用する場合は UTC が使用され、Google Cloud コンソールにはローカルタイムゾーンで時刻が表示されます。

--maintenance-window-start など、より詳細なフラグを使用する場合は、値の一部としてタイムゾーンを指定できます。タイムゾーンを省略すると、ローカルタイムゾーンが使用されます。

メンテナンスの時間枠を表示する場合

クラスタの情報を表示するとき、情報の表示方法に応じて、メンテナンスの時間枠のタイムスタンプは UTC またはローカルタイムゾーンで表示されます。

Google Cloud コンソールを使用してクラスタの情報を表示する場合、時刻は常にローカルタイムゾーンで表示されます。
gcloud CLI を使用してクラスタの情報を表示する場合、時刻は常に UTC で表示されます。

どちらの場合も、RRULE は常に UTC です。たとえば、曜日を指定すると、日付は UTC で表示されます。

メンテナンスの除外

メンテナンスの除外を指定すると、特定の期間の自動メンテナンスを回避できます。たとえば、多くの小売業には、年末年始のインフラストラクチャの変更を禁止するビジネスガイドラインがあります。別の例として、非推奨が予定されている API を企業が使用している場合、メンテナンスの除外を使用してマイナーアップグレードを一時停止することで、アプリケーションを移行する時間を確保できます。

影響が大きいイベントであることが既知の場合は、内部変更の制限を、イベントの 1 週間前からイベント期間中継続されるメンテナンスの除外と一致させることをおすすめします。

除外構成に繰り返しはありません。代わりに、定期的な除外の各インスタンスを個別に作成します。

除外設定とメンテナンスの時間枠が重複する場合は、除外設定が優先されます。

新規または既存のクラスタにメンテナンスの除外を設定する方法については、メンテナンスの除外の構成をご覧ください。

除外するメンテナンスのスコープ

クラスタの自動メンテナンスを行わないようにするタイミングを指定するだけでなく、実施される自動更新のスコープを制限することもできます。メンテナンスの除外スコープは、特に次のような場合に有効です。

アップグレードなし - メンテナンスを回避: 特定の期間中、クラスタへの変更を一時的に回避する場合。これはデフォルトのスコープです。
マイナーアップグレードなし - 現在の Kubernetes のマイナーバージョンを維持: API の変更や次のマイナーバージョン検証を回避するために、クラスタのマイナーバージョンを一時的に維持する場合。
マイナーアップグレードやノードのアップグレードなし - ノードプールの中断を回避: ノードのアップグレードによるワークロードのエビクションやスケジュール変更を一時的に回避する場合。

次の表に、メンテナンスの除外で制限できる自動更新のスコープを示します。この表では、発生したアップグレードの種類（マイナー、パッチ）も示します。アップグレードが行われると、コントロールプレーンとノードプールの VM が再起動します。コントロールプレーンの場合は、VM の再起動により Kubernetes API サーバーの可用性が一時的に低下する可能性があります。これは、特に単一のコントロールプレーンを使用するゾーンクラスタトポロジで顕著です。ノードの場合は、VM の再起動により Pod のスケジュール変更がトリガーされ、既存のワークロードが一時的に中断する可能性があります。Pod Disruption Budget（PDB）を使用して、ワークロードの中断に対する許容範囲を設定できます。

スコープ	コントロールプレーン			ノードプール
スコープ	マイナーアップグレード	パッチのアップグレード	GKE のメンテナンスによる VM の中断	マイナーアップグレード	パッチのアップグレード	GKE のメンテナンスによる VM の中断
アップグレードなし（デフォルト）	×	×	×	×	×	×
マイナーアップグレードなし	×	○	はい	×	○	○
マイナーアップグレードまたはノードアップグレードなし	×	○	はい	いいえ	×	×

マイナーバージョンとパッチバージョンの定義については、バージョニングスキームをご覧ください。

複数の除外

クラスタには複数の除外を設定できます。これらの除外は、スコープが異なり、時間範囲が重複している可能性があります。年末商戦のユースケースは、「アップグレードなし」と「マイナーアップグレードなし」の両方のスコープが使用されている重複除外の例です。

除外が重複している場合は、有効な除外（つまり、現在の期間が除外期間内）によりアップグレードが妨げられると、アップグレードが延期されます。

年末商戦のユースケースを使用すると、クラスタには次の除外が指定されています。

マイナーアップグレードなし: 9 月 30 日～1 月 15 日
アップグレードなし: 11 月 19 日～12 月 4 日
アップグレードなし: 12 月 15 日～1 月 5 日

これらの除外が重複するため、クラスタでは次のアップグレードがブロックされます。

11 月 25 日のノードプールに対するパッチアップグレード（「アップグレードなし」の除外による拒否）
12 月 20 日のコントロールプレーンに対するマイナーアップグレード（「マイナーアップグレードなし」と「アップグレードなし」の除外による拒否）
12 月 25 日のコントロールプレーンに対するパッチアップグレード（「アップグレードなし」の除外による拒否）
1 月 1 日のノードプールに対するマイナーアップグレード（「マイナーアップグレードなし」と「アップグレードなし」の除外による拒否）

クラスタでの次のメンテナンスは許可されます。

11 月 10 日のコントロールプレーンに対するパッチアップグレード（「マイナーアップグレードなし」の除外による許可）
12 月 10 日の GKE メンテナンスによる VM の中断（「マイナーアップグレードなし」の除外による許可）

除外の有効期限

除外の有効期限を経過した（つまり、現在の時刻が除外に対して指定された終了時刻よりも後の時点である）場合は、その除外によって GKE の更新が阻止されることはなくなります。有効な（有効期限を経過していない）他の除外は、引き続き GKE の更新を阻止します。

クラスタのアップグレードを阻止する除外事項が残っていない場合、クラスタはリリースチャンネルの現在のデフォルトバージョン（またはリリースチャンネルに存在しないクラスタの静的デフォルト）に徐々にアップグレードされます。

除外の有効期間の経過後にクラスタの現在のデフォルトバージョンより前のマイナーバージョンが複数ある場合は、クラスタがリリースチャンネルのデフォルトバージョンに達するまで、1 か月に 1 つのマイナーアップグレードがスケジュール設定されます（クラスタコントロールプレーンとノードの両方がアップグレードされます）。クラスタをこれより早くデフォルトバージョンに戻す場合は、手動アップグレードを実行します。

メンテナンスの除外の構成に関する制限事項

メンテナンスの除外には、次の制限があります。

メンテナンスの除外では、リリースチャンネルに登録されているクラスタに対してのみ、自動アップグレードのスコープを制限できます。リリースチャンネルに登録されていないクラスタでは、デフォルトの「アップグレードなし」のスコープでのみメンテナンスの除外を作成できます。
すべてのアップグレードを除外する（つまり「アップグレードなし」のスコープ）メンテナンスの除外は、最大 3 件追加できます。これらの除外は、32 日間のローリングウィンドウの中で、少なくとも 48 時間はメンテナンスが可能な状態になるように構成される必要があります。
クラスタごとに、メンテナンスの除外は最大 20 件設定できます。
除外でスコープを指定しない場合、スコープはデフォルトで「アップグレードなし」になります。
メンテナンスの除外は、スコープに応じて異なる長さに設定できます。詳細については、メンテナンスの除外を構成するのメンテナンスの除外の長さの行をご覧ください。
マイナーバージョンのサポート終了日を含むものや、それを超えるようなメンテナンスの除外は構成できません。たとえば、GKE のリリーススケジュールにサポート終了日が 2023 年 6 月 5 日と記載されているマイナーバージョンを実行しているクラスタでは、メンテナンスの除外の終了時刻を 2023-06-05T00:00:00Z 以前に設定する必要があります。

使用例

実施される可能性がある更新の範囲を制限するユースケースの例を次に示します。

例: 年末商戦に向けて準備する小売業者

この例では、小売業者は、販売量が最も多い期間（ブラックフライデー～サイバーマンデーを含む 4 日間、新しい年が始まる前の 12 月）の事業の中断は回避したいと考えています。ショッピングシーズンに備えて、クラスタ管理者は次の除外を設定します。

マイナーアップグレードなし: 9 月 30 日～1 月 15 日の期間について、コントロールプレーンとノードでのパッチ更新のみを許可します。
アップグレードなし: 11 月 19 日～12 月 4 日の期間について、すべてのアップグレードを停止します。
アップグレードなし: 12 月 15 日～1 月 5 日の期間について、すべてのアップグレードを停止します。

9 月 30 日から 1 月 6 日の間に新しい GKE マイナーバージョンへのアップグレードが可能になっている場合、メンテナンスの除外が終了したときに他の除外時間枠が適用されていなければ、クラスタはその GKE マイナーバージョンにアップグレードされます。

例: 削除が進んでいる Kubernetes でベータ版 API を使用している企業

この例では、企業は CustomResourceDefinition apiextensions.k8s.io/v1beta1 API を使用しており、この API はバージョン 1.22 で削除される予定です。企業が 1.22 より前のバージョンを実行している場合、クラスタ管理者は次の除外を設定します。

マイナーアップグレードなし: お客様のアプリケーションを apiextensions.k8s.io/v1beta1 から apiextensions.k8s.io/v1 に移行しながら、マイナーアップグレードを 3 か月間フリーズします。

例: 企業の以前のデータベースにノードプールのアップグレードに対する耐障害性がない

この例では、企業がデータベースのアップグレード中に行われる Pod のエビクションとスケジュール変更に正しく反応しないデータベースを実行しています。クラスタ管理者が次の除外を設定します。

マイナーアップグレードまたはノードアップグレードなし: ノードのアップグレードを 3 か月間停止します。企業がデータベースのダウンタイムを受け入れる準備ができたら、手動ノードアップグレードをトリガーします。