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