コンテンツに移動
Containers & Kubernetes

Config Sync とチームスコープを使用したスケーラブルなマルチテナンシー管理

2024年6月4日
Janet Kuo

Staff Software Engineer, Google Cloud

Kavitha Gowda

Product Manager, Google Cloud

※この投稿は米国時間 2024 年 5 月 4 日に、Google Cloud blog に投稿されたものの抄訳です。

アプリケーション チームやサービス チームに必要なリソースを確保することは、プラットフォーム管理者にとって重要です。Google Kubernetes EngineGKE)のフリートチーム管理を使用して各チームをフリート内で個別の「テナント」として機能させると、それを簡単に行うことができます。GKE GitOps サービスである Config Sync と組み合わせると、フリート全体のチームのリソース管理を合理化できます。

具体的には、Config Sync のチームスコープでリソースの割り当てやネットワーク ポリシーなどのクラスタ構成をフリート全体およびチームごとに定義して、各アプリケーション チームがクラスタ全体で指定された名前空間内のワークロードを管理できます。

いくつかのシナリオについて考えてみましょう。

フロントエンド チームとバックエンド チームのリソースを分離

フロントエンド チームとバックエンド チームにリソースをプロビジョニングするとします。それぞれのチームには独自のテナント スペースが必要です。チームスコープとフリートの名前空間を使用すると、各チームがどのメンバー クラスタでどの名前空間にアクセスするかを管理できます。

たとえば、バックエンド チームは us-east-cluster us-west-cluster クラスタで bookstore shoestore 名前空間にアクセスし、フロントエンド チームは 3 つのメンバー クラスタすべてで frontend-a frontend-b 名前空間にアクセスするとします。

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_-_intro.max-1100x1100.jpg

Config Sync を使用してリソースを動的にプロビジョニングする

Terraform を使用して、フリート全体で Config Sync をデフォルトで有効にできます。以下に Terraform の構成例を示します。

読み込んでいます...

: フリートのデフォルトは、フリートで新しく作成されたクラスタのみに適用されます。

この Terraform 構成では、Config Sync フリート全体のデフォルト機能として有効にしていします。Config Sync をインストールして、Git リポジトリ(具体的には「main」ブランチと「fleet-tenancy/config」フォルダ)から Kubernetes マニフェストをフェッチするよう指示します。この構成は、このフリート内で今後作成されるすべてのクラスタに自動的に適用されます。このアプローチは、フリート クラスタ全体でマニフェストを構成する優れた方法であり、個々のクラスタを手動でインストールして構成する必要性を排除します。

これで Config Sync がデフォルトのフリート設定として構成されたので、次に特定の Kubernetes リソースを各チームに指定した名前空間とクラスタに同期します。Config Sync をチームスコープと組み合わせると、このプロセスが合理化されます。

チームスコープを設定する 同じ例で、フロントエンド チームとバックエンド チームに異なるネットワーク ポリシーを適用するとします。フリートチーム管理機能は、個々のチームのインフラストラクチャ リソースをプロビジョニングおよび管理するプロセスを簡素化し、フリート内で各チームを個別の「テナント」として扱います。

個別のテナンシーを管理するには、上のチームスコープの図に示すように、まずバックエンド チームとフロントエンド チームのチームスコープを設定します。これには、フリートレベルの名前空間を定義し、各チームスコープにフリート メンバー クラスタを追加します。

それでは、Config Sync でクラスタを同期する Kubernetes マニフェストを詳しく見てみましょう。

Config Sync でチームスコープを適用するクラスタ内の各フリート名前空間には、自動的に fleet.gke.io/fleet-scope: <scope name> というラベルが付けられます。たとえば、バックエンドのチームスコープには、フリート名前空間 bookstore shoestore が含まれ、どちらにも fleet.gke.io/fleet-scope: backend というラベルが付いています。

Config Sync NamespaceSelector は、このラベルを使用して、チームスコープ内の特定の名前空間をターゲットにします。バックエンド チームの構成は以下のとおりです。

読み込んでいます...

バックエンド チームに NetworkPolicy を適用する

リソースに configmanagement.gke.io/namespace-selector: <NamespaceSelector name> というアノテーションを付けると、自動的に正しい名前空間に割り当てられます。バックエンド チームの NetworkPolicy は以下のとおりです。

読み込んでいます...

この NetworkPolicy は、バックエンド チームの bookstore shoestore 名前空間に自動的にプロビジョニングされ、名前空間やメンバー クラスタの追加 / 削除などのフリートに加えられた変更に適応します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/2_-_add_networkpolicy.max-1100x1100.jpg

概念を拡張する: フロントエンド チームの ResourceQuota

以下に、ResourceQuota がどのようにフロントエンド チームの名前空間に動的に適用されるかを示します。

読み込んでいます...

同様に、この ResourceQuota は、フロントエンド チームの frontend-a frontend-b 名前空間をターゲットとし、フリートの名前空間とメンバー クラスタの変化に応じて動的に調整します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/3_-_add_resourcequota.max-1100x1100.jpg

Config Sync を使用したリソース管理の委任: バックエンド チームに権限を付与する

指定された bookstore 名前空間内のリソースをバックエンド チームが自身で管理できるようにするには、Config Sync RepoSync を使用します。これは、多少異なる NamespaceSelector です。

特定のフリート名前空間をターゲットにする

バックエンド チームの bookstore 名前空間に焦点を当てると、次の NamespaceSelector は、ラベルを使用して両方のチームスコープと名前空間の名前をターゲットにしています。

読み込んでいます...

RepoSync を導入する

Config Sync のもう一つの機能として RepoSync があります。これを使用すると、特定の名前空間内でリソースの管理を委任できます。セキュリティ上の理由から、RepoSync にはデフォルト アクセスはなく、必要な RBAC 権限を名前空間に明示的に付与する必要があります。

NamespaceSelector を利用して、バックエンド チームのメンバー クラスタ全体にあるすべての bookstore 名前空間に、以下の RepoSync リソースとその RoleBinding を動的に適用できます。RepoSync は、それをバックエンド チームが所有するリポジトリにポイントします。

読み込んでいます...

: .spec.git セクションは、バックエンド チームのリポジトリを参照します。

バックエンド チームのリポジトリには、ConfigMap が含まれます。Config Sync は、バックエンド チームのメンバー クラスタすべてで ConfigMap bookstore 名前空間に確実に適用されるようにし、管理における GitOps アプローチをサポートします。

複数チームのリソースの管理を簡単に

クラスタのフリート内で複数チームのリソースを管理するのは複雑な作業です。Google Cloud のフリートチーム管理機能と Config Sync の組み合わせは、このプロセスを合理化するための効果的なソリューションです。

このブログ投稿では、フロントエンド チームとバックエンド チームがそれぞれ独自のテナント スペースとリソースを必要とするシナリオについて検討しました(NetworkPolicyResourceQuotaRepoSync)。Config Sync とフリート管理機能を組み合わせて使用することで、これらのリソースのプロビジョニングを自動化し、一貫性のあるスケーラブルな設定が適用されるようにしました。

次のステップ

ー Google Cloud、スタッフ ソフトウェア エンジニア Janet Kuo

ー Google Cloud、プロダクト マネージャー Kavitha Gowda

投稿先