クラスタのライフサイクルの変更を管理して中断を最小限に抑える

このページでは、ワークロードの中断を最小限に抑えながらパフォーマンスと可用性を最大化するために、Google Kubernetes Engine（GKE）がクラスタのライフサイクル中に変更を管理する方法について説明します。

このページは、ワークロードの中断を最小限に抑えるためにクラスタ環境を計画して最適化するプラットフォーム管理者を対象としています。このページは、クラスタの管理とクラスタ管理の概要で説明されている基本的なクラスタ管理タスクの実行方法を学習する前または後に読むことができます。

マネージド プラットフォームと責任共有

GKE は、Google が管理する Kubernetes オープンソース コンテナ オーケストレーション プラットフォームです。GKE の仕組みで説明したように、GKE クラスタは、システム コンポーネントを実行する管理ノードを含むコントロール プレーンと、ワークロードをデプロイするワーカーノードで構成されます。

ワークロードを実行するための最適なクラスタ環境を構築し、パフォーマンスと可用性を最大化して、中断を最小限に抑えることは共有責任です。

  • GKE の責任は、信頼性と可用性が高く、安全で高パフォーマンスのクラスタ環境を維持することです。これを行うために、GKE はコントロール プレーン、システム コンポーネント、ワーカーノード（Autopilot モードの場合）を管理します。
  • プラットフォーム管理者の責任は、クラスタを構成し、ワークロードを管理することです。これには、中断に対処するための準備も含まれます。Standard モードの場合は、ノードプールでグループ化されるワーカーノードの作成と管理も行います。

詳細については、GKE の共有責任をご覧ください。

GKE がクラスタのライフサイクル中に変更を管理する仕組み

Kubernetes の実装として、GKE クラスタは、ワークロードを実行するための最適な環境を維持するために連携するプロセスとシステムのネットワークです。クラスタを管理するために、GKE はメンテナンス タスクの実行、変更の適用、オペレーションの開始、コンポーネントの更新、コントロール プレーンとノードのバージョンのアップグレードを行います。

アプリケーションの日常的な実行のほとんどはバックグラウンドで行われるため、ワークロードが中断されることなく実行されます。ただし、次のセクションで説明するように、一部の重要な変更は、ワークロードを一時的に中断する方法で完了する必要があります。

ワークロードが中断される可能性のあるクラスタの変更

GKE はワークロードをシームレスに実行するよう努めていますが、一部の重要な変更では、ワークロードを一時的に中断する必要があります（主に、ワークロードを実行しているノードの再起動を伴う変更です）。GKE と Kubernetes の機能を使用して、停止を行うタイミングと方法を指定することで、停止が発生したときにワークロードが変更を正常に処理できるようにします。

以降のセクションでは、GKE がクラスタに行う変更の種類と、それに伴う中断の種類、準備方法について説明します。

GKE クラスタのライフサイクル管理によるアップグレードと更新

GKE では、クラスタのアップグレードとクラスタの更新は関連しています。

GKE では、クラスタのアップグレード（または単にアップグレード）という用語は、コントロール プレーンの Kubernetes バージョン（コントロール プレーンのアップグレード）またはノードのアップグレード（ノードのアップグレード）、あるいはその両方の更新を表します。Standard クラスタを使用する場合、GKE は単一オペレーションでノードのノードプールをアップグレードするため、ノードのアップグレードはノードプールのアップグレードとも呼ばれます。

クラスタの更新（または単に更新）という用語は、バージョンの更新など、コントロール プレーンまたはノードのあらゆる種類の変更を指す、より一般的な用語です。GKE は、アップグレード、その他のタイプの更新、必要なメンテナンス オペレーションを実行することで、クラスタ環境を積極的に管理しています。これらのアクションにより、クラスタのパフォーマンス、セキュリティ、最新の機能とバグ修正が常に最新の状態に保たれています。GKE は、ノード アップグレード戦略やメンテナンス ポリシーなどのツールを使用して、これらのプロセス中の中断を最小限に抑えます。

ノードの更新による中断の計画

特定の種類のクラスタ変更（主にノードの変更）は、中断を引き起こす可能性があります。

GKE は、ノードのアップグレード戦略を使用して、ワークロードのニーズに合わせて最適化された方法で、Autopilot ノードまたは Standard クラスタ ノードプールの両方のノードを更新します。これらの戦略は、バージョンのアップグレードと、他のタイプのノードの変更にも適用されます。この戦略により、GKE はノードのアップデート中に中断を最小限に抑えることができます。これは、クラスタの機能とパフォーマンスを維持するために重要です。

ベスト プラクティス:

メンテナンスの時間枠と除外を使用して、クラスタのメンテナンスを行うタイミングと行わないタイミングを選択します。また、Standard クラスタの場合は、ワークロード プロファイルとリソース制約に最適なノード アップグレード戦略を選択します。

手動と自動の両方で開始されるノードの変更について、GKE は次の一般的な特性で変更を行います。

  • 通常、変更はメンテナンス ポリシーに準拠します。GKE がノードに変更を加えると、通常、これらの変更は GKE メンテナンス ポリシーに準拠します。ノードプール内のすべてのノードの再作成を必要とする手動変更を開始する場合は、次の点を考慮してください。
    • 一部の変更の場合、GKE はメンテナンス ポリシーに従い、メンテナンスが利用可能になるまで送信された変更を適用しません。GKE が次回のメンテナンスを待機していて、変更が緊急の場合は、変更を手動で適用して、新しい構成をすぐに適用できます。
    • 手動アップグレードなどのその他の手動変更の場合、GKE はメンテナンス ポリシーを適用しません。このような手動変更を行う場合は、ワークロードが即時中断に対応できるように準備してください。
  • 変更では通常、ノードのアップグレード戦略が使用されます。GKE は、バージョン アップグレード以外のノード アップデートなど、自動または手動で開始された変更をノードに適用するときに、ノード アップグレード戦略（サージ アップグレードまたは Blue/Green アップグレード）を選択します。Autopilot は常にサージ アップグレードを使用します。Standard クラスタのノードプールの変更では、Blue/Green アップグレードを構成して特定の種類の変更を行う場合を除き、通常はサージ アップグレードを使用します。
  • 変更に十分なリソースが必要: GKE がノードのアップグレード戦略を使用して変更を適用する場合、この変更には戦略とその構成に応じて一定量のリソースが必要です。クラスタのプロジェクトには、十分なリソース割り当て、リソースの可用性、予約容量（特定の予約アフィニティを持つノードプールの場合）が必要です。詳細については、ノードのアップグレード用のリソースを確保するをご覧ください。

特定の変更とその特性の詳細なリストについては、このページの GKE クラスタの変更の種類をご覧ください。

破壊的な変化に備えてワークロードの可用性を最大化する

GKE クラスタで実行されるワークロードの可用性を最大限に高めるには、次のセクションで説明する操作を行うことをおすすめします。

クラスタの可用性を選択する

コントロール プレーンの可用性が優先される場合は、ゾーン Standard クラスタではなく、Autopilot クラスタまたはリージョン Standard クラスタを選択します。詳細については、クラスタ構成の選択についてをご覧ください。

GKE ツールを使用してアップグレードを制御する

次のツールを使用して、GKE によるクラスタのアップグレードのタイミングと方法を制御し、ベスト プラクティスを実装できます。

クラスタの管理とモニタリング

クラスタの潜在的な中断を管理するには、次のタスクを継続的に実行します。

ワークロードを準備する

ワークロードの中断に対する耐障害性を可能な限り高めて、中断を管理します。

これらのトピックの一般的な説明については、GKE のベスト プラクティス: ビジネスの継続性を確保する Day 2 オペレーションのサービス停止を管理するセクションをご覧ください。

GKE クラスタの変更の種類

次の表に、クラスタに対する主な変更の最も一般的なタイプと、これらの変更の特性（頻度や中断レベルなど）も示します。

アップグレードの種類

次の表で、アップグレードがクラスタ環境にどのように影響するかを確認してください。

変更 自動または手動で開始 メンテナンス ポリシーを遵守する 頻度 中断の種類 中断のレベル
コントロール プレーンのアップグレード 自動または手動

自動アップグレードは、極めてまれな緊急修正を除き、サポート終了までメンテナンス ポリシーを遵守します。

手動アップグレードはメンテナンス ポリシーによってブロックされません。

パッチ アップグレード（リリース チャンネルに応じて毎週）。

マイナー アップグレード: 約 4 か月ごと

Extended チャンネル クラスタの場合、マイナー アップグレードはマイナー バージョンのサポート終了が近づいた場合にのみ行われます。

 コントロール プレーン

Autopilot クラスタとリージョン Standard クラスタの場合、コントロール プレーンは引き続き使用できます。

ゾーン Standard クラスタの場合、コントロール プレーンと通信できない時間が数分間あります。つまり、その間はクラスタ、ノード、ワークロードを構成できません。
ノードのアップグレード 自動または手動

自動アップグレードは、極めてまれな緊急修正を除き、サポート終了までメンテナンス ポリシーを遵守します。

手動アップグレードはメンテナンス ポリシーによってブロックされません。

通常は、コントロール プレーンのアップグレードと同じです。

クラスタがリリース チャンネルに登録されておらず、ノードの自動アップグレードを無効にしている場合は、クラスタのノードプールを手動でアップグレードする必要があります。

 Autopilot クラスタのすべてのノード、または 1 つ以上の Standard クラスタ ノードプール。

ノードを再作成するにはシャットダウンする必要があり、Pod は置き換える必要があります。

GKE は、Autopilot にサージ アップグレードを使用し、Standard クラスタには構成されたノード アップグレード戦略（サージまたは Blue/Green）を使用します。

ノード アップグレード戦略に従ってノードを再作成し、メンテナンス ポリシーを遵守する手動変更

次の表で、これらの手動変更がクラスタ環境にどのように影響するかを確認してください。このリストには、GKE メンテナンス ポリシーが適用される手動での変更が含まれています。

変更 自動または手動で開始 メンテナンス ポリシーを遵守する 頻度 中断の種類 中断のレベル
コントロール プレーンの IP アドレスのローテーション クラスタ認証情報の有効期限が 30 日以内の場合は自動的に開始されます。手動での開始も可能です。 メンテナンス ポリシーが適用されます。メンテナンス アベイラビリティによってブロックされてから 7 日後に失敗します。 このタイプの手動変更ごとに 1 回。自動開始の場合はクラスタ認証情報の有効期間によって異なります。 Autopilot クラスタのすべてのノード、各 Standard クラスタ ノードプールのすべてのノード。

ノードを再作成するにはシャットダウンする必要があり、Pod は置き換える必要があります。

GKE はサージ アップグレードを使用してノードを再作成します。
コントロール プレーンの認証情報のローテーション クラスタ認証情報の有効期限が 30 日以内の場合は自動的に開始されます。手動での開始も可能です。 メンテナンス ポリシーが適用されます。メンテナンス アベイラビリティによってブロックされてから 7 日後に失敗します。 このタイプの手動変更ごとに 1 回。自動開始の場合はクラスタ認証情報の有効期間によって異なります。 Autopilot クラスタのすべてのノード、各 Standard クラスタ ノードプールのすべてのノード。

ノードを再作成するにはシャットダウンする必要があり、Pod は置き換える必要があります。

GKE はサージ アップグレードを使用してノードを再作成します。
シールドされたノードの構成 手動で開始 メンテナンス ポリシーの適用 このタイプの変更ごとに 1 回 更新する Standard クラスタ ノードプール内のすべてのノードを更新する必要があります。

ノードを再作成するにはシャットダウンする必要があり、Pod は置き換える必要があります。

GKE はサージ アップグレードを使用してノードを再作成します。
ネットワーク ポリシーの構成 手動で開始 メンテナンス ポリシーの適用 このタイプの変更ごとに 1 回 Autopilot クラスタのすべてのノード、各 Standard クラスタ ノードプールのすべてのノード。

ノードを再作成するにはシャットダウンする必要があり、Pod は置き換える必要があります。

GKE はサージ アップグレードを使用してノードを再作成します。
ノード内の可視化の構成 手動で開始 メンテナンス ポリシーの適用 このタイプの変更ごとに 1 回 Autopilot クラスタのすべてのノード、各 Standard クラスタ ノードプールのすべてのノード。

ノードを再作成するにはシャットダウンする必要があり、Pod は置き換える必要があります。

GKE はサージ アップグレードを使用してノードを再作成します。
NodeLocal DNSCache の構成 手動で開始 メンテナンス ポリシーの適用 このタイプの変更ごとに 1 回 更新する Standard クラスタ ノードプール内のすべてのノードを更新する必要があります。

ノードを再作成するにはシャットダウンする必要があり、Pod は置き換える必要があります。

GKE はサージ アップグレードを使用してノードを再作成します。

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

次の表で、メンテナンス ポリシーが適用されない自動メンテナンスがクラスタ環境を中断する仕組みを確認します。

変更 自動または手動で開始 メンテナンス ポリシーを遵守する 頻度 中断の種類 中断のレベル
コントロール プレーンの修復またはサイズ変更 自動 メンテナンス ポリシーは適用されません

コントロール プレーンの修復頻度はランダムですが、Autopilot クラスタとリージョン Standard クラスタには影響しません。

コントロール プレーンのサイズ変更は頻繁ではありませんが、クラスタ スケーリング イベントの頻度に応じて増加します。また、Autopilot クラスタとリージョン Standard クラスタには影響しません。

 コントロール プレーン

Autopilot クラスタとリージョン Standard クラスタの場合、コントロール プレーンは引き続き使用できます。

ゾーン Standard クラスタの場合、コントロール プレーンと通信できない時間が数分間あります。つまり、その間はクラスタ、ノード、ワークロードを構成できません。
ホスト メンテナンス イベント 自動 メンテナンス ポリシーは適用されません 頻度については、メンテナンス イベントをご覧ください。 1 つのノード

ほとんどのタイプのノードでは影響は最小限です。

GPU や TPU を搭載したノードなど、一部のノードでは中断が長引く可能性があります。詳細については、その他の Google Cloud メンテナンスをご覧ください。
ノードの自動修復 自動 メンテナンス ポリシーは適用されません

ノードの自動修復の頻度はランダムです。

 1 つのノード ノードが再起動されるため、ノードで実行されている Pod は中断されます。
Spot VM とプリエンプティブル VM を再利用 自動 メンテナンス ポリシーは適用されません

プリエンプティブル VM の場合は、少なくとも 24 時間に 1 回。

Spot VM の場合、Compute Engine が別の場所でリソースを必要とするとき。

 1 つのノード Spot VM の終了と正常なシャットダウンとプリエンプティブル VM の終了と正常なシャットダウンで詳細を確認してください。

メンテナンス ポリシーを遵守せずにノード アップグレード戦略に従ってノードを再作成する手動変更

次の表で、これらの手動変更がクラスタ環境にどのように影響するかを確認してください。このリストには、GKE がサージ アップグレードを使用する場合と GKE が Blue/Green アップグレードを使用する場合の変更が含まれています。これらの変更はメンテナンス ポリシーに準拠していないため、他のセクションには含まれていません。

変更 自動または手動で開始 メンテナンス ポリシーを遵守する 頻度 中断の種類 中断のレベル
ノードプールのラベルの更新 手動で開始 メンテナンス ポリシーを尊重せず、すぐに変更を加えます。 このタイプの変更ごとに 1 回 Standard クラスタ ノードプール内のすべてのノード 有効なメンテナンス ポリシーに関係なく、既存のノードプールのノードラベルを更新すると、GKE はサージ アップグレードを使用してノードプールをすぐに再作成します。
ノードマシン属性を変更してノードを垂直方向にスケーリングする 手動で開始 メンテナンス ポリシーを尊重せず、すぐに変更を加えます。 このタイプの変更ごとに 1 回 Standard クラスタ ノードプール内のすべてのノード GKE は、有効なメンテナンス ポリシーに関係なく、サージ アップグレードを使用して既存のノードプールのノードをすぐに再作成します。
イメージの種類の変更 手動で開始 メンテナンス ポリシーを尊重せず、すぐに変更を加えます。 このタイプの変更ごとに 1 回 Standard クラスタ ノードプール内のすべてのノード

ノードを再作成するにはシャットダウンする必要があり、Pod は置き換える必要があります。

GKE は、Standard クラスタに構成されたノード アップグレード戦略（サージまたは Blue/Green）を使用します。
Standard クラスタ ノードプール内のストレージ プールを追加または置換する 手動で開始 メンテナンス ポリシーを尊重せず、すぐに変更を加えます。 このタイプの変更ごとに 1 回 Standard クラスタ ノードプール内のすべてのノード

ノードを再作成するにはシャットダウンする必要があり、Pod は置き換える必要があります。

GKE は、Standard クラスタに構成されたノード アップグレード戦略（サージまたは Blue/Green）を使用します。
画像ストリーミングの有効化 手動で開始

クラスタレベルで更新する場合は、メンテナンス ポリシーを遵守します。

個々のノードプールを更新するときに、メンテナンス ポリシーは尊重しません。

 このタイプの変更ごとに 1 回

ノードプール レベルで切り替えた場合、Standard クラスタ ノードプール内のすべてのノード。

クラスタレベルで切り替えた場合、その設定を個別に有効または無効にしていない Standard クラスタ ノードプールのノード。

 GKE はサージ アップグレードを使用して、ノードプールのノードを再作成します。
ネットワーク パフォーマンス構成の更新 手動で開始 メンテナンス ポリシーを尊重せず、すぐに変更を加えます。 このタイプの変更ごとに 1 回 Standard クラスタ ノードプール内のすべてのノード

ノードを再作成するにはシャットダウンする必要があり、Pod は置き換える必要があります。

GKE は、有効なメンテナンス ポリシーに関係なく、サージ アップグレードを使用して既存のノードプールのノードをすぐに再作成します。
gVNIC の有効化 手動で開始 メンテナンス ポリシーを尊重せず、すぐに変更を加えます。 このタイプの変更ごとに 1 回 Standard クラスタ ノードプール内のすべてのノード

ノードを再作成するにはシャットダウンする必要があり、Pod は置き換える必要があります。

GKE は、有効なメンテナンス ポリシーに関係なく、サージ アップグレードを使用して既存のノードプールのノードをすぐに再作成します。
ノードシステム構成の変更 手動で開始 メンテナンス ポリシーを尊重せず、すぐに変更を加えます。 このタイプの変更ごとに 1 回 Standard クラスタ ノードプール内のすべてのノード

ノードを再作成するにはシャットダウンする必要があり、Pod は置き換える必要があります。

GKE は、有効なメンテナンス ポリシーに関係なく、サージ アップグレードを使用して既存のノードプールのノードをすぐに再作成します。
機密ノード 手動で開始 メンテナンス ポリシーを尊重せず、すぐに変更を加えます。 このタイプの変更ごとに 1 回 Standard クラスタ ノードプール内のすべてのノード

ノードを再作成するにはシャットダウンする必要があり、Pod は置き換える必要があります。

GKE は、有効なメンテナンス ポリシーに関係なく、サージ アップグレードを使用して既存のノードプールのノードをすぐに再作成します。

ノードの再作成が不要な変更

次の表に、ノードの再作成が不要なノード構成の変更を示します。これらの変更は中断しませんが、更新されたノード構成がワークロードに影響する場合は、中断する可能性があります。

変更 自動または手動で開始 メンテナンス ポリシーを遵守する 頻度 中断の種類 中断のレベル

次の設定を更新します。

 手動で開始 メンテナンス ポリシーを尊重せず、すぐに変更を加えます。 このタイプの変更ごとに 1 回 関連するすべてのノードが更新されます。 ノードを再作成せずにノード構成が更新されるため、Pod を置き換える必要はありません。

次のステップ