このページでは、フリートがマルチクラスタ デプロイの管理にどのように役立つかについて詳しく説明します。フリートに関する重要な用語とコンセプトについても説明します。フリートとは、複数のクラスタと他のリソースを論理的に編成するための Google Cloud のコンセプトです。フリートを使用することによって、マルチクラスタ機能の使用と管理、複数のシステム間での一貫したポリシーの適用が可能になります。フリートは、Google Cloud でエンタープライズ マルチクラスタ機能が効果を発揮するうえで重要な役割を果たします。
このガイドは、複数のクラスタと関連インフラストラクチャを利用するシステム アーキテクト、プラットフォーム オペレータ、サービス オペレータなどの技術リーダーを対象としています。これらのコンセプトは、Google Cloud 上、複数のクラウド プロバイダ間、オンプレミスなど、複数のクラスタを組織で実行しているあらゆる場所で役立ちます。
このガイドは、Kubernetes の基本的なコンセプト（クラスタや名前空間など）に精通していることを前提としています。精通されていない場合は、Kubernetes の基礎、GKE のドキュメント、Cloud Service Mesh 用アプリケーションの準備をご覧ください。
フリートを使用する GKE Enterprise プラットフォームとコンポーネントの詳細については、GKE Enterprise の技術概要と GKE Enterprise の使い方チュートリアルをご覧ください。ただし、このガイドに沿って操作を行うために GKE Enterprise に精通している必要はありません。
用語
ここでは、フリートに関する重要な用語についていくつか説明します。
フリート対応リソース
フリート対応リソースは、フリートとして論理的にグループ化して管理できる Google Cloud プロジェクトのリソースです。現在、フリート メンバーとして設定できるのは Kubernetes クラスタのみです。
フリート ホスト プロジェクト
他の多くの Google Cloud リソースと同様に、フリートの実装は、Google Cloud プロジェクトに基づいています。このプロジェクトは、フリートホスト プロジェクトと呼ばれます。1 つの Google Cloud プロジェクトに関連付けられるのは、1 つのフリート（またはフリートなし）だけです。この制限により、Google Cloud プロジェクトを使用して、制御されていないリソースや一緒に使用されないリソースの分離を強化します。
インフラストラクチャのグループ化
フリートの最初の重要なコンセプトはグループ化です。グループ化とは、関連する フリート対応リソースのうち、どれを使ってフリートを形成するかを選択することです。グループに含めるリソースを判断するには、次の質問に答える必要があります。
- リソースは相互に関連していますか？
- サービス間の通信が多いリソースは、フリート内でまとめて管理することで大きなメリットを得られます。
- 同じデプロイ環境（本番環境など）のリソースは 1 つのフリートにまとめて管理する必要があります。
- リソースを管理しているのは誰ですか？
- フリートの整合性を確保するために重要になるのが、リソースの統合的（または少なくとも相互に信頼できる）な制御です。
わかりやすい例として、複数の事業部門（LOB）がある組織について考えてみます。この場合、LOB の境界を越えてサービス間で通信することはほとんどありません。LOB ごとにサービスの管理方法も異なります（アップグレード サイクルが LOB ごとに異なるなど）。LOB ごとに管理者が異なる場合さえあります。この場合、LOB ごとにフリートがあると合理的です。本番環境と非本番環境のサービスを分離するために、各 LOB に複数のフリートを導入することもできます。
フリートの他のコンセプトについては以降のセクションで説明しますが、組織に固有のニーズに合わせて複数のフリートを作成する理由は、これに限るものではありません。
同一性
フリートの重要なコンセプトの 1 つが同一性です。つまり、特定のフリート対応機能を使用する場合、異なるクラスタで同じ名前を持つ Namespace など、一部の Kubernetes オブジェクトは同じものとして扱われます。この正規化は、フリート リソースの管理を容易にすることを目的としています。同一性を利用している機能を使用する場合は、この同一性の仮定が、Namespace、サービス、ID を設定する方法に関する強力なガイダンスになります。一方で、Environ をすでに実装している多くの組織のやり方も参考にしています。
次の表に示すように、同一性の種類によって利点が異なります。
| 同一性プロパティ | 次のことが可能になります。 |
|---|---|
| Namespace は、複数のクラスタで同じと見なされます。 |
|
| Namespace とサービス名の組み合わせは、複数のクラスタで同じと見なされます。同じ Namespace 内の同じ名前のサービスは、同じラベルセレクタを使用します。 |
|
| Namespace とサービス アカウント（ID）の組み合わせは、複数のクラスタで同じと見なされます。 |
|
このように、フリート機能によって同一性の内容が異なります。一部の特徴量では、同一性を使用しません。詳しくは、同一性を使用する機能をご覧ください。フリート全体の同一性を考慮せずに使用できる機能や、慎重な計画が必要な機能について説明しています。
名前空間の同一性
フリートにおける基本的な同一性が名前空間の同一性です。異なるクラスタで同じ名前を持つ Namespace は、多くのフリート機能で同一と見なされます。このプロパティについては、名前空間のインスタンス化がフリート リソースのサブセット内でのみ起こり得る場合でも、名前空間はフリート全体で論理的に定義されるという点に注目する必要があります。
次の backend 名前空間の例を考えてみましょう。この名前空間はクラスタ A と B でのみインスタンス化されますが、クラスタ C で暗黙的に予約されています（必要に応じて、backend 名前空間内のサービスをクラスタ C にもスケジュールできます）。つまり、名前空間はクラスタごとではなく、フリート全体に割り当てられます。したがって、名前空間の同一性では、フリート全体で一貫した名前空間を所有している必要があります。
サービスの同一性
Cloud Service Mesh とマルチクラスタ Ingress は、名前空間内のサービスの同一性のコンセプトを使用します。これは、名前空間の同一性と同様、名前空間とサービス名が同じサービスが同一サービスとみなされることを意味します。
Cloud Service Mesh の場合は、サービス エンドポイントをメッシュ全体でマージできます。マルチクラスタ Ingress では、MultiClusterService（MCS）リソースによってエンドポイントのより明示的なマージが行われます。命名に関しても同様の方法をおすすめします。このため、同じ名前空間内の名前が同じサービスは実際に同じものにする必要があります。
次の例では、インターネット トラフィックがクラスタ B と C の両方に存在する frontend 名前空間内の同じ名前のサービス全体に負荷分散されています。同様に、フリート内のサービス メッシュ プロパティを使用して、frontend 名前空間のサービスは、クラスタ A と C に存在する auth Namespace の同じ名前のサービスにアクセスできます。
外部リソースにアクセスする場合の ID の同一性
フリート Workload Identity 連携を使用すると、フリート内のサービスは、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 の同一性が使用されます。フリート サービスは、外部サービスに対して一度認証されると、内部でも認証されます。
次の例では、Cloud Service Mesh を使用して、frontend が backend にアクセスできるマルチクラスタ サービス メッシュを作成しています。Cloud Service Mesh とフリートで、クラスタ B と C の frontend がクラスタ A と B の backend にアクセスできることを指定する必要はありません。代わりに、フリート内の frontend がフリート内の backend にアクセスできることを指定するのみです。このプロパティは認証を簡素化するだけでなく、リソースの境界も柔軟になります。ワークロードは、認証方法に影響を与えずに、クラスタ間で簡単に移動できるようになります。ワークロード ID の同一性と同様、サービス間通信の整合性を確保するにはフリート リソースのガバナンスが不可欠です。
同一性を使用する機能
多くのフリート機能は同一性にまったく依存しておらず、フリート全体でなんらかの同一性を想定するかどうかを検討することなく、有効にして使用できます。他の機能（Config Sync や Policy Controller など）では、同一性を使用できます。たとえば、単一の信頼できる情報源から構成するために、複数のフリート メンバー クラスタにまたがる Namespace を選択する場合などです。ただし、すべてのユースケースで同一性を使用する必要はありません。最後に、マルチクラスタ Ingress やフリート全体の Workload Identity 連携などの機能は、クラスタ間で常に何らかの形の同一性を前提としており、ニーズや既存のワークロードに応じて慎重に導入する必要があります。
フリート機能によっては（フリート Workload Identity 連携など）、フリート全体が、使用される同一性の前提条件を満たしている必要があります。チーム管理などの他の機能を使用すると、名前空間またはチームスコープレベルで同等性を段階的に有効にできます。
次の表に、このセクションで説明する同一性のコンセプトの 1 つ以上をrequire機能を示します。
| 特徴 | 同等性の段階的な導入をサポート | Namespace の同一性によって異なる | サービスの同一性によって異なる | 同一性による |
|---|---|---|---|---|
| フリート | なし | × | いいえ | × |
| Binary Authorization | なし | × | いいえ | × |
| ノード間の透過的暗号化 | なし | × | いいえ | × |
| 完全修飾ドメイン名ベースのネットワーク ポリシー | なし | × | いいえ | × |
| Connect Gateway | なし | × | いいえ | × |
| Config Sync | なし | × | いいえ | × |
| Policy Controller | なし | × | いいえ | × |
| GKE Security Posture | なし | × | いいえ | × |
| Advanced Vulnerability Insights | なし | × | いいえ | × |
| コンプライアンス体制 | なし | × | いいえ | × |
| ロールアウト シーケンス | なし | × | いいえ | × |
| チーム管理 | ○ | はい | ○ | × |
| マルチクラスタ Ingress | ○ | はい | はい | ○ |
| マルチクラスタ サービス | ○ | はい | はい | ○ |
| フリートの Workload Identity 連携 | × | ○ | はい | ○ |
| Cloud Service Mesh | × | ○ | はい | ○ |
独占性
フリート対応リソースは、常に 1 つのフリートのメンバーにしかなれません。これは、Google Cloud のツールとコンポーネントによって適用される制限です。この制限により、クラスタを制御する、信頼できる情報源が 1 つだけになります。独占性がないと、非常に単純なコンポーネントであっても使い方が複雑になり、複数のフリートと複数のコンポーネントの交信方法を組織内で把握し構成しなければならなくなります。
強い信頼関係
サービス、ワークロード ID、メッシュ ID の同一性は、フリート メンバー間の強い信頼関係の原理のもとに構築されます。この信頼により、リソースごとに管理せずに（Kubernetes リソースの場合はクラスタごと）、フリートのリソースの管理を強化でき、最終的にはクラスタの境界が重要ではなくなります。
つまり、フリート内では、クラスタが影響範囲の懸念や可用性（制御プレーンと基盤となるインフラストラクチャ両方）、ノイズの多いネイバーなどから保護します。ただし、フリート内のメンバーの管理者がフリートの他のメンバーのサービスの運用に影響を及ぼす可能性があるため、これらはポリシーおよびガバナンスの強力な隔離境界ではありません。
このため、フリート管理者によって信頼されていないクラスタは、隔離しておくために専用のフリートに配置することをおすすめします。そうしておけば、必要に応じて個々のサービスをフリートの境界を越えて認証できます。
チームスコープ
チームスコープは、フリートをクラスタのグループに細分するためのメカニズムです。これにより、特定のアプリケーション チームに割り当てられたフリート対応リソースを定義できます。ユースケースに応じて、個別のフリート メンバー クラスタをチームに関連付けない、または 1 つのチーム、あるいは複数のチームに関連付けることができます。これにより、複数のチームでクラスタを共有できます。チームスコープを使用して、フリート全体でクラスタ アップグレードのロールアウトを順序付けすることもできます。ただし、各クラスタを 1 つのチームにのみ関連付ける必要があります。
スコープには、明示的に定義されたフリート名前空間を関連付けることができます。ここで、名前空間はスコープ全体で同じと見なされます。これにより、フリート単体で実現されるデフォルトの 名前空間の同一性よりも、名前空間をより詳細に制御できます。
フリート対応コンポーネント
次の GKE Enterprise と GKE のコンポーネントはすべて、名前空間や ID の同一性など、フリートのコンセプトを活用してクラスタとサービスの操作を簡略化します。各コンポーネントでフリートを使用するための現在の要件または制限については、コンポーネントの要件をご覧ください。
Workload Identity プール
フリートは、サービス メッシュ内および外部サービスに対してワークロードを均一に認証および認可するために使用できる共通のWorkload Identity プールを提供します。Cloud Service Mesh
Cloud Service Mesh は、Google Cloud、オンプレミス、およびその他のサポートされている環境で、信頼性の高いサービス メッシュをモニタリングおよび管理するためのツールセットです。同じフリートを構成する複数のクラスタに存在するサービス メッシュを形成できます。Config Sync
Config Sync では、名前空間、ラベル、アノテーションなどのコアとなる Kubernetes のコンセプトを活用して、Git リポジトリなどの信頼できる一元的な情報源に保存されたシステム用の宣言型構成パッケージをデプロイしてモニタリングできます。Config Sync では、構成がフリート全体で定義されますが、各メンバー リソースにおいてローカルに適用、および施行することができます。Policy Controller
Policy Controller を使用すると、Kubernetes クラスタに宣言型ポリシーを適用および施行することができます。ポリシーはガードレールとして機能し、クラスタとフリートのベスト プラクティス、セキュリティ、コンプライアンス管理に役立ちます。マルチクラスタ Ingress
マルチクラスタ Ingress はフリートを使用して、トラフィックのロード バランシングが可能なクラスタとサービス エンドポイントのセットを定義し、低レイテンシで可用性の高いサービスを実現します。Knative serving
Knative serving は、Google が管理するサポート対象の Knative デベロッパー プラットフォームであり、基盤となるインフラストラクチャの複雑さを解消し、フリート内のクラスタ間でアプリとサービスを簡単に構築、デプロイ、管理できます。
次のステップ
- 技術的およびビジネス上のニーズを満たすために複数のクラスタを使用する場合の詳細については、マルチクラスタのユースケースをご覧ください。
- これらのコンセプトをお使いのシステムに適用する場合は、フリート リソースを計画するをご覧ください。