プラットフォーム管理者の一般的なタスクは、アプリケーション チームおよびサービスチームがワークロードを実行するのに必要なインフラストラクチャ リソースを用意することです。組織によっては、特定のクラスタを使用する必要がある場合があります。また、各チームに適切なアクセス制御を設定してフリート内のすべてのクラスタでワークロードを実行する必要がある場合があります。フリートチーム管理機能によって、管理者はこのようにチームに対してインフラストラクチャ リソースをプロビジョニングし、管理することが容易になります。各チームはフリートの別々の「テナント」として機能します。ワークロードの実行と管理に加え、独自のクラスタと名前空間のセットを対象としたログ、リソース使用率、エラー率などの指標を表示することも可能です。
このページは、フリートチーム管理機能の詳細を知りたいプラットフォーム管理者とアプリケーション チームのメンバーを対象としています。フリートチーム管理機能は、GKE Enterprise プラットフォーム全体を有効にしたユーザーのみ使用できます。
フリートチーム管理の概要
フリートチーム管理は、フリートを管理するときに使用する「チームレベル」の抽象化を管理者が行うための 2 つの主要なコンセプトに基づいています。
- チームスコープを使用すると、チームごとにフリート リソースのサブセットを定義できます。各スコープは、1 つ以上のフリート メンバー クラスタと関連付けられます。チームスコープには、Google Cloud 上または Google Cloud 外のクラスタを含めることができますが、すべてのクラスタは同じフリートのメンバーである必要があります。クラスタは複数のチームスコープに関連付けることができるため、異なるチームが同じクラスタでワークロードを実行できます。
- フリートの名前空間によって、フリート内の特定の名前空間へのアクセス権がある者を制御できます。デフォルトでは、フリート内のクラスタに定義された同じ名前の名前空間は、同じ名前空間であるかのように扱われます。ただし、フリートチーム管理によって、名前空間をより細かく制御できます。特定のチームスコープ内にフリート名前空間を作成し、チームメンバーにチームスコープ内のクラスタのみへのアクセス権を付与できます。フリートの名前空間は、チームスコープのメンバー クラスタ上の他の Kubernetes 名前空間と同じ方法で使用できます。プラットフォーム管理者は、フリートの名前空間を自分自身で作成することも、なんらかの追加の権限でチーム管理者に名前空間の作成を委任することもできます。
チーム管理の例
たとえば、単一のフリートに 2 つのチームのリソースを設定する Cymbal Group の会社のプラットフォーム管理者であるとします。
- バックエンド チームは、1 つの Google グループ
backend-team@cymbalgroup.comで構成されています。このチームが名前空間backendを使用して、クラスタ 1 とクラスタ 2 でワークロードを実行できることを決定しました。2 つのクラスタを含むチームスコープを作成し、そのスコープ内にbackendフリートの名前空間を定義します。 - フロントエンド チームは、
frontend-admin@cymbalgroup.comとfrontend-dev@cymbalgroup.comの 2 つの Google グループで構成されています。名前空間frontend-fooとfrontend-barを使用して、フロントエンド チームがクラスタ 2 とクラスタ 3 でワークロードを実行できることを決定します。再び、2 つのクラスタを持つチームスコープを作成し、そのスコープ内に 2 つのフリート名前空間を定義します。
図に示すように、チームを設定すると、両方のチームは各チームが独自の名前空間を使用してクラスタ 2 を使用できるようになります。さらに、バックエンド チームはクラスタ 1 で名前空間を使用でき、フロントエンド チームはクラスタ 3 で名前空間を使用できます。両方のチームはクラスタ上でワークロードを実行し、他のチームを考慮せずに独自のリソースを表示できます。
いずれの場合も、チームリーダー（バックエンド チームの場合は個々のユーザー Dana、フロントエンド チームの場合は frontend-admin グループ メンバー）がチームスコープへの admin アクセス権があることを指定します。つまり、残りのチームメンバーが editor アクセス権がある一方で、彼らはスコープ内にロールとロール バインディングを作成できるということです。
この構成はすべて kubectl や他のツールで手動で設定できる一方、チーム管理機能を使用すると、チームをすばやくオンボーディングしやすくなり、管理者とチームメンバーはチームスコープ指標などのチームスコープに基づいて追加機能を使用できます。
実際の状況では、本番環境、開発環境、テスト環境用に別々のフリートを用意することになるでしょう。これらのフリートのそれぞれにフロントエンド チームとバックエンド チームのチームスコープを作成し、チームに独自の本番、開発、テストのクラスタを提供します。詳細については、フリートのベスト プラクティスと例をご覧ください。
チーム対応の機能
チームのスコープを設定すると、アプリケーション オペレータと管理者は、スコープ全体からリソースの使用率、ログ、名前空間別のエラーなど、チームスコープの情報を表示でき、リソース全体の使用状況、問題のトラブルシューティングなどを簡単に評価できます。これらの詳細については、チームの概要を使用するをご覧ください。 チームスコープは、アップグレード ロールアウトの順序付けにも使用できます。
チームスコープへのアクセス
チームメンバーは、Connect Gateway 用の特別なクラスタ認証情報を使用して、kubectl でチームスコープ クラスタにアクセスすることをおすすめします。Connect Gateway は、認証のための Google グループの使用など、ユーザーがフリート内の任意のクラスタにその Google ID でログインできるようにする一貫性のある安全なサービスです。 これは、Google Cloud 上の GKE クラスタへの認証に厳密には必要ありませんが、ゲートウェイの認証情報を使用すると、プロジェクト間でもフリート メンバー クラスタに対してシンプルで一貫した認証方法を提供します。現在のところ、フリートチーム管理はサードパーティの ID プロバイダをサポートしていません。
既存のリソース
フリートチーム管理を使用して、組織のチームで使用されている既存の名前空間とクラスタを「オンボーディング」することもできます。これにより、管理者とチームは既存のワークロードでチームベースの機能の使用を開始できます。フリートの名前空間を作成し、そのチームスコープに関連付けられたクラスタの 1 つに既存の Kubernetes Namespace がその名前付きである場合、その名前空間はフリート名前空間のインスタンス化と見なされ、そのためにチームスコープの一部とみなされます。
次のステップ
- プラットフォーム管理者の場合は、チームの設定の手順に従って、チームのスコープと名前空間を設定、構成、管理します。
- チームレベルの指標とその他のチーム特有の情報を表示する方法については、チームの概要を使用する（限定プレビューのみ）をご覧ください。