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

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

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

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

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

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

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

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

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

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

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

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 フラグを渡します。

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

一部の手動変更では、メンテナンス ポリシーを尊重せずに、ノードのアップグレード戦略を使用してノードがすぐに再作成されます。詳細については、メンテナンス ポリシーを尊重せずにノードのアップグレード戦略を使用してノードを再作成する手動変更をご覧ください。

メンテナンスの時間枠

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

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

メンテナンスの除外

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

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

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

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

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

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

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

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

次の表に、これらのスコープによりクラスタ コントロール プレーンやノードのマイナー アップグレードまたはパッチ アップグレードを制限する方法を示します。

GKE がクラスタをアップグレードすると、コントロール プレーンとノードの VM が再起動します。コントロール プレーンの場合、Autopilot クラスタとリージョン Standard クラスタは Kubernetes API サーバーの可用性を維持します。コントロール プレーン ノードが 1 つしかないゾーンクラスタでは、VM の再起動により、コントロール プレーンが一時的に使用できなくなります。ノードの場合は、VM の再起動により Pod のスケジュール変更がトリガーされ、既存のワークロードが一時的に中断する可能性があります。Pod Disruption Budget（PDB）を使用して、ワークロードの中断に対する許容範囲を設定できます。

スコープ コントロール プレーン ノード
自動マイナー アップグレード 自動パッチ アップグレード 自動マイナー アップグレード 自動パッチ アップグレード
アップグレードなし（デフォルト） 許可しない 許可しない 許可しない 許可しない
マイナー アップグレードなし 許可しない 許可 許可しない 許可
マイナー アップグレードまたはノード アップグレードなし 許可しない 許可 許可しない 許可しない

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

複数の除外

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

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

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

  • マイナー アップグレードなし: 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 の更新を阻止します。

クラスタのアップグレードを阻止する除外事項やその他の要因が残っていない場合、GKE は、対象となる自動アップグレード ターゲットにクラスタを段階的にアップグレードします。

除外によりクラスタで複数のマイナー バージョンのアップグレードがスキップされた場合、GKE はクラスタがサポートされているバージョンを実行できるように、クラスタ コントロール プレーンとノードの両方をアップグレードするマイナー バージョンのアップグレードを 1 か月に 1 回スケジュールします。手動アップグレードを実行して、クラスタを特定のマイナー バージョンに早急にアップグレードできます。

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

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

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

使用例

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

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

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

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

メンテナンスの除外の期限が切れた際に、他の除外時間枠の適用がない場合で、9 月 30 日から 1 月 6 日までの間にアップグレードが使用可能になった場合、クラスタは新しい 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 か月間停止します。企業がデータベースのダウンタイムを受け入れる準備ができたら、手動ノード アップグレードをトリガーします。

次のステップ