このドキュメントでは、組織、プロジェクト、Kubernetes クラスタを使用して、Google Distributed Cloud（GDC）エアギャップ環境のワークロードの階層と分離を設計するためのベスト プラクティスについて説明します。このガイダンスでは、リソースの効率的な使用、ワークロードの分離、運用の容易さのバランスを取ります。
顧客間の物理的および論理的な分離のために組織を設計する
Organization リソースは、1 人の顧客が所有するすべてのリソースのルートです。組織内のワークロード間の詳細なアクセス制御は、ロール バインディングとネットワーク ポリシーを使用して定義できます。詳細については、
Identity and Access Management をご覧ください。
GDC ゾーン内の各組織は、コンピューティング インフラストラクチャの物理的な分離と、ネットワーキング、ストレージ、その他のサービスの論理的な分離を提供します。明示的にアクセス権が付与されない限り、1 つの組織のユーザーは別の組織のリソースにアクセスできません。デフォルトでは、ある組織から別の組織へのネットワーク接続は許可されません。ただし、ある組織からのデータ転送と別の組織へのデータ転送を許可するように明示的に構成されている場合は除きます。
組織を共有できるワークロードのスコープを定義する
企業コンテキストでの組織のスコープは、企業が信頼境界をどのように定義するかによって異なります。企業によっては、社内のさまざまなエンティティに対して複数の組織リソースを作成する場合があります。たとえば、部門がワークロードの完全な物理的分離と管理上の分離を必要とする場合、各部門は独立した組織を持つ GDC の独立した顧客になる可能性があります。
一般に、次のシグナルに基づいて、複数のワークロードを 1 つの組織にグループ化することをおすすめします。
- ワークロードは依存関係を共有できます。たとえば、共有データソース、ワークロード間の接続、共有モニタリング ツールなどがあります。
- ワークロードは、管理ルート オブ トラストを共有できます。同じ管理者に、組織内のすべてのワークロードに対する特権アクセスを信頼できます。
- 十分な論理的分離が確保されている限り、ワークロードは基盤となる物理インフラストラクチャを同じ組織内の他のワークロードと共有できます。
- 同じ予算保有者が、ワークロードの予算の合計額に対して責任を負います。 組織の合計費用を表示する方法や、ワークロードごとの詳細な 分析については、 [お支払い] ページをご覧ください。
- ワークロードの可用性要件は、マルチゾーン間の距離に関する高可用性の要件に従う必要があります。
ワークロード間の論理的な分離のためにプロジェクトを設計する
組織内では、リソース間の論理的な分離を作成するために、複数のプロジェクトをプロビジョニングすることをおすすめします。同じ組織内のプロジェクトは基盤となる物理インフラストラクチャを共有する場合がありますが、プロジェクトは Identity and Access Management（IAM）ポリシーとネットワーク ポリシーに基づいて、論理境界でワークロードを分離するために使用されます。
プロジェクト境界を設計する際は、リソース間で共有できる最大の 機能セットを考慮してください。たとえば、 ロール バインディング、 ネットワーク ポリシー、 オブザーバビリティ 要件などです。この機能を共有できるリソースをプロジェクトにグループ化し、この機能を共有できないリソースを別のプロジェクトに移動します。
Kubernetes の用語では、プロジェクトは組織内のすべてのクラスタで予約されている Kubernetes Namespace です。 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 クラスタを含めることもできます。