フリートの概要

フリート(旧称 environ)は、クラスタと他のリソースを論理的に編成するための Google Cloud のコンセプトで、これを使用することによって、マルチクラスタ機能の使用と管理、複数のシステム間での一貫したポリシーの適用が可能になります。フリートは、Google Cloud でエンタープライズ マルチクラスタ機能が効果を発揮するうえで重要な役割を果たします。

このガイドでは、フリートとは何か、コンポーネントにおけるフリートの位置づけ、フリートレベルの機能を活用するためのシステムの設定方法について説明します。また、クラスタとシステム管理の簡素化に役立ついくつかのや、フリートを使ってマルチクラスタ システムを構築して運用する際のベスト プラクティスも紹介します。

このガイドは、複数のクラスタと関連インフラストラクチャを利用するシステム アーキテクト、プラットフォーム オペレータ、サービス オペレータなどの技術リーダーを対象としています。これらのコンセプトは、Google Cloud 上、複数のクラウド プロバイダ間、オンプレミスなど、複数のクラスタを組織で実行しているあらゆる場所で役立ちます。

このガイドは、Kubernetes の基本的なコンセプト(クラスタなど)に精通していることを前提としています。精通していない場合は、Kubernetes の基礎GKE のドキュメントAnthos Service Mesh 用アプリケーションの準備をご覧ください。

フリートを使用する Anthos とコンポーネントの詳細については、Anthos の技術概要Anthos を試すのチュートリアルをご覧ください。ただし、このガイドに沿って操作を行うために Anthos に精通している必要はありません。

はじめに

通常、組織がコンテナやコンテナ オーケストレーション、サービス メッシュなどのクラウドネイティブ テクノロジーを利用していると、単一クラスタを実行しているだけでは不十分になってきます。技術やビジネスの目標を達成するために、組織はさまざまな理由から複数のクラスタをデプロイします。たとえば、本番環境と非本番環境の分離や、層、ロケール、チーム間でサービスの分離を行います。マルチクラスタ アプローチの利点とトレードオフについては、複数クラスタのユースケースをご覧ください。

クラスタの数が増えると、これらのクラスタとそのリソースに対する管理とガバナンスが難しくなります。多くの場合、必要なレベルの制御を実現するために、組織はカスタムツールと運用ポリシーの構築を行います。

Google Cloud には、管理者が複数のクラスタを管理する際に役立つ、フリートというコンセプトがあります。フリートを使用すると、クラスタを論理的にグループ化して正規化できるため、インフラストラクチャの管理が容易になります。フリートは Anthos と GKE の両方のコンテキストで使用できます。フリートを活用できる Anthos コンポーネントと GKE コンポーネントの一覧については、このドキュメント後半のフリート対応コンポーネントのセクションをご覧ください。

フリートを導入することで、組織は個々のクラスタを管理する体制から、クラスタ グループ全体を管理する体制に強化できます。さらに、フリートで必要な正規化は、Google 社内で使用されるようなベスト プラクティスをチームに導入する場合にも役立ちます。比較すると、組織リソースは Google Cloud リソース階層のルートノードで、そのルートノード内でグループ化されたリソースのポリシーと制御に使用されるように、フリートでは、複数のクラスタを管理するためのルートを形成します。

用語

ここでは、フリートに関する重要な用語についていくつか説明します。

フリート対応リソース

フリート対応リソースは、フリートとして論理的にグループ化して管理できる Google Cloud プロジェクトのリソースです。現時点でフリート メンバーになれるのは Kubernetes クラスタだけです。ただし、仮想マシン(VM)インスタンスやその他のリソースは、将来のプラットフォーム リリースでフリートに参加できるようにする予定です。Google Cloud には、リソースをフリート メンバーとして登録するための Connect サービスが用意されています。

フリート ホスト プロジェクト

他の多くの Google Cloud リソースと同様に、フリートの実装は、Google Cloud プロジェクトに基づいています。このプロジェクトは、フリートホスト プロジェクトと呼ばれます。1 つの Cloud プロジェクトに関連付けられるフリートは 1 つ(またはフリートなし)だけです。この制限により、Cloud プロジェクトを使用して、制御されていないリソースや一緒に使用されないリソースの分離を強化します。

フリート対応コンポーネント

次の Anthos と GKE のコンポーネントはすべて、名前空間や ID の同一性など、フリートのコンセプトを活用してクラスタとサービスの操作を簡略化します。各コンポーネントでフリートを使用するための現在の要件または制限については、コンポーネントの要件をご覧ください。

  • Workload Identity プール(Anthos クラスタと GKE クラスタ)
    フリートは、サービス メッシュ内および外部サービスに対してワークロードを一律に認証して認可するために使用できる、共通の Workload Identity プールを提供します。

  • Anthos Service Mesh(Anthos)
    Anthos Service Mesh は、Google Cloud、またはオンプレミス上の信頼性の高いサービス メッシュをモニタリングおよび管理するためのツールセットです。同じフリートに属するリソース(クラスタや VM など)全体でサービス メッシュを形成できます。

  • Anthos Config Management(Anthos と GKE)
    Anthos Config Management は、名前空間、ラベル、アノテーションなど Kubernetes の中核的なコンセプトを活用しているため、中央の Git リポジトリに格納された、システム用の宣言型ポリシーと構成変更をデプロイしてモニタリングできます。Anthos Config Management では、ポリシーと構成がフリート全体で定義されますが、各メンバー リソースにローカルに適用されます。

  • 複数クラスタ Ingress(Anthos)
    複数クラスタ Ingress はフリートを使用して、トラフィックの負荷分散が可能なクラスタとサービス エンドポイントのセットを定義し、低レイテンシで可用性の高いサービスを可能にします。

インフラストラクチャのグループ化

フリートの最初の重要なコンセプトはグループ化です。グループ化とは、関連する フリート対応リソースのうち、どれを使ってフリートを形成するかを選択することです。グループに含めるリソースを判断するには、次の質問に答える必要があります。

  • リソースは相互に関連していますか?
    • サービス間の通信が多いリソースは、フリート内でまとめて管理することで大きなメリットを得られます。
    • 同じデプロイ環境(本番環境など)のリソースは 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 名前空間内の同じ名前のサービスにアクセスできます。

フリート内でのサービスの同一性を示す図
フリート内でのサービスの同一性

外部リソースにアクセスする場合の 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 の同一性

フリート内では、前述した外部 ID の同一性と同じように ID の同一性が使用されます。フリート サービスは、外部サービスに対して一度認証されると、内部でも認証されます。

次の例では、Anthos Service Mesh を使用して、frontendbackend にアクセスできるマルチクラスタ サービス メッシュを作成しています。Anthos Service Mesh とフリートでは、クラスタ B と C の frontend がクラスタ A と B の backend にアクセスできるように指定する必要はありません。代わりに、フリート内の frontend がフリート内の backend にアクセスできることを指定するだけです。このプロパティは認証を簡素化するだけでなく、リソースの境界も柔軟になります。ワークロードは、認証方法に影響を与えずに、クラスタ間で簡単に移動できるようになります。ワークロード ID の同一性と同様、サービス間通信の整合性を確保するにはフリート リソースのガバナンスが不可欠です。

フリート内での ID の同一性を示す図
フリート内での ID の同一性

独占性

フリート対応リソースは、常に 1 つのフリートのメンバーにしかなれません。これは、Google Cloud のツールとコンポーネントによって適用される制限です。この制限により、クラスタを制御する、信頼できる情報源が 1 つだけになります。独占性がないと、非常に単純なコンポーネントであっても使い方が複雑になり、複数のフリートと複数のコンポーネントの交信方法を組織内で把握し構成しなければならなくなります。

強い信頼関係

サービス、ワークロード ID、メッシュ ID の同一性は、フリート メンバー間の強い信頼関係の原理のもとに構築されます。この信頼により、リソースごとに管理せずに(Kubernetes リソースの場合はクラスタごと)、フリートのリソースの管理を強化でき、最終的にはクラスタの境界が重要ではなくなります。

つまり、フリート内では、クラスタが影響範囲の懸念や可用性(制御プレーンと基盤となるインフラストラクチャ両方)、ノイズの多いネイバーなどから保護します。ただし、フリート内のメンバーの管理者がフリートの他のメンバーのサービスの運用に影響を及ぼす可能性があるため、これらはポリシーおよびガバナンスの強力な隔離境界ではありません。

このため、フリート管理者によって信頼されていないリソースは、隔離しておくために専用のフリートに配置することをおすすめします。そうしておけば、必要に応じて個々のサービスをフリートの境界を越えて認証できます。

次のステップ

これらのコンセプトをお使いのシステムに適用する場合は、フリートの要件とベスト プラクティスをご覧ください。