メンテナンスの時間枠と除外を構成する

Autopilot Standard

---

メンテナンスの時間枠とメンテナンスの除外を使用することで、Google Kubernetes Engine（GKE）クラスタで自動アップグレードなどのクラスタの自動メンテナンスを実行するタイミング（実行の可否を含む）を制御できます。こうしたメンテナンス ポリシーを構成する前に、GKE メンテナンス ポリシーが適用される変更と適用されない変更を確認してください。

始める前に

始める前に、次の作業が完了していることを確認してください。

• Google Kubernetes Engine API を有効にする。
Google Kubernetes Engine API の有効化
• このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、gcloud components update を実行して最新のバージョンを取得する。
  注: gcloud CLI がすでにインストールされている場合には、必ず compute/region と compute/zone のプロパティを設定してください。デフォルトのロケーションを設定することで、gcloud CLI のエラー（One of [--zone, --region] must be supplied: Please specify location など）を防ぐことができます。

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

メンテナンスの時間枠を構成するには、メンテナンスの開始時間、期間、繰り返しの回数を指定します。たとえば、月曜日から金曜日まで毎日 4 時間、毎週繰り返すメンテナンスの時間枠を構成できます。

メンテナンスの時間枠の構成には、Google Cloud コンソールまたは Google Cloud CLI を使用できます。

メンテナンスの時間枠を構成する際の考慮事項

メンテナンスの時間枠を構成する際は、次のガイダンスに従ってください。

• GKE のメンテナンスの時間枠が適用されるメンテナンス イベントのタイプと、適用されないタイプを把握します。詳細については、GKE のメンテナンス ポリシーが適用される自動メンテナンスとGKE のメンテナンス ポリシーが適用されない自動メンテナンスをご覧ください。
• クラスタに構成できるメンテナンスの時間枠は 1 つだけです。新しい時間枠を構成すると、以前の時間枠が上書きされます。
• 32 日間のローリング ウィンドウ内で少なくとも 48 時間はメンテナンスが可能な状態にする必要があります。メンテナンスに 4 時間以上連続する時間を用意してください。
• Google Cloud コンソールを使用する場合、時刻は常にローカル タイムゾーンで表示されます。
• 曜日の繰り返しは、常に UTC に基づきます。このため、こうした繰り返しを伴うメンテナンスの時間枠は gcloud CLI を使用して、すべて UTC で設定することをおすすめします。フラグを設定する際は現地時間を使用できますが、そのタイムゾーンは保存されません。たとえば、タイムゾーンが UTC+6 で、メンテナンスの時間枠を水曜日の 02:00 から開始する場合、UTC での値には火曜日の 20:00 を指定します。詳細については、メンテナンスの時間枠のタイムゾーンをご覧ください。

• 予定されたメンテナンスの時間枠内にクラスタがノードのアップグレードを完了できない場合は、アップグレードの頻度が低下する可能性があります。お使いの環境に対する速度と中断の最適なバランスを見つけるために、構成のテストが必要になることがあります。アップグレードの頻度に影響を与える可能性がある要因は次のとおりです。

  • メンテナンスの可用性の低さ（たとえば、短いメンテナンスの時間枠）。
  • 大規模な Standard ノードプール。
  • 速度よりも中断の最小化を優先するノード アップグレード戦略の構成。
  • 一部の Pod 構成の選択。詳細については、ノードのアップグレード期間に関する考慮事項をご覧ください。

シンプルなメンテナンスの時間枠を設定した Standard クラスタの作成

シンプルなメンテナンスの時間枠は、gcloud CLI で --maintenance-window フラグを指定することによって作成できます。このフラグを使用すると、毎日 4 時間のメンテナンスの時間枠を簡単な形式で指定できます。メンテナンスの時間枠を設定した Autopilot クラスタを作成するには、Google Cloud コンソールを使用します。

シンプルなメンテナンスの時間枠を設定した新しい Standard クラスタの作成

gcloud container clusters create CLUSTER_NAME \
    --maintenance-window START_TIME

次のように置き換えます。

• CLUSTER_NAME: 新しいクラスタの名前。
• START_TIME: UTC 時間での 24 時間形式のタイムスタンプ（例: 16:00）。

メンテナンスの時間枠は、START_TIME で指定された時刻から毎日 4 時間実行されます。

カスタムのメンテナンスの時間枠を作成する

このセクションで説明する追加のパラメータを使用して、週または月の特定の時間帯に実施されるメンテナンスの時間枠を作成できます。

たとえば、次のコマンドを実行すると、2026 年 8 月 19 日水曜日の午前 2 時（UTC）に始まるメンテナンスの時間枠が設定された my-cluster というクラスタが作成されます。このメンテナンスの時間枠は毎週月曜日と金曜日に始まり、30 時間後に終了します。最初のメンテナンスの時間枠は、8 月 21 日（金）午前 2 時に始まり、8 月 22 日（土）午前 8 時に終了します。詳しくは、日付と時刻の形式をご覧ください。

gcloud container clusters create my-cluster \
    --maintenance-window-start 2026-08-19T02:00:00Z \
    --maintenance-window-end 2026-08-20T08:00:00Z \
    --maintenance-window-recurrence 'FREQ=WEEKLY:BYDAY=MO,FR'

その他のシナリオについては、メンテナンスの時間枠の例をご覧ください。

メンテナンスの時間枠を設定したクラスタの作成

メンテナンスの時間枠を設定した新しい Standard クラスタを作成するには、gcloud CLI または Google Cloud コンソールを使用します。メンテナンスの時間枠を設定した新しい Autopilot クラスタを作成するには、Google Cloud コンソールを使用します。

gcloud

メンテナンスの時間枠を設定した新しい Standard クラスタの作成

gcloud container clusters create CLUSTER_NAME \
    --maintenance-window-start START_TIME \
    --maintenance-window-end END_TIME \
    --maintenance-window-recurrence RRULE

次のように置き換えます。

• CLUSTER_NAME: 新しいクラスタの名前。
• START_TIME: 定期的なメンテナンスの時間枠が有効になっている日時。RFC-5545 の DTSTART 値で表されます。この時間が経過すると、RRULE に従ってメンテナンスの時間枠が繰り返されます。START_TIME には、メンテナンスの時間枠を開始する時刻も指定します。
• END_TIME: メンテナンスの時間枠の期間を計算するための終了時間。START_TIME より後の時間を同じ形式で指定します。END_TIME の値は、START_TIME より後の日時でなければなりません。
• RRULE: RFC-5545 RRULE で表されるメンテナンスの時間枠の繰り返し。これは柔軟な形式で、複数の方法で繰り返しルールを指定し、メンテナンスの時間枠の開始日を指定できます。たとえば、1 週間や 1 か月などの繰り返しを指定できます。END_TIME の日付が START_TIME の日付より後の日付の場合、メンテナンスの時間枠は複数の日にまたがります。たとえば、日曜日に始まるメンテナンスの時間枠は、月曜日まで継続します。

コンソール

1. Google Cloud コンソールで Google Kubernetes Engine のページに移動します。

   Google Kubernetes Engine に移動

2. [ 作成] をクリックします。

3. クラスタを構成します。

4. ナビゲーション パネルで、[クラスタ] の下の [自動化] をクリックします。

5. [メンテナンスの時間枠を有効化] チェックボックスをオンにします。

6. 開始時間と期間を選択し、メンテナンスの時間枠が発生する曜日を選択します。繰り返しルールの仕様（RRule）を直接編集するには、[カスタム エディタ] を選択します。

7. [作成] をクリックします。

既存のクラスタのメンテナンスの時間枠の構成

gcloud

既存のクラスタのメンテナンスの時間枠を作成または更新します。

gcloud container clusters update CLUSTER_NAME \
    --maintenance-window-start START_TIME \
    --maintenance-window-end END_TIME \
    --maintenance-window-recurrence RRULE

次のように置き換えます。

• CLUSTER_NAME: 新しいクラスタの名前。
• START_TIME: 定期的なメンテナンスの時間枠が有効になっている日時。RFC-5545 の DTSTART 値で表されます。この時間が経過すると、RRULE に従ってメンテナンスの時間枠が繰り返されます。START_TIME には、メンテナンスの時間枠を開始する時刻も指定します。
• END_TIME: メンテナンスの時間枠の期間を計算するための終了時間。START_TIME より後の時間を同じ形式で指定します。END_TIME の値は、START_TIME より後の日時でなければなりません。
• RRULE: RFC-5545 RRULE で表されるメンテナンスの時間枠の繰り返し。これは柔軟な形式で、複数の方法で繰り返しルールを指定し、メンテナンスの時間枠の開始日を指定できます。たとえば、1 週間や 1 か月などの繰り返しを指定できます。END_TIME の日付が START_TIME の日付より後の日付の場合、メンテナンスの時間枠は複数の日にまたがります。たとえば、日曜日に始まるメンテナンスの時間枠は、月曜日まで継続します。

コンソール

既存のクラスタのメンテナンスの時間枠を作成または変更するには:

1. Google Cloud コンソールで Google Kubernetes Engine のページに移動します。

   Google Kubernetes Engine に移動

2. クラスタのリストで、変更するクラスタの名前をクリックします。

3. [自動化] で、[メンテナンスの時間枠] フィールドの横にある [メンテナンス ポリシーを編集] をクリックします。

4. [メンテナンスの時間枠を有効化] チェックボックスをオンにします。

5. 開始時間と期間を選択し、メンテナンスの時間枠が発生する曜日を選択します。RRule を直接編集するには、[カスタム エディタ] を選択します。

6. [Save Changes] をクリックします。

未完了のメンテナンスを手動で終了する

アップグレードなどの自動メンテナンスがメンテナンスの時間枠よりも長くかかる場合、GKE は実行中のメンテナンス タスクを終了し、次のメンテナンスの時間枠の中でメンテナンス タスクを再開しようとします。自動アップグレードがキャンセルされ、ノードの自動アップグレードが有効になっている場合、ノードのバージョンが混在する可能性がありますが、クラスタは正常に動作します。

クラスタを手動でアップグレードするか、部分的なアップグレードをキャンセルまたはロールバックする場合は、クラスタの手動アップグレードをご覧ください。

メンテナンスの時間枠を削除する

gcloud

クラスタからメンテナンスの時間枠を削除します。

gcloud container clusters update CLUSTER_NAME --clear-maintenance-window

CLUSTER_NAME を、既存のクラスタの名前に置き換えます。

Console

メンテナンスの時間枠を削除するには:

1. Google Cloud コンソールで Google Kubernetes Engine のページに移動します。

   Google Kubernetes Engine に移動

2. クラスタのリストで、変更するクラスタの名前をクリックします。

3. [自動化] で、[メンテナンスの時間枠] フィールドの横にある [メンテナンス ポリシーを編集] をクリックします。

4. [メンテナンスの時間枠を有効化] チェックボックスをオフにします。

5. [変更を保存] をクリックします。

メンテナンスの時間枠の例

次の例では、メンテナンスの時間枠を構成する方法をいくつか説明します。コマンドのフラグは、クラスタの新規作成や更新と同じ構文を使用するので、ここでは関連するフラグのみを示します。

週末（2026 年 8 月 22 日より）

この例では、start と end のタイムスタンプの差が 丸 2 日であるため、メンテナンスの時間枠は週末全体（土曜日と日曜日）にわたって実行されます。時間枠を 48 時間とは異なる長さにする場合、時間枠の開始時間を変えるには -start を、時間枠の合計時間を変えるには -end を変更します。

--maintenance-window-start 2026-08-22T00:00:00Z \
--maintenance-window-end 2026-08-24T00:00:00Z \
--maintenance-window-recurrence 'FREQ=WEEKLY;BYDAY=SA'

平日の午前 9 時から午後 5 時（UTC-4）

この例では、週末を除く、月曜日から金曜日までにメンテナンスの時間枠を設定しています。この例では、UTC 以外のタイムゾーンを指定しています。

--maintenance-window-start 2026-09-02T09:00:00-04:00 \
--maintenance-window-end 2026-09-02T17:00:00-04:00 \
--maintenance-window-recurrence 'FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR'

毎週午後 4 時から 8 時間（UTC-7）

--maintenance-window-start にタイムゾーンを指定しない場合、Google Cloud アカウントで構成されている現地時間が使用されます。Google Cloud コンソールは常に現地時間を使用しています。

--maintenance-window-start 2026-08-13T16:00:00-7:00 \
--maintenance-window-end 2026-08-14T00:00:00-7:00 \
--maintenance-window-recurrence 'FREQ=WEEKLY'

平日の夜間

この例では、UTC-7 タイムゾーンの平日の夜間に実施される毎日のメンテナンスの時間枠を示しています。この例では、時間枠は 20:00 から翌朝の 4:00 まで続きます。

 --maintenance-window-start 2026-08-15T20:00:00-7:00 \
 --maintenance-window-end 2026-08-16T04:00:00-7:00 \
 --maintenance-window-recurrence 'FREQ=WEEKLY;BYDAY=MO,TU,WE,TH'

メンテナンスの除外を構成する

クラスタのメンテナンスの除外を設定するには、以下を指定する必要があります。

• 名前: 除外の名前（省略可）。
• 開始時間: 除外期間の開始日時。
• 終了時間: 除外期間の終了日時。それぞれに使用可能な範囲の除外期間に対する制限については、次の表をご覧ください。
• 範囲: 制限する自動アップグレードの範囲。次の表に、使用可能な除外スコープの一覧を示します。

範囲	説明	除外の最大期間
アップグレードなし（デフォルト）	すべてのパッチとマイナー アップグレードが除外されます。アップグレードによってクラスタのコントロール プレーンとノードで VM の中断が発生しないようにします。	30 日を超えることはできません。
マイナー アップグレードなし	マイナー アップグレードがすべて除外されます。パッチのアップグレードによってクラスタのコントロール プレーンとノードで VM の中断が発生する可能性があります。	終了日に、除外の作成日から 180 日を超える日付は設定できません。Rapid、Regular、Stable の各チャンネルに登録されているクラスタについては、標準サポートの終了日を超えて延長することはできません。Extended チャンネルに登録されているクラスタの場合、マイナー バージョンの延長サポートの終了日を超えて延長することはできません。
マイナー アップグレードまたはノード アップグレードなし	すべてのマイナー アップグレードとノード アップグレードが除外されます。アップグレードによってクラスタのノードで VM の中断が発生しないようにします。ただし、コントロール プレーンで中断が発生することがあります。	終了日に、除外の作成日から 180 日を超える日付は設定できません。Rapid、Regular、Stable の各チャンネルに登録されているクラスタについては、標準サポートの終了日を超えて延長することはできません。Extended チャンネルに登録されているクラスタの場合、マイナー バージョンの延長サポートの終了日を超えて延長することはできません。

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

メンテナンスの除外を使用したクラスタを作成する

メンテナンスの除外は、新しいクラスタを作成するときに、Google Cloud コンソールで構成できます。このタスクは、gcloud CLI では行えません。

メンテナンスの除外を使用したクラスタを作成するには、次の操作を行います。

1. Google Cloud コンソールで Google Kubernetes Engine のページに移動します。

   Google Kubernetes Engine に移動

2. [ 作成] をクリックします。

3. クラスタを構成します。

4. ナビゲーション パネルの [クラスタ] の下の [自動化] をクリックします。

5. [メンテナンスの除外] で [メンテナンスの除外を追加します] をクリックします。

6. [範囲]、[開始時間]、[終了時間] を選択します。

7. [作成] をクリックします。

ブラック フライデーのメンテナンスの除外の例をご覧ください。

既存のクラスタに対してメンテナンスの除外を構成する

メンテナンスの除外は、Google Cloud コンソールまたは gcloud CLI を使用して既存のクラスタに構成できます。

gcloud

既存のクラスタに対してメンテナンスの除外を構成します。

gcloud container clusters update CLUSTER_NAME \
    --add-maintenance-exclusion-name EXCLUSION_NAME \
    --add-maintenance-exclusion-start START_DATE_TIME \
    --add-maintenance-exclusion-end END_DATE_TIME \
    --add-maintenance-exclusion-scope SCOPE

次のように置き換えます。

• CLUSTER_NAME: クラスタの名前。
• EXCLUSION_NAME: メンテナンスの除外の名前。
• START_DATE_TIME: 除外の開始日時。
• END_DATE_TIME: 除外の終了日時。
• SCOPE: 除外するアップグレードの範囲。no_upgrades、no_minor_upgrades、no_minor_or_node_upgrades のいずれかになります。

サポートされている日付と時刻の形式を表示するには、gcloud topic datetimes を実行します。

Console

既存のクラスタのメンテナンスの除外を構成するには:

1. Google Cloud コンソールで Google Kubernetes Engine のページに移動します。

   Google Kubernetes Engine に移動

2. クラスタのリストで、変更するクラスタの名前をクリックします。

3. [自動化] の [メンテナンスの除外] フィールドの横にある [メンテナンスの除外を編集] をクリックします。

4. [メンテナンスの除外] で [メンテナンスの除外を追加します] をクリックします。

5. [範囲]、[開始時間]、[終了時間] を選択します。

6. [変更内容を保存] をクリックします。

メンテナンスの除外を削除する

メンテナンスの除外を削除するには、Google Cloud コンソールまたは gcloud CLI を使用します。

gcloud

既存のメンテナンスの除外を削除します。

gcloud container clusters update CLUSTER_NAME \
    --remove-maintenance-exclusion EXCLUSION_NAME

次のように置き換えます。

• CLUSTER_NAME: 既存のクラスタの名前。
• EXCLUSION_NAME: 削除するメンテナンスの除外の名前。

Console

既存のクラスタからメンテナンスの除外を削除するには:

1. Google Cloud コンソールで Google Kubernetes Engine のページに移動します。

   Google Kubernetes Engine に移動

2. クラスタのリストで、変更するクラスタの名前をクリックします。

3. [自動化] の [メンテナンスの除外] フィールドの横にある [メンテナンスの除外を編集] をクリックします。

4. [メンテナンスの除外] で、削除する除外の [終了時間] フィールドの横の [アイテムの削除] をクリックします。

5. [変更を保存] をクリックします。

クラスタのメンテナンスの除外をすべて表示するには、クラスタのメンテナンス ポリシーを表示します。

メンテナンスの除外の例

次の例では、ブラック フライデーからサイバー マンデーまでの 4 日間にわたりメンテナンスを除外しています。多くの小売店にとって、この時期は 1 年で最も売り上げが見込める期間です。次の例は、2021 年のブラック フライデー（2021 年 11 月 26 日）から 2021 年のサイバー マンデー（2021 年 11 月 29 日）、東海岸の午前 0 時（UTC-5）から西海岸の 23:59:59（UTC-8）までの間、メンテナンスの時間枠の実行をブロックする方法を説明します。

gcloud container clusters update sample-cluster \
    --add-maintenance-exclusion-name black-friday \
    --add-maintenance-exclusion-start 2021-11-26T00:00:00-05:00 \
    --add-maintenance-exclusion-end 2021-11-29T23:59:59-08:00 \
    --add-maintenance-exclusion-scope no_upgrades

クラスタのメンテナンス ポリシーの表示

クラスタのメンテナンス ポリシーを表示するには、次のコマンドを使用します。これにより、メンテナンス ポリシーにメンテナンスの時間枠が設定されているかどうかと、すべてのメンテナンスの除外も表示されます。

gcloud container clusters describe CLUSTER_NAME

トラブルシューティング

メンテナンスの除外範囲の制限はリリース チャンネルにのみ適用可能

メンテナンスの除外で自動アップグレードの範囲を制限する場合、クラスタがリリース チャンネルに登録されている必要があります。登録しないと、次のエラーが発生することがあります。

ERROR: (gcloud.container.clusters.update) INVALID_ARGUMENT: Cannot update to
STATIC channel since following maintenancePolicy.maintenanceExclusions can only
apply to release channels. Please remove those maintenance exclusions.

ERROR: (gcloud.container.clusters.update) ResponseError: code=400,
message=MaintenancePolicy.maintenanceExclusions["no"] could not apply to cluster
in STATIC channel, only no_upgrades exclusions are allowed in STATIC channel.

上限を超えるメンテナンスの除外

すべてのアップグレードを除外する（つまり、「アップグレードなし」の範囲）メンテナンスの除外は 3 つまで指定できます。それ例外の場合、次のエラーが発生します。

ERROR: (gcloud.container.clusters.update) ResponseError: code=400,
message=Number of active maintenance exclusions exceeds limit (3).

メンテナンスの除外は合計で最大 20 個まで指定できます。それ以上指定すると、次のエラーが発生します。

ERROR: (gcloud.container.clusters.update) ResponseError: code=400,
message=Number of total maintenance exclusions exceeds limit (20).

次のステップ

• クラスタとノードのアップグレードの詳細を確認する
• ノードの自動アップグレードを有効にする方法を確認する
• クラスタ通知を受信する方法を確認する。