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

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

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

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

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 クラスタの変更の種類

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

アップグレードの種類

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

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

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

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

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

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

Extended チャンネル クラスタの場合、マイナー アップグレードはマイナー バージョンのサポートが終了する直前のみ。

 コントロール プレーン

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

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

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

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

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

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

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

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

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

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

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

変更 自動または手動で開始 メンテナンス ポリシーを遵守する Frequency 中断の種類 中断のレベル
クラスタ認証情報のローテーション クラスタ認証情報の有効期限が 30 日以内の場合は自動的に、手動で開始することもできます。 メンテナンス ポリシーが適用されますが、GKE は認証情報の有効期限が切れてから 30 日以内にメンテナンス ポリシーをオーバーライドすることがあります。また、最初のステップの後に特定のオペレーションを手動でトリガーした場合、そのオペレーションにはメンテナンス ポリシーが適用されません。 このタイプの手動変更ごとに 1 回、または自動開始の場合はクラスタ認証情報の有効期間によって異なります。ローテーション プロセスの特定のステップのオペレーションを手動で呼び出すことができます。 一部の手順では、コントロール プレーン。他の手順では、Autopilot クラスタのすべてのノード、各 Standard クラスタ ノードプールのすべてのノード。

ローテーションを開始してローテーションを完了すると、中断レベルは次のようになります。

  • Autopilot クラスタとリージョン Standard クラスタの場合、コントロール プレーンは引き続き使用できます。
  • ゾーン Standard クラスタの場合、どちらのオペレーションでも短時間のダウンタイムが発生します。つまり、コントロール プレーンと通信してクラスタ、ノード、ワークロードの構成などのオペレーションを実行できない時間が数分間発生します。

ノードが再作成されると、中断のレベルは次のようになります。

  • ノードを再作成するにはシャットダウンする必要があり、Pod は置き換える必要があります。
  • GKE はサージ アップグレードを使用してノードを再作成します。
コントロール プレーンの IP アドレスのローテーション 手動で開始 メンテナンス ポリシーに準拠しますが、最初のステップの後に特定のオペレーションを手動でトリガーした場合、そのオペレーションはメンテナンス ポリシーに準拠しません。 このタイプの手動変更ごとに 1 回。ローテーション プロセスの特定のステップのオペレーションを手動で呼び出すことができます。 一部の手順では、コントロール プレーン。他の手順では、Autopilot クラスタのすべてのノード、各 Standard クラスタ ノードプールのすべてのノード。

ローテーションを開始してローテーションを完了すると、中断レベルは次のようになります。

  • Autopilot クラスタとリージョン Standard クラスタの場合、コントロール プレーンは引き続き使用できます。
  • ゾーン Standard クラスタの場合、どちらのオペレーションでも短時間のダウンタイムが発生します。つまり、コントロール プレーンと通信してクラスタ、ノード、ワークロードの構成などのオペレーションを実行できない時間が数分間発生します。

ノードが再作成されると、中断のレベルは次のようになります。

  • ノードを再作成するにはシャットダウンする必要があり、Pod は置き換える必要があります。
  • GKE はサージ アップグレードを使用してノードを再作成します。
シールドされたノードの構成 手動で開始

コントロール プレーンの再作成はメンテナンス ポリシーを尊重せず、すぐに変更を加えます。

ノードの再作成では、メンテナンス ポリシーが考慮されます。

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

コントロール プレーンが更新されます。

コントロール プレーンが更新されたら、各 Standard クラスタ ノードプールのすべてのノードを再作成する必要があります。

コントロール プレーンが再作成されると、中断レベルは次のようになります。

  • Autopilot クラスタとリージョン Standard クラスタの場合、コントロール プレーンは引き続き使用できます。
  • ゾーン Standard クラスタの場合、どちらのオペレーションでも短時間のダウンタイムが発生します。つまり、コントロール プレーンと通信してクラスタ、ノード、ワークロードの構成などのオペレーションを実行できない時間が数分間発生します。

ノードが再作成されると、中断のレベルは次のようになります。

  • ノードを再作成するにはシャットダウンする必要があり、Pod は置き換える必要があります。
  • GKE はサージ アップグレードを使用してノードを再作成します。
ネットワーク ポリシーの構成 手動で開始 メンテナンス ポリシーを尊重する このタイプの変更ごとに 1 回 Autopilot クラスタのすべてのノード、各 Standard クラスタ ノードプールのすべてのノード。

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

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

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

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

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

GKE はサージ アップグレードを使用してノードを再作成します。
イメージ ストリーミングの有効化 手動で開始

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

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

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

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

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

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

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

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

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

コントロール プレーンの修復頻度はランダムですが、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 アップグレードを使用する場合の変更が含まれます。これらの変更はメンテナンス ポリシーに準拠していないため、他のセクションには含まれません。

変更 自動または手動で開始 メンテナンス ポリシーを遵守する Frequency 中断の種類 中断のレベル
ノードプールのラベルの更新 手動で開始 メンテナンス ポリシーを尊重せず、すぐに変更を加えます。 このタイプの変更ごとに 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 は、有効なメンテナンス ポリシーに関係なく、サージ アップグレードを使用して既存のノードプールのノードをすぐに再作成します。

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

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

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

次の設定を更新します。

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

次のステップ