このドキュメントでは、マルチクラスタの Google Kubernetes Engine（GKE）環境でアップグレードを設計、計画、実装する方法について説明します。このドキュメントではアップグレードにマルチクラスタ Ingress を使用していますが、外部ロードバランサを手動で構成するなど、別のソリューションでコンセプトを実現することもできます。このドキュメントに付属のチュートリアルでは、マルチクラスタ Ingress を使用してマルチクラスタ GKE 環境をアップグレードする方法を説明しています。このドキュメントは、GKE クラスタのフリートを管理する Google Cloud 管理者を対象としています。
マルチクラスタ アーキテクチャの必要性
このセクションでは、マルチクラスタの Kubernetes アーキテクチャが必要になる理由について説明します。
インフラストラクチャとしての Kubernetes
このドキュメントでは、Kubernetes クラスタをインフラストラクチャのコンポーネントとして説明します。インフラストラクチャは誰でも自由に使えるものです。コンポーネントはその目的を果たすために存在するため、インフラストラクチャのコンポーネントを特別に扱う必要はありません。Kubernetes の目的は、デベロッパーや運用者に自動化とオーケストレーションの機能を提供し、コンテナベースのアプリケーションとサービスをユーザーに提供できるようにすることです。ユーザーは社内のチームである場合もあれば、他のサービスや外部ユーザーの場合もあります。
一般的なマルチクラスタ シナリオ
マルチクラスタ環境を使用する理由は、Kubernetes がインフラストラクチャとして機能することだけではありません。
- 地理的な意味。多くの Service は、複数のリージョンに存在する必要があります。ユーザーに近いリージョンに Service を配置すると、単一リージョンから Service が提供される場合よりもレイテンシが短くなり、ユーザーの利便性が向上します。Kubernetes クラスタは単一リージョンで実行されます。マルチリージョン デプロイでは、複数のリージョンに複数の Kubernetes クラスタが必要になります。また、マルチクラウド環境やハイブリッド クラウド環境では各環境に複数のクラスタが必要になります。多くの場合、Kubernetes クラスタは Service（ステートフル）のデータソースと同じ場所に配置されます。リレーショナル データベース管理システム（RDBMS）など、特定のアプリケーションはバックエンドと同じロケーション（リージョンとゾーンなど）に配置しなければなりません。
- テナンシーと環境。Kubernetes クラスタはマルチテナンシー用に設計されています。複数のチームが、それぞれの Service で 1 つのクラスタを共有できます。Kubernetes は、名前空間、ロールベースのアクセス制御（RBAC）、ネットワーク ポリシー、認証などの標準リソースを提供し、マルチテナント環境で適切なアクセス制御を構成します。会社のポリシー、プライバシー、セキュリティ、業界規制により、同じクラスタ上で他の Service と共存できない Service もあります。このような場合、特定のテナントと独自のクラスタに分離するため、複数のクラスタが必要になります。通常、開発環境、ステージング環境、本番環境もそれぞれ別のクラスタとして作成されます。環境が異なれば、アクセス権のスコープやインストールされるアプリケーションも大きく異なるため、これらを別のクラスタとして維持する必要があります。
- 構成と機能。特定のファンクションを実行するためにクラスタを作成することもあります。たとえば、ML ワークフローでは Kubeflow やデータ分析ジョブを使用しますが、これらのノードでは複数の GPU やハードウェアが必要になる場合があります。たとえば、バッチ分析ワークロードでは、複数の Spot VM から構成されたクラスタを使用します。こうしたハードウェア要件は、他の Service には当てはまらないこともあります。ビジネスに不可欠でないワークフローの場合、エフェメラル クラスタ（有効期間が短いクラスタ）で十分かもしれません。オブザーバビリティ（ロギング、指標、トレース）や CI / CD ツールなどの共有サービスの場合は、独自のプラットフォーム管理クラスタで実行したほうが良いでしょう。機能別のクラスタはビジネスに重要でないワークフローでよく使用されています。
- 復元性。複数のクラスタを使用すると、環境の復元力を高めることができます。それぞれのクラスタには影響領域があります。たとえば、クラスタの誤動作や構成ミス、計画的または予定外のメンテナンスでクラスタがオフラインになることで影響を受ける Service の数が影響領域の 1 つとなります。サイズの小さいクラスタが数多く存在する場合、規模の小さい影響領域が数多く存在することになります。Service が 2 つのクラスタに存在する場合、各クラスタで同等の負荷を共有します。1 つのクラスタがオフラインになると、トラフィックの 50% が影響を受けます。この Service を単一クラスタで処理した場合、そのクラスタでのイベントが発生するたびに、その Service が完全に停止することになります。このような理由から、障害復旧のために複数のクラスタが使用されています。
このドキュメントでは、マルチクラスタ デプロイの復元力を中心に説明します。
マルチクラスタと分散 Service
分散 Service は、複数の Kubernetes クラスタにデプロイされる Kubernetes Service です。分散 Service はステートレスな Service で、複数のクラスタで同じように機能します。分散 Service は同じ Kubernetes Service 名を持ち、複数のクラスタで同じ名前空間に実装されます。Kubernetes Service は、実行される Kubernetes クラスタに関連付けられます。Kubernetes クラスタがオフラインになると、Kubernetes Service もオフラインになります。分散 Service は、個々の Kubernetes クラスタから抽象化されています。1 つ以上の Kubernetes クラスタが停止した場合でも、分散 Service がオンラインで、サービスレベル目標（SLO）の範囲内であることもあります。
次の図で、frontend は複数のクラスタで実行される分散 Service です。どのクラスタでも同じ Service 名と名前空間が使用されています。
このアーキテクチャでは、frontend Service は単一のクラスタに関連付けられていません。概念上は、Kubernetes クラスタ インフラストラクチャ レイヤにまたがるレイヤとして表されています。frontend Service を実行している個々のクラスタが停止しても、frontend はオンライン状態で維持されます。accounts Service や ledger Service など、個々のクラスタでは別の Service も実行されています。稼働時間と可用性は、それぞれの Service が存在する Kubernetes クラスタの稼働時間によって異なります。
復元力は、マルチクラスタ デプロイメントを使用する理由の 1 つです。分散 Service により、マルチクラスタ アーキテクチャで復元力の高いサービスを作成できます。ステートレスなサービスは、マルチクラスタ環境の分散型サービスの主要な候補となります。分散 Service を利用する場合には、次の要件を考慮する必要があります。
マルチクラスタ ネットワーク分散 Service 宛てのトラフィックをその Service が実行されているクラスタに送信するには、マルチクラスタ Ingress などのマルチクラスタ Ingress テクノロジーを使用するか、独自の外部ロードバランサやプロキシ ソリューションを使用します。いずれの場合も、分散 Service の特定のインスタンスにルーティングするタイミング、場所、量を制御する必要があります。次の図は、2 つの GKE クラスタで実行される分散 Service
frontendにトラフィックを送信するロードバランサを示しています。
オブザーバビリティ。分散 Service の SLO（通常は可用性とレイテンシ）は、ツールを使用してまとめて測定します。これにより、複数のクラスタにまたがる各 Service の全体的なパフォーマンスを把握できます。ほとんどのオブザーバビリティ ソリューションでは、分散 Service は明確に定義されたリソースではありませんが、個々の Kubernetes Service の指標を収集して組み合わせることができます。Cloud Monitoring などのソリューションや、Grafana などのオープンソース ツールを使用することで、Kubernetes Service の指標を収集できます。Istio や Anthos Service Mesh などのサービス メッシュ ソリューションでも、インストルメンテーションなしで Service の指標を収集できます。
サービスの提供。Kubernetes Services は、単一の Kubernetes クラスタ内でノードレベルのフォールト トレラントを提供します。これは、Kubernetes Service がノードの停止に対応できることを意味します。ノードが停止した場合、Kubernetes コントロール プレーン ノードが Pod を正常なノードに再スケジュールします。この処理は自動的に行われます。分散 Service はクラスタレベルでのフォールト トレラントを提供します。これは、分散 Service がクラスタの停止に対応できることを意味します。分散 Service のキャパシティ プランニングを行う際に、このような Service の配置も検討する必要があります。分散 Service をすべてのクラスタで実行する必要はありません。分散 Service が実行されるクラスタは次の要件によって異なります。
- Service はどのリージョンで必要か。
- 分散 Service に必要な SLO はなにか。
- 分散 Service にどのようなタイプのフォールト トレラントが必要か（クラスタ、ゾーン、リージョン）。たとえば、1 つのゾーン内に複数のクラスタが必要かどうか、1 つのリージョンのゾーンをまたがる複数のクラスタが必要かどうか、複数リージョンの複数のクラスタが必要かどうか、などを検討します。
最悪の状況が発生したときに分散 Service がどのレベルの耐障害性を備えているべきか。クラスタレイヤの場合、次のオプションがあります。
- N+1（N はサービスのキャパシティ要件を満たすために必要なクラスタの数）。この場合、分散 Service は単一クラスタの障害に耐えることができます。
- N+2。分散 Service は同時に 2 つの障害に耐えることができます。たとえば、2 つのクラスタで Kubernetes Service の計画的な停止と想定外の停止が同時に発生した場合でも、Service を維持することが可能です。
ロールアウトとロールバック。Kubernetes Service などの分散 Service では、段階的なロールアウトとロールバックが可能です。Kubernetes Services とは異なり、分散 Service では段階的な変更をクラスタ単位で行うことができます。ロールアウトとロールバックも Service の要件によって異なります。バグの修正など、すべてのクラスタで同時にサービスをアップグレードしなければならないこともあります。また、クラスタを 1 つずつ変更する段階的なロールアウトが必要になる場合もあります。この段階的なロールアウトでは、サービスに対する変更を段階的に導入することで、分散 Service へのリスクを軽減しています。ただし、クラスタの数によっては、処理に時間がかかることがあります。最適なアップグレード方法は 1 つとは限りません。多くの場合、分散 Service の要件に応じて、ロールアウトとロールバックが併用されています。ここで重要な点は、分散 Service で環境内の変更を段階的に管理できるようにすることです。
事業継続性と障害復旧（BCDR）。この 2 つの用語はよく一緒に使用されています。事業継続性とは、重大なイベント（計画されたイベントまたは想定外のイベント）が発生した場合に重要なサービスの継続が可能かどうかを表しています。一方、障害復旧とは、イベントの発生後にビジネスを正常な状態に戻すために必要な手順を表しています。BCDR にはさまざまな戦略がありますが、このドキュメントでは詳しく説明しません。BCDR では、システムと Service にある程度の冗長性が必要になります。分散 Service の場合、複数のロケーション（クラスタ、ゾーン、リージョン）で実行される点が異なります。
BCDR の戦略は、前述のロールアウトとロールバックの戦略に依存します。たとえば、ロールアウトを段階的または制御された方法で行っている場合、多くのユーザーに影響を及ぼすことなく、バグまたは誤った構成の影響を早期に検出できる可能性があります。最新の CI / CD プラクティスなど、大規模で変更頻度の激しい環境では、すべてのユーザーに同じバージョンの分散 Service が提供されるとは限りません。分散型のシステムと Service に対する BCDR の計画と戦略は、従来のモノリシック アーキテクチャとは異なります。従来のシステムでは、変更が大規模に行われるため、非常に多くのユーザー（場合によってはすべてのユーザー）がその影響を受けることになります。ロールアウトが難しい環境では、冗長システムまたはバックアップ システムを用意する必要があります。分散型のシステムと Service の場合は、ほぼすべての変更が段階的に行われるため、その影響はごく少数のユーザーに限定されます。
クラスタ ライフサイクル管理。制御されたロールアウトやロールバックと同様に、分散 Services に対して制御されたクラスタ ライフサイクル管理を行うことができます。分散 Service はクラスタレベルの復元力を備えているため、クラスタをメンテナンスのローテーションから除外できます。クラスタ ライフサイクル管理は、Kubernetes Services には適用されない分散 Service の原則です。
このドキュメントの残りの部分では、分散 Service のクラスタ ライフサイクルを中心に説明します。
GKE クラスタのライフサイクル管理
クラスタのライフサイクル管理は、サービスの SLO に違反することなく、Kubernetes クラスタのフリートを常に最新かつ正常な状態にしておくために必要な戦略と計画と定義できます。クラスタのライフサイクル管理では、想定外の対応が必要にならないように適切な戦略と計画を立て、日常的に実施する必要があります。
このドキュメントでは、GKE のライフサイクル管理を中心に説明しますが、このコンセプトは Kubernetes の他のディストリビューションにも適用できます。
GKE のバージョニングとアップグレード
クラスタのライフサイクル管理の戦略と計画について検討する前に、クラスタのアップグレードを構成する要素について理解しておきましょう。
クラスタには、コントロール プレーン ノードとワーカーノードの 2 つのコンポーネントが含まれます。Kubernetes クラスタをアップグレードするには、すべてのノードが同じバージョンにアップグレードする必要があります。Kubernetes はセマンティック バージョニング スキーマに従います。Kubernetes のバージョンは X.Y.Z: と表記されます。ここで、X はメジャー バージョン、Y はマイナー バージョン、Z はパッチ バージョンです。マイナー リリースは約 3 か月（四半期）ごとに行われ、Kubernetes プロジェクトには最新の 3 つのマイナー リリースのブランチが維持されます。つまり、9 か月前の Kubernetes マイナー リリースは維持されないため、最新バージョンにアップグレードするときに API の変更が必要になることがあります。Kubernetes のアップグレードは定期的に計画する必要があります。GKE のアップグレードは四半期または 2 四半期ごとに行うことをおすすめします。
GKE クラスタでは、対応するマイナー リリースの Kubernetes バージョンの実行がサポートされます。マイナー バージョンは、任意の時点で少なくとも 2 つ利用できます。
GKE には、次のクラスタの可用性タイプがあります。
- シングルゾーン クラスタ。1 つのコントロール プレーン ノードとすべてのノードプールは、単一リージョン内の単一ゾーンにあります。
- マルチゾーン クラスタ。1 つのコントロール プレーン ノードが 1 つのゾーンにあり、ノードプールは 1 つのリージョンの複数のゾーンにあります。
- リージョン クラスタ。1 つのリージョン内の複数のゾーンに複数のコントロール プレーン ノードとノードプールがあります。
GKE はマネージド サービスであり、コントロール プレーン ノードとワーカーノードの自動アップグレードを行います。
GKE の自動アップグレード
GKE の自動アップグレードは、よく使用されるクラスタのライフサイクル戦略です。GKE の自動アップグレードでは、フルマネージドの方法で GKE クラスタをサポート対象のバージョンに更新します。GKE の自動アップグレードは、コントロール プレーン ノードとワーカーノードを個別にアップグレードします。
マスターの自動アップグレード。デフォルトでは、GKE コントロール プレーン ノードは自動的にアップグレードされます。単一ゾーンクラスタとマルチゾーン クラスタには、1 つのコントロール プレーン（コントロール プレーン ノード）があります。コントロール プレーン ノードのアップグレード中、ワークロードは引き続き実行されます。ただし、アップグレードが完了するまで、新しいワークロードのデプロイ、既存のワークロードの変更、クラスタの構成に対するその他の変更は行うことができません。
リージョン クラスタにはコントロール プレーンの複数のレプリカがありますが、一度にアップグレードされるレプリカは 1 つだけです。アップグレード中は、クラスタが高可用性を維持します。各コントロール プレーン レプリカは、そのアップグレード中にのみ使用不可になります。
ワーカーノードの自動アップグレード。ノードプールは一度に 1 つずつアップグレードされます。ノードプール内では、未定義の順序でノードが一度に 1 つずつアップグレードされます。同時にアップグレードされるノードの数は変更できますが、ノード数とそのワークロードの構成によっては処理に数時間かかる場合があります。
GKE 自動アップグレード ライフサイクル戦略
可能であれば、GKE の自動アップグレードを使用することをおすすめします。GKE の自動アップグレードでは、制御よりも利便性が優先されますが、特定のパラメータを使用すると、クラスタのアップグレード方法とタイミングを制御できます。また、メンテナンスの時間枠と除外対象も制御できます。リリース チャンネルは、バージョンの選択とノードのアップグレード戦略に影響を与え、ノードのアップグレードの順序とタイミングに影響します。これらの制御機能とリージョン クラスタ（複数の Kubernetes コントロール プレーンが存在する場合）を使用しても、GKE の自動アップグレードではサービスの稼働時間は保証されません。次のいずれかを必要とする場合は、GKE の自動アップグレード機能を使用しないでください。
- GKE クラスタのバージョンを正確に制御する。
- GKE をアップグレードするタイミングを正確に制御する。
- GKE フリートのアップグレード戦略（次のセクションを参照）を制御する。
GKE マルチクラスタ ライフサイクル管理
このセクションでは、さまざまな GKE マルチクラスタのライフサイクル管理戦略とその計画方法について説明します。
計画と設計に関する考慮事項
GKE のマルチクラスタ アーキテクチャは、クラスタのライフサイクル管理戦略の選択で重要な役割を果たします。これらの戦略を検討する前に、クラスタのライフサイクル管理戦略に影響を与える可能性または影響を受ける可能性のある設計上の決定について検討する必要があります。
クラスタのタイプ
クラスタのライフサイクル管理戦略として GKE の自動アップグレードを使用する場合、クラスタのタイプは重要な要素となります。たとえば、リージョン クラスタには複数のコントロール プレーン ノードが存在し、コントロール ノードではコントロール プレーン ノードが 1 つずつ自動的にアップグレードされます。一方、ゾーンクラスタにはコントロール プレーン ノードが 1 つしかありません。GKE の自動アップグレードを使用しない場合、すべての Kubernetes クラスタが自由に使用できるインフラストラクチャであると考えると、クラスタのライフサイクル管理戦略を決定する際に選択するクラスタのタイプは問題にならないかもしれません。次のセクションの GKE マルチクラスタ ライフサイクル管理で説明する戦略は任意のタイプのクラスタに適用できます。
クラスタの配置とフットプリント
クラスタの配置とフットプリントを決定する際は、次の要素を考慮してください。
- クラスタが必要なゾーンとリージョン。
- 必要なクラスタの数とサイズ。
この最初の要素は比較的簡単に解決します。ゾーンとリージョンはビジネスによって決まり、サービスを提供するユーザーはリージョンによって決まります。
通常、クラスタの数とサイズには次のようなメリットとデメリットがあります。
- 少数の大規模クラスタ。リージョン クラスタが提供する冗長性と復元性を使用して、リージョンごとに 1 つまたは 2 つの大きなリージョン クラスタを配置できます。このアプローチの利点は、複数のクラスタを管理する運用上のオーバーヘッドです。ただし、影響領域が大きいため、同時に多数のサービスが影響を受ける可能性があります。
- 多数の小規模クラスタ。サービスが複数のクラスタにまたがっている場合は、サイズの小さいクラスタを数多く作成することで、クラスタの影響領域を小さくすることができます。このアプローチは、有効期間が短いエフェメラル クラスタ（バッチ ワークロードを実行するクラスタなど）にも適しています。このアプローチの欠点は、アップグレードするクラスタが多くなるため、運用上のオーバーヘッドが増加する点です。また、コントロール プレーン ノードの数が増えるため、追加費用が発生する場合もあります。自動化、予測可能なスケジュールと戦略、影響を受けるチームとサービス間での慎重な調整を行うことで、費用を抑えながら運用上のオーバーヘッドを少なくすることができます。
このドキュメントで紹介するアプローチはオプションであり、一方のアプローチをもう一方よりも推奨することは行いません。サービスのカテゴリごとに、両方の設計パターンを選択できる場合もあります。
次の戦略はどちらの設計を選択した場合でも機能します。
キャパシティ プランニング
キャパシティ プランニングを行う場合は、選択したクラスタのライフサイクル戦略を検討することが重要です。キャパシティ プランニングでは、次のサービスの通常の負荷とメンテナンス イベントを考慮する必要があります。
- クラスタ アップグレードなどの計画的なイベント
- クラスタの停止などの想定外のイベント（不適切な構成の push、問題のあるロールアウトなど）
キャパシティ プランニングでは、完全な停止と部分的な停止について考慮する必要があります。計画されたメンテナンス イベントのみを対象にして設計を行うと、すべての分散 Services に必要のないクラスタを 1 つ追加する必要があります。これにより、サービスを低下させることなく、一度に 1 つのクラスタをローテーションから外すことができます。この方法は、N+1 のキャパシティ プランニングともいいます。計画されたメンテナンス イベントと想定外のメンテナンス イベントを対象として設計を行うと、目的のキャパシティを提供するため、すべての分散サービスに 2 つ以上のクラスタを別に用意し、1 つを計画されたイベント用、もう 1 つは計画されたメンテナンスの時間枠に発生した想定外のイベント用に使用する必要があります。この方法は、N+2 のキャパシティ プランニングともいいます。
マルチクラスタ アーキテクチャでは、「ドレイン」と「スピル」という用語がよく使用されます。これらの用語は、アップグレードやメンテナンス時に、クラスタからトラフィックを削除（またはドレイン）し、トラフィックを他のクラスタにリダイレクト（またはスピル）するプロセスを表しています。このプロセスを実現するには、マルチクラスタ Ingress などの負荷分散ソリューションを使用します。ドレインとスピルを適切に使用することは、クラスタのライフサイクル管理戦略で中核となる要素です。キャパシティ プランニングでは、ドレインとスピルを考慮する必要があります。たとえば、単一クラスタがドレインされたときに、スピルされた追加トラフィックの処理に十分なキャパシティが他のクラスタに存在するかどうかを確認する必要があります。また、ゾーンまたはリージョンに十分なキャパシティがあるか、異なるリージョンにトラフィックを送信する必要があるか（リージョンごとに単一のリージョン クラスタを使用している場合）も検討する必要があります。次の図は、あるクラスタから削除され（クラスタのドレインともいいます）、同じ分散サービスを実行している別のクラスタに送信されるトラフィックを示しています。
クラスタと分散サービス
サービスベースのクラスタ設計では、クラスタのアーキテクチャ（数、サイズ、ロケーション）は、クラスタで実行するために必要な Service によって決まります。したがって、クラスタの配置は、分散 Services が必要になる場所によって決まります。分散 Services の配置を決定する場合は、次の点を考慮してください。
- ロケーションの要件。この Service を必要とするリージョンはどれか。
- 重要度。ビジネスに対する Service の可用性はどの程度重要か。
- SLO。サービスにどのようなサービスレベル目標が設定されているか（通常は重要度に基づく）。
- 復元力。サービスに必要な復元力はどのレベルか。クラスタ、ゾーン、さらにリージョンの障害に耐える必要があるか。
クラスタのアップグレードを計画する際は、単一クラスタがドレインされるときに、単一クラスタが影響を及ぼす Service の数を検討する必要があります。また、それぞれの Service を他の適切なクラスタにスピルすることも検討する必要があります。クラスタは、単一テナントかマルチテナントのいずれかになります。単一テナント クラスタは、単一の Service または一連の Service で表されるプロダクトのみを提供します。単一テナント クラスタは、クラスタを他の Service やプロダクトと共有しません。マルチテナント クラスタは多くの Service とプロダクトを実行できます。通常は名前空間にパーティション分割されます。
チームへの影響
クラスタ イベントは、Services だけでなくチームにも影響を与える可能性があります。たとえば、クラスタのアップグレード中に DevOps チームが CI/CD パイプラインのリダイレクトまたは停止が必要になる場合があります。同様に、サポートチームが計画的な停止に対してアラートを受け取る場合があります。複数のチームへの影響を緩和するには、自動化とツールを導入する必要があります。すべてのチームに通知が行われていれば、クラスタまたはクラスタ フリートのアップグレードは不定期でない日常的な作業となります。
タイミング、スケジュール、調整
Kubernetes は新しいマイナー バージョンを四半期ごとにリリースし、最新の 3 つのリリースを保持します。クラスタのアップグレードのタイミングとスケジューリングは慎重に計画する必要があります。これらのアップグレードの実施時期については、サービス オーナー、サービス オペレーター、プラットフォーム管理者の間で合意が必要になります。アップグレードを計画する場合は、次の点を考慮してください。
- どれくらいの頻度でアップグレードするのか。四半期ごとにアップグレードするのか、別のタイムラインでアップグレードするのか。
- いつアップグレードするのか。繁忙期でない四半期の初めに行うのか、業界で一般的な閑散期に行うのか。
- どのような場合にアップグレードを行わないのか。ブラックフライデー、サイバーマンデーのようなピークイベント、注目度の高い会議や業界イベントの開催中など、アップグレードを行わない時期を明確に計画する必要があります。
サービス オーナー、オペレーション チーム、サポートチームに明確に通知する方法を明確にしておくことが重要です。クラスタのアップグレードを行うタイミングと方法を全員に周知し、アップグレードを突然行わないようにする必要があります。そのためには、関係するすべてのチームとの協力が欠かせません。1 つの Service には複数のチームが関係しています。通常、これらのチームは次のカテゴリに分類できます。
- Service のデベロッパー。ビジネス ロジックの作成とコーディングを行います。
- Service オペレーター。Service が安全かつ確実に実行されるようにします。オペレーターは、ポリシー管理者、セキュリティ管理者、ネットワーク管理者、サポートチームなど、複数のチームで構成されている場合があります。
クラスタのアップグレード時に適切なアクションを実行できるように、アップグレード中も全員が情報を交換できるようにしておく必要があります。その方法の 1 つは、停止インシデントを計画する場合と同じ方法でアップグレードを計画することです。たとえば、インシデント コマンダー、チャットルーム、事後対応（影響を受けるユーザーがいない場合でも）を計画します。詳細については、インシデント レスポンスをご覧ください。
GKE クラスタのライフサイクル戦略
このセクションでは、GKE マルチクラスタ アーキテクチャでよく使用される主なクラスタ ライフサイクル管理戦略について説明します。1 つの戦略がすべてのシナリオに適しているとは限りません。さまざまなカテゴリのサービスやビジネス要件に合わせて複数の戦略を選択することもあります。
ローリング アップグレード
次の図は、ローリング アップグレード戦略を示しています。
ロードバランサにより、1 つの GKE クラスタですべてのトラフィックがドレインされ、クラスタのアップグレードが行われます。ドレインされたトラフィックの負荷は別の GKE クラスタにスピルされます。
ローリング アップグレードは、このドキュメントで説明する戦略の中で最もシンプルで、費用対効果に優れた戦略です。old_ver（または現在の本番環境の）バージョンを実行している n 個のクラスタがあります。m 個のクラスタを同時にドレインします（m は n より小さい値です）。その後、クラスタを削除して新しいバージョンのクラスタを作成するか、ドレインされたクラスタをアップグレードします。
クラスタを削除して新しいクラスタを作成するかどうかは、クラスタのサイズや、クラスタを不変のインフラストラクチャとみなすかどうかによって異なります。不変のインフラストラクチャの場合、クラスタのアップグレードを継続的に行うと、不用意な結果が生じる可能性があります。このため、新しいクラスタを作成することで、予期しない構成のずれを避けることができます。
GKE を使用する場合は、1 つのコマンドまたは API 呼び出しで GKE クラスタを作成できます。新しいクラスタ戦略では、全体のクラスタ構成（クラスタ マニフェスト）をクラスタの外部（通常は Git）に保存する必要があります。これにより、新しいクラスタでも同じ構成テンプレートを使用できます。新しいクラスタの場合は、CI / CD パイプラインが正しいクラスタを参照していることを確認します。クラスタが適切に構成されたら、Service の SLO をモニタリングしながら、クラスタにトラフィックを段階的に戻していくことができます。
このプロセスはすべてのクラスタに行われます。キャパシティ プランニングによっては、Service の SLO に違反することなく、複数のクラスタを同時にアップグレードできる場合があります。
復元力よりもシンプルさとコストを重視している場合は、ローリング アップグレード戦略を使用します。この戦略では、すべての分散型サービスの容量が GKE フリートで必要な容量を超えることはありません。
次の図では、マルチクラスタ アーキテクチャで GKE クラスタをアップグレードする場合のタイムラインと Service の容量要件を比較しています。
上の図は、GKE のアップグレード プロセスで、サービスをサポートする容量が必要量を下回ることがないことを示しています。ローテーションでアップグレード対象の GKE クラスタがなくなると、負荷を処理できるように他のクラスタがスケールアップされます。
Blue/Green アップグレード
次の図は、Blue/Green アップグレード戦略を示しています。
上の図では、新しいバージョンを実行する新しい GKE クラスタが追加されています。次に、ロードバランサを使用して新しいクラスタにトラフィックを送信し、送信するトラフィックがなくなるまで古いクラスタの 1 つを段階的にドレインします。ドレインされた古いクラスタは削除できます。残りのクラスタについても同じプロセスを行います。
Blue/Green アップグレード戦略では復元力を強化できます。この戦略はローリング アップグレードと似ていますが、コストは高くなります。唯一の違いは、既存のクラスタをドレインするのではなく、そのバージョンで m 個のクラスタを新しく作成することです（m は n 以下の値です）。新しいクラスタを CI / CD パイプラインに追加し、Service の SLO をモニタリングしながらトラフィックを段階的にスピルします。新しいクラスタがすべてのトラフィックを引き継いだら、古いバージョンのクラスタをドレインして削除します。
クラスタをアップグレードする Blue/Green 戦略は、Service でよく使用される Blue/Green 戦略と似ています。同時に複数の新しいクラスタを作成すると、全体的なコストは増加しますが、フリートのアップグレード時間は短縮できます。追加コストが発生するのは、追加のクラスタを使用したアップグレード期間だけです。最初に新しいクラスタを作成するメリットは、障害が発生した場合にロールバックできることです。新しいクラスタに本番環境のトラフィックを送信する前に、テストを行うこともできます。これらのクラスタが古いバージョンと共存する期間は短いため、追加コストは最小限になります。
コストよりもシンプルさと復元力を重視する場合は、Blue/Green アップグレード戦略を使用します。アップグレード中にクラスタが追加され、GKE フリートに必要な容量を上回ります。
上の図では、新しいクラスタが先に追加され、使用可能な容量が一時的に増加しています。必要な容量を超過しているため、フリートの別のクラスタがドレインされ、フリートから削除されます。古い（完全にドレインされた）クラスタのいずれかを削除すると必要な容量に戻ります。このモデルでは、フリート内のクラスタの数とサイズによってコストが増加する可能性があるため、容量の変化がハイライト表示されています。
カナリア クラスタのアップグレード
カナリア クラスタのアップグレードは、このドキュメントで説明する戦略の中で最も復元力が高く、複雑な戦略です。この戦略では、Service のライフサイクル管理からクラスタのライフサイクルを完全に抽象化することで、リスクを最小限に抑え、サービスの復元力を最大限に高めています。ローリング戦略と Blue/Green アップグレード戦略では、GKE フリート全体を 1 つのバージョンで維持していますが、この戦略では、異なるバージョンを実行する GKE クラスタのフリードを 2 つまたは 3 つ維持します。クラスタをアップグレードするのではなく、1 つのクラスタから他のフリートに段階的に Service を移行します。最も古い GKE フリートがドレインされると（つまり、すべての Service がバージョニングされた次の GKE フリートに移行された場合）、フリートが削除されます。
この戦略では、現在の本番環境用と本番環境の候補用に少なくとも 2 つの GKE フリートを維持する必要があります。3 つ以上の GKE フリートを維持することもできます。フリートを追加することでより柔軟な構成が可能になりますが、コストと運用上のオーバーヘッドは増大します。これらの追加フリートを使用することは、開発環境、ステージング環境、本番環境などの異なる環境にクラスタを配置することとは異なります。本番環境以外のトラフィックで Kubernetes の機能と Service をテストするには、本番環境以外の環境が最適です。
カナリア クラスタのアップグレード戦略では、本番環境で複数の GKE フリート バージョンを維持します。これは、Service でよく使用されるカナリア リリース戦略に似ています。カナリア Service のデプロイでは、Service オーナーは Service の特定のバージョンに関する問題をすぐに特定できます。カナリア クラスタの場合、Service オーナーは、Service が実行されている GKE フリートのバージョンも考慮する必要があります。1 つの分散 Service のバージョンが複数の GKE フリート バージョンで実行される可能性があります。Service の移行は段階的に実施できます。これにより、Service のすべてのトラフィックを新しいバージョン クラスタに送信する前に、新しいフリートで Service の影響を確認できます。
次の図では、GKE クラスタの複数のフリードを管理することで、クラスタのライフサイクルがサービスのライフサイクルから完全に抽象化されることを示しています。
上の図では、古いフリートが完全にドレインされるまで、分散 Service frontend が GKE クラスタの 1 つのフリートから新しいバージョンを実行するフリートに段階的に移行されます。フリートがドレインされたら、そのフリートを削除し、新しいフリートが作成されます。すべてのサービスが次のフリートに移行すると、古いフリートがドレインされ、削除されます。
復元力以外を重視する場合は、カナリア クラスタのアップグレード戦略を使用します。
アップグレード戦略を選択する
以下の図は、Service とビジネスのニーズに基づいて最適な戦略を判断する際に役立ちます。
上の図は、適切なアップグレード戦略の選択に役立つ意思決定ツリーを表しています。
- アップグレードの正確なバージョンとタイミングを完全に制御する必要がない場合は、GKE の自動アップグレード機能を選択できます。
- コストの抑制が最優先であれば、ローリング アップグレード戦略を選択します。
- コストと復元力のバランスが重要な場合は、Blue/Green 戦略を選択します。
- コストより復元力を重視している場合は、カナリア クラスタのアップグレード戦略を選択します。
マルチクラスタ Ingress を使用して GKE クラスタのライフサイクル管理を行う
どの戦略も、アップグレード中にトラフィックを他のクラスタにドレインし、再ルーティングできるかどうかに依存しています。このマルチクラスタ Ingress 機能を提供するソリューションがマルチクラスタ Ingress です。マルチクラスタ Ingress は、Google Cloud がホストする GKE クラスタ用のマルチクラスタ Ingress コントローラで、クラスタ間やリージョン間で共有されたロード バランシングのリソースをデプロイします。マルチクラスタ Ingress は、複数のリージョンの異なるクラスタで実行される分散型サービスにクライアント トラフィックを送信するためのソリューションです。Ingress for GKE と同様に、Cloud Load Balancing を使用してバックエンド サービスにトラフィックを送信します。バックエンド サービスは分散 Service です。バックエンド Service は複数のバックエンド（複数の GKE クラスタで実行されている Kubernetes Service）にトラフィックを送信します。クラスタをまたがるサービス間のトラフィックには、Anthos Service Mesh や Istio などのサービス メッシュ テクノロジーを使用できます。これらは分散 Services 全体で同様の機能を提供します。
GKE マルチクラスタ環境では、前述のクラスタ ライフサイクル管理戦略にマルチクラスタ Ingress を使用し、複数のクラスタへのトラフィックを操作します。Blue/Green 戦略では、マルチクラスタ Ingress for GKE のアップグレードで使用するチュートリアルの手順に沿うこともできます。
次のステップ
- マルチクラスタ Ingress の詳細を確認する。
- クラスタ間で Multi Cluster Ingress をデプロイする方法を確認する。