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

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

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

概要

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

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

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

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

自動メンテナンスの例

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

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

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

注意点

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

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

GKE クラスタとワークロードは、Compute Engine などの依存サービスの自動メンテナンスによっても影響を受ける可能性があります。GKE のメンテナンスの時間枠と除外によって、他の Google サービス、またはアプリケーションをクラスタにインストールするサービス（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 で表示されます。

メンテナンスの除外

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次のステップ