このドキュメントでは、組織、プロジェクト、Kubernetes クラスタを使用して、Google Distributed Cloud（GDC）エアギャップのワークロードの階層と分離を設計するためのベスト プラクティスについて説明します。このガイダンスでは、効率的なリソース使用、ワークロードの分離、運用の容易さのバランスを考慮しています。
お客様間の物理的および論理的な分離を目的とした組織を設計する
Organization リソースは、1 人のお客様が所有するすべてのリソースのルートです。組織内のワークロード間のきめ細かいアクセス制御は、ロール バインディングとネットワーク ポリシーを使用して定義できます。詳細については、Identity and Access Management をご覧ください。
GDC ゾーン内の各組織は、コンピューティング インフラストラクチャの物理的な分離と、ネットワーキング、ストレージ、その他のサービスの論理的な分離を提供します。ある組織のユーザーは、明示的にアクセス権を付与されていない限り、別の組織のリソースにアクセスできません。ある組織から別の組織へのネットワーク接続は、ある組織からのデータ転送と別の組織へのデータ転送を許可するように明示的に構成されていない限り、デフォルトでは許可されません。
組織を共有できるワークロードのスコープを定義する
会社のコンテキストにおける組織のスコープは、会社が信頼境界をどのように定義しているかによって異なる場合があります。会社によっては、社内の異なるエンティティに対して複数の組織リソースを作成することを好む場合があります。たとえば、各部門がワークロードの完全な物理的および管理的な分離を必要とする場合、各部門は独立した組織を持つ GDC の独立した顧客になる可能性があります。
一般に、次のシグナルに基づいて、複数のワークロードを 1 つの組織にグループ化することをおすすめします。
- ワークロードは依存関係を共有できます。たとえば、共有データソース、ワークロード間の接続、共有モニタリング ツールなどです。
- ワークロードは、管理ルート オブ トラストを共有できます。同じ管理者が、組織内のすべてのワークロードに対する特権アクセスを信頼できます。
- 十分な論理的な分離が実施されている限り、ワークロードは同じ組織内の他のワークロードと基盤となる物理インフラストラクチャを共有できます。
- 同じ予算管理者が、ワークロード予算の合計に対して説明責任を負います。組織の集計費用やワークロードごとの詳細な分析を表示する方法については、[お支払い] ページをご覧ください。
- ワークロードの可用性要件は、マルチゾーン距離の高可用性要件に従う必要があります。
ワークロード間の論理的な分離を考慮してプロジェクトを設計する
組織内では、複数のプロジェクトをプロビジョニングして、リソース間に論理的な分離を作成することをおすすめします。同じ組織内のプロジェクトは、基盤となる物理インフラストラクチャを共有する場合がありますが、プロジェクトは、Identity and Access Management（IAM）ポリシーとネットワーク ポリシーに基づいて論理境界でワークロードを分離するために使用されます。
プロジェクトの境界を設計するときは、ロール バインディング、ネットワーク ポリシー、オブザーバビリティの要件など、リソースで共有できる機能の最大のセットを検討します。この機能を共有できるリソースをプロジェクトにグループ化し、この機能を共有できないリソースを別のプロジェクトに移動します。
Kubernetes の用語では、プロジェクトは組織内のすべてのクラスタに予約されている Kubernetes の Namespace です。名前空間は複数のクラスタにわたって予約されますが、これは Pod がすべてのクラスタにわたって自動的にスケジュールされることを意味するものではありません。特定のクラスタにスケジュールされた Pod は、その特定のクラスタにスケジュールされたままになります。
次の図は、複数のクラスタにまたがるプロジェクトにロール バインディングがどのように適用されるかを示しています。
ロール バインディングはプロジェクト レベルで設定され、誰がどのリソースタイプに対して何を実行できるかを定義します。VM や Pod などのワークロードはプロジェクトにデプロイされ、これらのワークロードへのアクセスはロール バインディングによって管理されます。ロール バインディングは、デプロイ先のクラスタに関係なく、VM ベースのワークロードとコンテナベースのワークロードに一貫して適用されます。
次の図は、ネットワーク ポリシーがプロジェクト間のアクセスを管理する方法を示しています。Backend Project、Frontend Project、Database Project 間のプロジェクト間通信は無効になっています。ただし、各プロジェクト内のリソースは相互に通信できます。
ネットワーク ポリシーは、リソース間のネットワーク アクセスを選択的に許可するためにプロジェクト レベルで設定されます。デフォルトでは、同じプロジェクト内のすべてのリソースは内部ネットワーク上で相互に通信できます。また、あるプロジェクトのリソースは別のプロジェクトのリソースと通信できません。ネットワーク ポリシーのこの動作は、リソースが同じクラスタにデプロイされているかどうかに関係なく適用されます。
ProjectNetworkPolicy カスタム リソースを定義して、プロジェクト間の通信を有効にすることもできます。このポリシーは、他のプロジェクトからの上り（内向き）トラフィックを許可するために、プロジェクトごとに定義されます。次の図は、Frontend Project と Database Project からのデータ転送を有効にするために Backend Project に定義された ProjectNetworkPolicy カスタム リソースを示しています。
また、モニタリング スタックは組織全体の指標を収集しますが、リソース階層のさまざまなレベルでフィルタリングやクエリを行うことができます。クラスタや Namespace などのエンティティを使用して指標をクエリできます。
ソフトウェア開発環境ごとにプロジェクトを作成する
ワークロードごとに、ソフトウェア開発環境ごとに個別のプロジェクトを作成することをおすすめします。ソフトウェア開発環境は、指定されたライフサイクル フェーズに対応するすべてのオペレーションを対象とする GDC ユニバース内の領域です。たとえば、テスト、開発、本番環境用のソフトウェア開発環境を構築できます。ソフトウェア開発環境を分離すると、ロール バインディングとネットワーク ポリシーをきめ細かく定義できるため、非本番環境で使用されるプロジェクトで行われた変更が本番環境に影響することはありません。
プロジェクト内でリソースレベルのロール バインディングを付与する
チームの構造と要件に応じて、デベロッパーが管理するプロジェクト内のリソースを変更できるようにすることも、よりきめ細かいアクセス制御を必要とすることもできます。プロジェクト内で、個々のデベロッパーがプロジェクト内のすべてのリソースではなく、一部のリソースにアクセスできるように、きめ細かいロール バインディングを付与します。たとえば、チームにデータベースを管理する必要があるデータベース管理者がいるが、他のリソースを変更する必要がない場合、チームのソフトウェア デベロッパーにはデータベースを変更する権限を付与しないでください。
Kubernetes オペレーションを論理的に分離するようにクラスタを設計する
Kubernetes クラスタは、ロール バインディングとネットワーク ポリシーが Kubernetes クラスタではなくプロジェクトに適用されるため、厳格なテナント境界ではありません。Kubernetes クラスタとプロジェクトには多対多の関係があります。1 つのプロジェクトに複数の Kubernetes クラスタが存在する場合や、1 つの Kubernetes クラスタが複数のプロジェクトにまたがっている場合があります。