このページでは、フリートの主な用語とコンセプトなど、マルチクラスタ デプロイメントの管理にフリートがどのように役立つかについて詳しく説明します。フリートとは、複数のクラスタと他のリソースを論理的に編成するための Google Cloud のコンセプトで、フリートを使用することによって、マルチクラスタ機能の使用と管理、複数のシステム間での一貫したポリシーの適用が可能になります。フリートは、Google Cloud でエンタープライズ マルチクラスタ機能が効果を発揮するうえで重要な役割を果たします。
このガイドは、複数のクラスタと関連インフラストラクチャを利用するシステム アーキテクト、プラットフォーム オペレータ、サービス オペレータなどの技術リーダーを対象としています。これらのコンセプトは、Google Cloud 上、複数のクラウド プロバイダ間、オンプレミスなど、複数のクラスタを組織で実行しているあらゆる場所で役立ちます。
このガイドは、Kubernetes の基本的なコンセプト（クラスタなど）に精通していることを前提としています。精通していない場合は、Kubernetes の基礎、GKE のドキュメント、Anthos Service Mesh 用アプリケーションの準備をご覧ください。
フリートを使用する Anthos プラットフォームとコンポーネントの詳細については、Anthos の技術概要と Anthos を試すのチュートリアルをご覧ください。ただし、このガイドに沿って操作を行うために Anthos に精通している必要はありません。
用語
ここでは、フリートに関する重要な用語についていくつか説明します。
フリート対応リソース
フリート対応リソースは、フリートとして論理的にグループ化して管理できる Google Cloud プロジェクトのリソースです。現在、Kubernetes クラスタのみがフリート メンバーになります。
フリート ホスト プロジェクト
他の多くの Google Cloud リソースと同様に、フリートの実装は、Google Cloud プロジェクトに基づいています。このプロジェクトは、フリートホスト プロジェクトと呼ばれます。1 つの Cloud プロジェクトに関連付けられるフリートは 1 つ（またはフリートなし）だけです。この制限により、Cloud プロジェクトを使用して、制御されていないリソースや一緒に使用されないリソースの分離を強化します。
インフラストラクチャのグループ化
フリートの最初の重要なコンセプトはグループ化です。グループ化とは、関連する フリート対応リソースのうち、どれを使ってフリートを形成するかを選択することです。グループに含めるリソースを判断するには、次の質問に答える必要があります。
- リソースは相互に関連していますか？
- サービス間の通信が多いリソースは、フリート内でまとめて管理することで大きなメリットを得られます。
- 同じデプロイ環境（本番環境など）のリソースは 1 つのフリートにまとめて管理する必要があります。
- リソースを管理しているのは誰ですか？
- フリートの整合性を確保するために重要になるのが、リソースの統合的（または少なくとも相互に信頼できる）な制御です。
わかりやすい例として、複数の事業部門（LOB）がある組織について考えてみます。この場合、LOB の境界を越えてサービス間で通信することはほとんどありません。LOB ごとにサービスの管理方法も異なります（アップグレード サイクルが LOB ごとに異なるなど）。LOB ごとに管理者が異なる場合さえあります。この場合、LOB ごとにフリートがあると合理的です。本番環境と非本番環境のサービスを分離するために、各 LOB に複数のフリートを導入することもできます。
フリートの他のコンセプトについては以降のセクションで説明しますが、組織に固有のニーズに合わせて複数のフリートを作成する理由は、これに限るものではありません。
同一性
フリートの重要なコンセプトの 1 つが同一性です。同一性とは、異なるクラスタで同じ名前を持つ名前空間など、一部の Kubernetes オブジェクトが同じものとして扱われることを指します。この正規化は、フリート リソースの管理をやりやすくすることを目的としています。また、名前空間、サービス、ID の設定方法に関する強力なガイダンスにもなります。一方で、Environ をすでに実装している多くの組織のやり方も参考にしています。
名前空間の同一性
フリートにおける基本的な同一性が名前空間の同一性です。異なるクラスタで同じ名前を持つ名前空間は、多くのコンポーネントで同一と見なされます。このプロパティについては、名前空間のインスタンス化がフリート リソースのサブセット内でのみ起こり得る場合でも、名前空間はフリート全体で論理的に定義されるという点に注目する必要があります。
次の backend 名前空間の例を考えてみましょう。この名前空間はクラスタ A と B でのみインスタンス化されますが、クラスタ C で暗黙的に予約されています（必要に応じて、backend 名前空間内のサービスをクラスタ C にもスケジュールできます）。つまり、名前空間はクラスタごとではなく、フリート全体に割り当てられます。したがって、名前空間の同一性では、フリート全体で一貫した名前空間を所有している必要があります。
サービスの同一性
Anthos Service Mesh とマルチクラスタ Ingress は、名前空間内のサービスの同一性のコンセプトを使用します。これは、名前空間の同一性と同様、名前空間とサービス名が同じサービスが同一サービスとみなされることを意味します。
Anthos Service Mesh の場合、サービス エンドポイントをメッシュ全体でマージできます。マルチクラスタ Ingress では、MultiClusterService（MCS）リソースによってエンドポイントのより明示的なマージが行われます。命名に関しても同様の方法をおすすめします。このため、同じ名前空間内の名前が同じサービスは実際に同じものにする必要があります。
次の例では、インターネット トラフィックがクラスタ B と C の両方に存在する frontend 名前空間内の同じ名前のサービス全体に負荷分散されています。同様に、フリート内のサービス メッシュ プロパティを使用して、frontend 名前空間のサービスは、クラスタ A と C に存在する auth Namespace の同じ名前のサービスにアクセスできます。
外部リソースにアクセスする場合の ID の同一性
フリート内のサービスは、Google Cloud サービス、オブジェクト ストアなどの外部リソースに下り（外向き）のアクセスを行うときに、共通の ID を使用できます。この共通 ID によって、外部リソースへのアクセスを、クラスタ単位ではなくまとめてフリート内のサービスに付与できます。
この点についてより具体的に理解するため、次の例を考えてみましょう。クラスタ A、B、C はフリート内で共通の ID に登録されます。backend 名前空間のサービスが Google Cloud リソースにアクセスすると、その ID は back という共通の Google Cloud サービス アカウントにマッピングされます。Google Cloud サービス アカウント back は、Cloud Storage から Cloud SQL まで、任意の数のマネージド サービスで認証できます。クラスタなどの新しいフリート リソースが backend 名前空間に追加されると、自動的にワークロード ID の同一性プロパティが継承されます。
ID の同一性により、フリート内のすべてのリソースが信頼され、適切に管理されていることが重要です。前の例に戻ると、クラスタ C が別の信頼されていないチームによって所有されている場合、このチームでも backend 名前空間を作成し、クラスタ A または B の backend であるかのようにマネージド サービスにアクセスできます。
フリート内の ID の同一性
フリート内では、前述した外部 ID の同一性と同じように ID の同一性が使用されます。フリート サービスは、外部サービスに対して一度認証されると、内部でも認証されます。
次の例では、Anthos Service Mesh を使用して、frontend が backend にアクセスできるマルチクラスタ サービス メッシュを作成しています。Anthos Service Mesh とフリートで、クラスタ B と C の frontend がクラスタ A と B の backend にアクセスできることを指定する必要はありません。代わりに、フリート内の frontend がフリート内の backend にアクセスできることを指定するだけです。このプロパティは認証を簡素化するだけでなく、リソースの境界も柔軟になります。ワークロードは、認証方法に影響を与えずに、クラスタ間で簡単に移動できるようになります。ワークロード ID の同一性と同様、サービス間通信の整合性を確保するにはフリート リソースのガバナンスが不可欠です。
独占性
フリート対応リソースは、常に 1 つのフリートのメンバーにしかなれません。これは、Google Cloud のツールとコンポーネントによって適用される制限です。この制限により、クラスタを制御する、信頼できる情報源が 1 つだけになります。独占性がないと、非常に単純なコンポーネントであっても使い方が複雑になり、複数のフリートと複数のコンポーネントの交信方法を組織内で把握し構成しなければならなくなります。
強い信頼関係
サービス、ワークロード ID、メッシュ ID の同一性は、フリート メンバー間の強い信頼関係の原理のもとに構築されます。この信頼により、リソースごとに管理せずに（Kubernetes リソースの場合はクラスタごと）、フリートのリソースの管理を強化でき、最終的にはクラスタの境界が重要ではなくなります。
つまり、フリート内では、クラスタが影響範囲の懸念や可用性（制御プレーンと基盤となるインフラストラクチャ両方）、ノイズの多いネイバーなどから保護します。ただし、フリート内のメンバーの管理者がフリートの他のメンバーのサービスの運用に影響を及ぼす可能性があるため、これらはポリシーおよびガバナンスの強力な隔離境界ではありません。
このため、フリート管理者によって信頼されていないクラスタは、隔離しておくために専用のフリートに配置することをおすすめします。そうしておけば、必要に応じて個々のサービスをフリートの境界を越えて認証できます。
フリート対応コンポーネント
次の Anthos と GKE のコンポーネントはすべて、名前空間や ID の同一性など、フリートのコンセプトを活用してクラスタとサービスの操作を簡略化します。各コンポーネントでフリートを使用するための現在の要件または制限については、コンポーネントの要件をご覧ください。
Workload Identity プール
フリートは、サービス メッシュ内および外部サービスに対してワークロードを均一に認証および認可するために使用できる共通のWorkload Identity プールを提供します。Anthos Service Mesh
Anthos Service Mesh は、Google Cloud 上で信頼性の高いサービス メッシュをオンプレミス、およびその他のサポートされている環境でモニタリングおよび管理するためのツールセットです。同じフリートの一部であるクラスタ間でサービス メッシュを形成できます。Anthos Config Management
Anthos Config Management は、名前空間、ラベル、アノテーションなど Kubernetes の中核的なコンセプトを活用しているため、中央の Git リポジトリに格納された、システム用の宣言型ポリシーと構成変更をデプロイしてモニタリングできます。Anthos Config Management では、ポリシーと構成がフリート全体で定義されますが、各メンバー リソースにローカルに適用されます。マルチクラスタ Ingress
マルチクラスタ Ingress はフリートを使用して、トラフィックの負荷分散が可能なクラスタとサービス エンドポイントのセットを定義し、低レイテンシで可用性の高いサービスを可能にします。Cloud Run for Anthos
Cloud Run for Anthos は、Google が管理するサポート対象の Knative デベロッパー プラットフォームで、基盤となるインフラストラクチャの複雑さを解消し、Anthos フリート内のクラスタ間でアプリとサービスを簡単にビルド、デプロイ、管理できます。
次のステップ
- 複数クラスタを使用するタイミングについて詳しくは、マルチクラスタのユースケースをご覧ください。
- これらのコンセプトをお使いのシステムに適用する場合は、フリートの要件とベスト プラクティスをご覧ください。