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

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

概要

メンテナンスの時間枠と除外を使用すると、クラスタで自動メンテナンスをいつ実行できるかをきめ細かく管理できます。

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

メンテナンスの除外は、自動メンテナンスの実行が禁止される定期的な時間枠です。

メンテナンスの時間枠とメンテナンスの除外は個別に構成できます。メンテナンスの除外は複数の構成が可能です。

自動メンテナンスの例

Google は、必要な場合に、またはクラスタ内でノードやネットワークを再作成する次のような構成変更を行った場合に、メンテナンス タスクを実施します。

ゾーンクラスタは、コントロール プレーン構成の変更とクラスタのメンテナンス中は変更できません。これには、ワークロードのデプロイも含まれます。

上に示した他のタイプの変更はいずれも、ワークロードがアップグレードされたノードに移行される間、一時的な中断が発生する原因となる可能性があります。

注意点

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

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

GKE クラスタとワークロードは、Compute Engine などの依存サービスの自動メンテナンスによっても影響を受ける可能性があります。GKE のメンテナンスの時間枠と除外によって、他の Google サービス、すなわちアプリケーションをクラスタにインストールするサービス（Cloud Deploy など）による自動メンテナンスを回避することはできません。

自動修復とサイズ変更

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

ノードにも自動修復機能がありますが、これは無効にできます。

ノードの再作成とメンテナンスの時間枠

コントロール プレーンとノード間のネットワークに影響するような機能やオプションを有効化または変更すると、ノードが再作成されて新しい構成が適用されます。ノードの再作成を行う機能の例は次のとおりです。

メンテナンスの時間枠または除外を使用していて、ノードの再作成が必要な機能やオプション（クラスタ認証情報のローテーションなど）の有効化または変更を行うと、ノードのメンテナンスが許可されている場合のみ新しい構成が適用されます。待機しないようにするには、gcloud container clusters upgrade コマンドを呼び出し、すでにノードプールが動作している GKE バージョンを指定した --cluster-version フラグを渡すことで、ノードに変更を手動で適用できます。この対処法には、Google Cloud CLI を使用する必要があります。

メンテナンスの時間枠

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

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

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

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

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

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

制限事項

メンテナンスの時間枠には次の制限があります。

クラスタごとに 1 つのメンテナンスの時間枠

メンテナンスの時間枠は、クラスタごとに 1 つだけ構成できます。新しいメンテナンスの時間枠を構成すると、以前のメンテナンスの時間枠が上書きされます。

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

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

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

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

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

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

クラスタの情報を表示するとき、情報の表示方法に応じて、メンテナンスの時間枠のタイムスタンプは 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 つのマイナー アップグレードがスケジュール設定されます（クラスタ コントロール プレーンとノードの両方がアップグレードされます）。クラスタをこれより早くデフォルト バージョンに戻す場合は、手動アップグレードを実行します。

制限事項

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

  • メンテナンスの除外では、リリース チャンネルに登録されているクラスタに対してのみ、自動アップグレードのスコープを制限できます。リリース チャンネルに登録されていない Standard クラスタでは、デフォルトの「アップグレードなし」スコープでのみメンテナンスの除外を作成できます。
  • すべてのアップグレードを除外する（つまり「アップグレードなし」のスコープ）メンテナンスの除外は、最大 3 件追加できます。これらの除外は、32 日間のローリング ウィンドウの中で、少なくとも 48 時間はメンテナンスが可能な状態になるように構成される必要があります。
  • クラスタごとに、メンテナンスの除外は最大 20 件設定できます。
  • 除外で範囲を指定しない場合、範囲はデフォルトで「アップグレードなし」になります。
  • メンテナンスの除外期間には、指定された除外スコープに基づいて制限があります。
    • アップグレードなし: 30 日以下にする必要があります。
    • マイナー アップグレードなし: 除外の作成日から 180 日を超える終了日は設定できません。
    • マイナー アップグレードやノード アップグレードなし: 除外の作成日から 180 日を超える終了日は設定できません。
  • マイナー バージョンのサポート終了日を含むか、それを超えるようなメンテナンスの除外を構成することはできません。たとえば、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 か月間停止します。企業がデータベースのダウンタイムを受け入れる準備ができたら、手動ノード アップグレードをトリガーします。

次のステップ