フリートの機能を計画する

フリートの計画では、フリート対応の機能の使用を決定することが重要です。特に、既存のクラスタと本番環境ワークロードを扱っている場合は、既存のアプリケーションへの負担やリスクを最小限に抑えながらすぐに導入できるフリート機能を特定し、より段階的な導入や慎重な導入が必要な他の機能を計画することをおすすめします。このガイドでは、フリートを使用して有効になるさまざまな種類の機能とその要件について説明し、機能の導入に関する実用的なガイダンスを提供します。

このガイドで説明する機能の多くは、GKE Enterprise の一部としてのみ利用できます。詳細については、GKE Enterprise のデプロイ オプションをご覧ください。

このガイドは、組織でフリートを使用したい Cloud アーキテクトを対象としています。このガイドを読む前に、フリート管理の概要とフリート リソースの計画について理解しておいてください。これらのガイドでは、新規または既存のクラスタをフリートに編成する方法を説明しています。

機能を導入する際のベスト プラクティス

フリート機能（基本的なフリート オブザーバビリティを除く）はすべてオプトインです。つまり、使用することを指定する必要があります。既存のクラスタをフリートに追加しても、構成は変更されません。フリート機能を使用する場合、リスクを最小限に抑えてすぐに有効にできる機能もありますが、慎重に取り組む必要のある機能もあります。このセクションでは、機能の導入に関するガイダンスを紹介します。

特に既存のクラスタとワークロードでは、機能で同一性が必要になる箇所に特に注意する必要があります。この機能は、フリートのコンセプトです。異なるクラスタで同じ名前の Namespace、Service、ID は、この機能によって同じものとして想定されます。同一性の原則と、それを利用する機能の詳細については、フリートの仕組みをご覧ください。

低リスク機能のオンボーディング

次の「アンビエント」機能は、いかなる種類の同一性も想定せず、クラスタに影響を与えません。これらの機能は、既存のワークロードやクラスタでも安全に使用できるため、フリート全体で強化されたオブザーバビリティとセキュリティ分析情報のメリットをすぐに享受できます。また、フリート メンバーシップに基づいてクラスタのアップグレードの順序を管理することもできます。

次の機能は個々のクラスタにインストールされます。これらの機能は、複数のクラスタにわたってリソースを構成または指定する場合にのみ、同一性を前提とすることができます。つまり、既存のワークロードを含むクラスタでこれらの機能を安全に有効にできます。これらのオプションのセレクタを使用する構成を作成または使用する場合にのみ、同一性を考慮する必要があります。

高度なマルチクラスタ機能のオンボーディング

次の機能により、複数のクラスタを管理する運用上のオーバーヘッドを削減できます。ただし、これらの機能はすべて、動作するために 1 つ以上の同一性を前提としており、有効または無効にすると、複数のクラスタとそのワークロードに影響する可能性があるため、慎重に使用する必要があります。

たとえば、異なるクラスタとアプリケーション（デフォルトの Namespace を含む）に同じ名前の既存の Kubernetes Namespace がある場合、これを前提とする機能を有効にする前に、それらを同じ Namespace として扱うかどうかを確認する必要があります。同様に、Cloud Service Mesh を使用する場合は、クラスタ間でマージされるサービス エンドポイントを把握し、これが望ましい動作であることを確認する必要があります。

Namespace の同一性の監査

アプリケーションをよく理解している場合は、2 つの「異なる」アプリケーションが同じ Namespace を使用していないことを確認するだけで、Namespace を監査できます。特に、デフォルトの Namespace をアドホックに使用している点に注意してください。たとえば、あるクラスタに default という Namespace があり、別のクラスタに default という Namespace がありときに、それらが異なる目的で使用されている限り、一方の名前を変更する必要があります。

より厳格なアプローチについては、以下を試してください。フリートの異なるクラスタに同じ名前の Namespace が存在する場合は、次の点を確認します。

  • 各クラスタに同じ RBAC ルールが存在し、プリンシパルの Namespace が Namespace へのアクセスを許可している。
  • Pod で使用される画像のセット（ハッシュ / タグは除く）が同じである。
  • Pod で使用される Secret のセットが同じである。

これらがすべて true の場合、Namespace は「同じ」として扱うのに十分な類似性があります。

Namespace が十分に類似していない場合は、アプリを新しい Namespace に移行できます。Namespace の同一性の前提に問題がなければ、それを利用する機能をオンにできます。

サービスの同一性を監査する

Cloud Service Mesh を採用してマイクロサービス ベースのアプリケーションを管理する場合は、サービスの同一性も考慮する必要があります。つまり、Namespace とサービス名の組み合わせに関係なく、Cloud Service Mesh は次の点でこれらを同じ論理サービスとして扱います。

  • ID（特に Cloud Service Mesh のセキュリティの場合）: namespace1/service1 が操作を実行する権限を持っている場合、任意のクラスタのその ID を持つワークロードは認可されます。
  • トラフィック管理: デフォルトでは、トラフィックは任意のクラスタ内の namespace1/service1 サービス間でロードバランスされます。
  • オブザーバビリティ: すべてのクラスタの namespace1/service1 の指標が集約されます。

新しいクラスタとアプリケーションで Cloud Service Mesh を有効にする場合は、メッシュ全体で一意の Namespace 名 / サービス名の組み合わせを予約することをおすすめします。既存のアプリケーションの場合は、サービスを監査して、クラスタ間で同じ Namespace と名前を持つサービスが、ID、トラフィック管理、オブザーバビリティの観点から同じサービスとして扱われることを確認します。

特に、論理的に異なるサービス（Payment Accounting API と Payment Transaction API など）で同じ [namespace, name] ペア（payments/api など）を使用しないようにしてください。サービス メッシュに配置されると、同じサービスとして扱われます。このコンセプトの結合は、リージョンの境界を越えて行われることに注意してください。また、サービスの機能に影響が生じる可能性があります。

マルチクラスタ Ingress とマルチクラスタ Gateway は、複数のクラスタにまたがるサービスにトラフィックを転送するときに、Service の Namespace / 名前の同一性も想定します。ただし、これはクラスタの外部に公開されている Service に限られます。

Workload Identity を検討する

フリート全体の Workload Identity 連携は、フリートの強力な機能です。これにより、GKE 用 Workload Identity 連携で提供される機能を拡張し、クラスタ内のワークロードを Google に認証させることができます。Google Cloud のサービス アカウント キーをダウンロードし、手動でローテーションして管理する必要はありません。その代わり、ワークロードはクラスタによって生成される有効期間の短いトークンを使用して認証されます。各クラスタは、特別な Workload Identity プールに ID プロバイダとして追加されます。特定の Namespace で実行されているワークロードは、クラスタ間で同じ Identity and Access Management ID を共有できます。

通常の GKE 用 Workload Identity 連携では、プロジェクト全体の ID プールが使用されますが、フリート全体の Workload Identity 連携では、フリート全体の Workload Identity プールが使用されます。クラスタが異なるプロジェクトにある場合でも、フリート全体の ID の暗黙の同一性、Namespace とサービスの同一性が維持されます。これにより、プロジェクト間でアプリケーションの認証を簡単に設定できます。ただし、マルチプロジェクト フリートで使用する場合、特にフリート ホスト プロジェクトにフリート クラスタとフリート以外のクラスタが混在している場合は、通常の Workload Identity Federation for GKE のアクセス制御に加えて、アクセス制御に関する考慮事項が生じる可能性があります。

フリート Workload Identity 連携の詳細と、これを使用して Google Cloud サービスにアクセスする方法については、フリート Workload Identity を使用するをご覧ください。フリート Workload Identity 連携でリスクを最小限に抑える方法と例については、フリート Workload Identity の使用に関するベスト プラクティスをご覧ください。

フリートレベルのデフォルト

GKE Enterprise では、Cloud Service Mesh、Config Sync、Policy Controller などの特定のエンタープライズ機能にフリートレベルのデフォルトを設定できます。これにより、各クラスタを個別に構成しなくても、これらの機能を使用するようにクラスタを設定できます。たとえば、管理者はフリートで Policy Controller を有効にして、フリートレベルでデフォルト ポリシーを設定できます。これにより、必要なエージェントが新しいフリート メンバー クラスタにインストールされ、デフォルト ポリシーが適用されます。

ただし、これらのデフォルトは、クラスタの作成時にフリートに追加する新しいクラスタにのみ自動的に適用されます。既存のクラスタとそのワークロードは影響を受けません。フリートにすでに追加されている場合でも、機能のデフォルトを設定した後にクラスタを追加した場合でも影響はありません。つまり、準備ができていないクラスタで機能を有効にしたり構成することなく、フリートレベルのデフォルトを安全に設定できます。後で既存のクラスタにデフォルト設定を適用することもできます。

機能の要件

組織で使用するフリート機能に基づいてフリートを実装する場合は、考慮すべきいくつかの制限事項があります。たとえば、一部の機能はフリート ホスト プロジェクトに含まれていないクラスタでの作業をサポートしていません。また、一部の機能は Google Cloud 外のクラスタではサポートされていません。

次の表に、各コンポーネントの現在の要件と制限事項を示します。また、以降のセクションでは、具体的なガイドラインについても説明します。

機能
 クラスタの種類
 プロジェクト要件
 VPC の要件
Config Sync GKE Enterprise でサポートされるすべてのクラスタ なし なし
Policy Controller GKE Enterprise でサポートされるすべてのクラスタ なし なし
Cloud Service Mesh 制限事項をご覧ください。 Cloud Service Mesh で使用されるすべてのクラスタは、同じプロジェクト内に存在し、同じフリートに登録されている必要があります。詳細については、Cloud Service Mesh のフリートの要件をご覧ください。 GKE クラスタは同じ VPC ネットワーク内にある必要があります。
マルチクラスタ サービス（MCS） Google Cloud 上の GKE なし 共有 VPC での MCS をご覧ください。
マルチクラスタ Ingress とマルチクラスタ Gateway Google Cloud 上の GKE Ingress / Gateway リソース、GKE クラスタ、フリートは同じプロジェクト内に存在する必要があります。 Ingress / Gateway リソースと GKE クラスタは同じ VPC ネットワーク内に存在する必要があります。
Workload Identity プール Google Cloud 上の GKE と VMware 上の Google Distributed Cloud 向けに最適化されています。他の Kubernetes クラスタはサポートされていますが、追加の設定作業が必要です。 なし なし
Binary Authorization Google Cloud 上の GKE、VMware 上の Google Distributed Cloud、ベアメタル上の Google Distributed Cloud なし なし
Advanced Vulnerability Insights Google Cloud 上の GKE なし なし
セキュリティ ポスチャー Google Cloud 上の GKE なし なし
コンプライアンス ポスチャー Google Cloud 上の GKE なし なし
フリートのリソース使用率の指標 Google Cloud 上の GKE なし なし
フリートのロギング すべて なし なし
Connect Gateway すべて なし なし
フリートチーム管理 すべて なし なし
Pod FQDN ネットワーク ポリシー Google Cloud 上の GKE なし なし
ノード間の透過的暗号化 Google Cloud 上の GKE なし なし
Config Controller 該当なし なし なし
ロールアウト シーケンス Google Cloud 上の GKE なし なし

Virtual Private Cloud の要件を考慮する

前の表に示したように、クラスタが単一の Virtual Private Cloud（VPC）ネットワークに存在する必要がある Cloud Service Mesh などの機能を使用する場合は、VPC ごとにフリートを作成しなければなりません。これらの機能を使用しない場合は、複数の VPC を 1 つのフリートに配置できます。

たとえば、組織に複数のプロジェクトがあり、それぞれに独自のデフォルト VPC があるというパターンがよくあります。これらの間にピアリング接続が存在している可能性があります。単一 VPC の要件がある機能を使用していない場合は、これらをすべて 1 つのフリートに配置できます。別の一般的なパターンは、複数の VPC を使用する「ハブアンドスポーク」トポロジです。単一 VPC の要件がある機能を使用していない場合は、すべての VPC のクラスタを 1 つのフリートに配置できます。このガイドラインに従うと、クラスタが 1 つしかないフリートになる場合があります。その場合は、VPC 制限のある機能の使用を中止し、マルチプロジェクト フリートを作成する必要がある場合があります。また、必要に応じて、アーキテクチャを見直し、ワークロードを移行する必要があります。

マルチクラスタ ネットワーキングの要件

トラフィック管理にマルチクラスタ Ingress またはマルチクラスタ Gateway を使用する場合、いずれの場合もプロジェクトにまたがって Gateway コントローラを使用できないことに注意してください。つまり、これらの機能で使用するすべてのクラスタは、同じプロジェクトとフリートに存在する必要があります。マルチプロジェクト クラスタを含むフリートを作成する必要がある場合は、代わりに単一クラスタ Gateway を使用し、他の方法（DNS の使用など）で適切な Gateway にトラフィックを転送できます。これらの機能を使用するクラスタも同じ VPC ネットワークに存在する必要があります。

次のステップ