フリート リソースを計画する

フリートの管理の概要で説明したように、フリートは、Kubernetes クラスタを大規模に管理、構成、保護するためのグループ化メカニズムです。フリートは、マルチクラスタ環境で繰り返しオペレーションを実行する必要性を排除し、大規模なクラスタ グループ全体で一貫性と包括的なオブザーバビリティを提供する強力なツールです。多くの GKE Enterprise 機能は、フリート経由でのみ使用できます。

フリートの作成に使用するグループ化戦略は、組織の技術的ニーズとビジネスニーズによって異なります。たとえば、ある組織では、クラスタ内で実行されているアプリケーションの種類に基づいてクラスタをグループ化しますが、別の組織では、地域、環境、またはその他の関連する要因に基づいてクラスタをグループ化します。他の条件がすべて同じであれば、組織内で必要な数のフリートだけを設定するのが便利です。

このガイドは、組織でフリートを使用したい Cloud アーキテクトを対象としています。ここでは、クラスタをフリートに編成する際の実践的なガイダンスを提供します。これは、次のような場合に役立ちます。

  • まったく新しいクラスタを作成する場合。
  • 既存のクラスタでフリートを作成する場合。

ここで説明するパターンは多くの組織で機能しますが、フリート計画の方法は他にもあります。フリートは柔軟性があるため、クラスタに別のグループ化パターンを使用できます。

このガイドを読む前に、フリート管理の概要で説明されているコンセプトを理解しておく必要があります。また、このガイドでは、Kubernetes の基本的なコンセプトと Google Cloud のリソース階層に精通していることを前提としています。

フリートとリソースの制限

フリート作成時に、次の一般的な制限が適用されます。

  • 1 つの Google Cloud プロジェクトに関連付けられるのは、1 つのフリート（またはフリートなし）だけです。ただし、そのフリートには複数のプロジェクトのクラスタを含めることができます。フリートに関連付けられたプロジェクトは、フリートのフリート ホスト プロジェクトと呼ばれます。
  • クラスタがメンバーになれるフリートは 1 つだけです。
  • フリート内のクラスタ数のデフォルトの上限は 250 ですが、必要に応じて上限の引き上げをリクエストできます。

多くの場合、複数のクラスタを同じプロジェクトに配置することは有効な手法となります。ただし、プロジェクトに組み込むクラスタの計画では、次の上限を考慮してください。

一般原則

クラスタをフリートにグループ化するかどうかを判断する際に、考慮すべき一般的な質問を以下に示します。これらの適用方法については、以降のセクションで詳しく説明します。

  • リソースは相互に関連していますか？
    • サービス間の通信が多いリソースについては、フリート内で一体的に管理することで大きなメリットを得られます。
    • 同じデプロイ環境（本番環境など）のリソースは 1 つのフリートにまとめて管理する必要があります。
  • リソースを管理しているのは誰ですか？
    • フリートの整合性を確保するために重要になるのが、リソースの統合的（または少なくとも相互に信頼できる）な制御です。

新しいクラスタにフリートを計画する

このセクションでは、既知のアプリケーション セットがあり、アプリケーションのデプロイ場所を柔軟に選択できる場合に、フリート計画を立てる方法について説明します。これには、まだアプリケーションを開発していないか、別のコンテナ プラットフォームから移行している場合が該当します。また、既存のクラスタでアプリケーションがすでに実行されていますが、優先するアーキテクチャを実現するためにアプリケーションを新しいクラスタに移行することを検討している場合もあります。

フリートが特定されたら、フリートごとに新しいプロジェクトを作成し、各プロジェクトにフリートを作成して、目的のフリートにクラスタを作成して登録できます。

ワークロードを監査する

まず、デプロイするすべての Kubernetes ワークロード（Deployment など）のリストを作成します。これはリストである必要はありません。必要なワークロードのアイデアでも構いません。次に、このセクションの残りの手順に沿って、必要最小限のグループ化セットになるまで、アプリケーションのセットを徐々にサブセットに分割していきます。これにより、必要なフリートとクラスタを定義できます。

ビジネス ユニットを考慮する

組織に連携型の IT 構造がある場合があります。たとえば、組織の中央 IT チームが存在し、ビジネス ユニットごとにも IT チームが存在していることがあります。この場合、各 IT チームで独自のフリート管理が必要になることがあります。2 つのビジネス ユニットのワークロードが規制上の理由（銀行取引の監査など）で相互に通信できない場合は、別々のフリートを使用します。

ワークロードを環境ごとに分離する

多くの組織で使用される一般的なパターンは、クラスタを環境ごとにグループ化する方法です。一般的な構成では、開発環境、非本番環境（ステージング環境）、本番環境の 3 つのプライマリ環境を用意します。通常、アプリケーションの変更は、リスト内の各環境に段階的にデプロイ（またはプロモート）されます。そのため、同じ基盤となるアプリケーション（同じベースコンテナ イメージ名など）に対して、各環境で個別にデプロイを行う必要があります。組織内で環境を作成する方法の例については、エンタープライズ基盤ブループリントをご覧ください。

フリートには、1 つの環境のクラスタのみを含める必要があります。多くの組織では、3 つの環境と、それぞれの環境に 1 つのフリートがあれば十分です。各環境に 1 つのフリートがあり、アプリケーションを段階的にデプロイする方法の例については、エンタープライズ アプリケーションのブループリントをご覧ください。

冗長なワークロード インスタンスを組み合わせる

アプリケーションに高可用性が必要な場合、2 つ以上のリージョンでアプリケーションを実行する方法があります。このパターンでは、ユニットとして管理される 2 つ以上のクラスタでよく似た構成のデプロイを実行します。多くの場合、すべてのクラスタのアプリケーション インスタンスにまたがるロードバランサを使用するか、DNS ロード バランシングを使用します。

このようなシナリオでは、すべてのクラスタを同じフリートに配置します。通常、異なるリージョンのクラスタを別々のフリートに配置する必要はありませんが、規制上の理由やその他の理由で必要な場合は、別々のフリートに配置できます。

既存のクラスタでフリートを計画する

このセクションでは、既存のクラスタでワークロードが実行されていて、ワークロードを再配置しない場合に、フリートを計画する方法について説明します。これらのクラスタは、Google Cloud 内または外部に配置できます。このシナリオでは、組織内に一連のフリートを作成し、既存のクラスタを割り当てることを目的としています。

フリートが特定されたら、フリートごとに新しいプロジェクトを作成し、各プロジェクトにフリートを作成して、目的のフリートにクラスタを登録できます。

クラスタを監査する

まず、組織内のすべての Kubernetes クラスタのリストを取得します。Cloud Asset Inventory は、組織で Kubernetes クラスタ リソースを検索する方法の一つです。

次に、このセクションの残りの手順に沿って、必要最小限のグループ化セットになるまで、アプリケーションのセットを徐々にサブセットに分割していきます。これにより、必要なフリートが定義されます。

ビジネス ユニットを考慮する

組織に連携型の IT 構造がある場合があります。たとえば、組織の中央 IT チームが存在し、ビジネス ユニットごとにも IT チームが存在していることがあります。これらのビジネス ユニットの IT チームが、既存のクラスタを作成している可能性があります。この場合は通常、クラスタのセットをビジネス ユニットごとに分割します。たとえば、特定のビジネス ユニットのワークロード（銀行の監査と取引など）が、規制上の理由で相互に通信できない場合などです。

ビジネス ユニットが純粋に費用会計の目的で存在し、共通の IT チームを使用している場合（特に、ビジネス ユニット間でサービス間の依存関係が大きい場合）は、クラスタを 1 つのフリートにまとめることを検討してください。

環境ごとにクラスタをグループ化する

組織で使用されている環境を特定します。一般的な環境名は、開発、非本番環境（ステージング）、本番環境です。

各クラスタが明確に 1 つの環境にのみ存在する場合は、クラスタのリストを環境ごとに分離します。ただし、論理的に異なる環境に属するワークロードがクラスタに含まれている場合は、単一の論理環境に属するアプリケーションのみを含むクラスタに、アプリケーションを再デプロイすることをおすすめします。

クラスタ オーナーの数を最小限に抑える

既存のプロジェクトをフリートに結合する場合、IAM ポリシー（container.admin）と RBAC（admin ClusterRoleBinding）の両方を考慮して、これらのクラスタで管理者として機能するユーザーのセットを別にする場合があります。同一性が必要となる機能を使用する場合、すべてのクラスタで同じ管理者セットを使用し、フリート用に少数の管理者セットを用意する必要があります。クラスタに異なる管理者が必要で、同一性を必要とする機能を使用するときに、それらのクラスタが同じフリートに属していない場合があります。

たとえば、クラスタ C1 と C2 に互いに信頼関係のない異なる管理者がいて、フリートを管理する中央プラットフォーム チームに管理者権限を共有する意思がない場合は、フリート内でグループ化しないでください。

同一性と、同一性が必要となる機能の詳細については、フリートの仕組みをご覧ください。

フリート機能を検討する

新しいクラスタと既存のクラスタのどちらを使用しているかにかかわらず、選択したフリート機能は、フリート構成の最適化にも影響します。たとえば、フリート全体の Workload Identity 連携を使用する場合は、フリート全体のワークロード認証を設定する場合のリスクを最小限に抑えるようにフリートを編成できます。また、Cloud Service Mesh を使用する場合は、特定のクラスタを同じフリートに配置する必要があります。Virtual Private Cloud（VPC）を使用する場合、一部の機能ではフリートごとに 1 つの VPC を使用する必要があります。

フリート機能の導入、その要件と制限事項について詳しくは、このシリーズの次のガイド「フリート機能を計画する」をご覧ください。

VPC 境界を検討する

新規クラスタと既存クラスタの両方で考慮すべきもう一つの問題は、Virtual Private Cloud（VPC）を使用して Google Cloud で独自のプライベート ネットワークを作成する場合です。VPC 境界内のクラスタ（VPC Service Controls が有効になっている共有 VPC など）は、フリート内に一緒に配置できます。制限付きと制限なしの両方の共有 VPC がある場合は、それらを別々のフリートに配置することをおすすめします。

VPC Service Controls 境界を使用する予定がある場合は通常、一部のワークロードは境界内にあり、残りは境界外にあります。各環境（または少なくとも本番環境と本番環境の直前の環境）に、各フリートの VPC Service Controls バージョンと非 VPC Service Controls バージョンを用意する必要があります。

VPC を使用するフリートの計画を立てる際は、一部のフリート機能で、それらを使用するすべてのクラスタが同じ VPC ネットワーク内にある必要があるなど、特定の VPC 要件があることに注意してください。

次のステップ