このドキュメントでは、Google Distributed Cloud（GDC）のエアギャップ リソース階層と、エアギャップ インスタンスでリソースを管理する方法について説明します。複数のゾーンにまたがるリソースの管理のコンセプトについては、マルチゾーンの概要をご覧ください。
GDC リソース階層の目的は次の 2 つです。
- 所有権を階層的に編成し、リソースのライフサイクルを階層で直接の親にバインドする。
- アクセス制御ポリシーと組織のポリシーの接続ポイントを提供し、継承を可能にする。
GDC リソース階層は、エンティティを階層的に編成して管理している点では、オペレーティング システムのファイル システムに類似しています。一般的に、各リソースの親は 1 つだけです。リソースを階層的に編成することで、Identity and Access Management（IAM）などのアクセス制御ポリシーを割り当て、子リソースに継承できます。
アクセス境界を整理するためのベスト プラクティスの詳細については、リソース間のアクセス境界を設計するをご覧ください。
リソース構造の詳細
次のエンティティは、GDC リソース階層で認識されるリソースタイプです。
GDC リソースは階層的に編成されます。リソース階層内のほとんどのリソースの親は 1 つだけです。この例外は、最も高いリソースにのみ適用されます。最下位レベルでは、サービス リソースがすべての GDC サービスを構成する基本要素となります。
組織は GDC リソース階層の最上位にあり、組織に属するすべてのリソースは組織リソースの下にグループ化されます。これにより、組織に属するすべてのリソースを集中管理できます。
プロジェクトとクラスタはどちらも組織スコープです。これらを相互に接続して、サービス リソースを整理できます。ただし、プロジェクトとクラスタは互いに独立して機能します。この柔軟性により、サービスとワークロードの整理方法についてさまざまなオプションが提供されます。たとえば、単一のプロジェクト専用のクラスタを作成できます。同様に、クラスタは複数のプロジェクトにまたがることができます。
サービス リソースは、プロジェクトまたはクラスタに属している必要があり、プロジェクトまたはクラスタ間で共有できないエンティティです。サービス リソースの例には、仮想マシン（VM）、データベース、ストレージ バケット、バックアップなどがあります。これらの下位レベルのリソースのほとんどは、親としてプロジェクト リソースを持ちます。
次の図は、GDC リソース階層の例を示しています。
最適なワークロード管理のためにリソース階層を整理するためのベスト プラクティスの詳細については、ユーザー ワークロードの分離を設計するをご覧ください。
組織
組織リソースは、会社などの管理単位またはビジネス機能を表し、GDC リソース階層の最上位のリソースです。組織は、一緒に管理されるインフラストラクチャ リソースを囲むセキュリティ境界を定義し、ユーザーがアプリケーション ワークロードをデプロイできるようにします。組織はグローバルであり、ユニバース内のすべてのゾーンにまたがります。組織内では、VM やストレージ ボリュームなどのサービス リソースはプロジェクトごとに論理的にグループ化されます。
すべてのプロジェクト、クラスタ、サービス リソースは、作成者ではなく組織に属します。つまり、作成したユーザーが組織を離れても、組織のリソースタイプは削除されません。代わりに、すべてのリソースタイプは GDC で組織のライフサイクルに従います。
組織リソースに適用される IAM アクセス制御ポリシーは、組織内のすべてのリソースの階層全体に適用されます。組織全体のポリシーと権限の付与の詳細については、組織のポリシーと IAM のセクションをご覧ください。
プロジェクト
プロジェクトは、すべてのサービスが統合する必要があるテナンシー ユニットです。プロジェクトは、サービス リソースの論理グループ化を提供します。プロジェクトはグローバルであり、ユニバース内のすべてのゾーンにまたがります。
プロジェクトを使用すると、組織内のサービス リソースをセグメント化し、リソースを管理するためのライフサイクルとポリシーの境界を設定できます。プロジェクト内のサービス リソースは、プロジェクト自体よりも長く存続したり、プロジェクト間で移動したりすることはありません。これにより、リソースのライフサイクル全体で制御が利用可能になります。したがって、プロジェクト Namespace 内に任意タイプのリソースをデプロイする必要があります。
プロジェクトは、組織内の複数のクラスタにまたがる適切な Kubernetes Namespace と見なされます。Namespace の同一性により、同じ組織内のすべてのクラスタで、特定の名前のすべての Namespace が同じ Namespace と見なされます。単一の Namespace には、クラスタのセット全体で一貫したオーナーがいます。サービス プロバイダは、Namespace にコントロール プレーン コンポーネントとデータプレーン コンポーネントを作成して、プロジェクト スコープのサービスを作成します。
プロジェクトの Namespace には、次のものがホストされます。
- プロジェクト スコープのサービス API。
- プロジェクト レベルのポリシー構成（ロールやロール バインディングなど）。
プロジェクトを組織内のクラスタのサブセットにのみ関連付けることができます。コンテナ化されたワークロードは、プロジェクト Namespace 内のこれらのクラスタにデプロイできます。Namespace の同一性のコンセプトは、これらのクラスタのプロジェクト Namespace に適用されます。ロールベースのアクセス（RBAC）ポリシーなどの Namespace スコープのポリシーは、これらのすべての Namespace に適用されます。
プロジェクトの詳細については、プロジェクトの概要をご覧ください。
Kubernetes クラスタ
Kubernetes クラスタは、GDC 上の GKE の一部としてコンテナ化されたワークロードを実行するノードのセットです。アプリケーションのコンピューティング要件をサポートするように Kubernetes クラスタをプロビジョニングできます。クラスタは組織スコープであり、1 つ以上のプロジェクトに関連付ける必要があります。
クラスタは、インフラストラクチャ リソースを組織内のプロジェクトで使用される分離されたプールに分割します。クラスタは論理的にも分離され、異なる障害ドメインと分離保証が提供されます。組織ごとのポリシーの適用により、クラスタをチームやユーザー間で共有しながら、パフォーマンスとリソースの保証を維持できます。また、組織のポリシーを使用すると、運用上の複雑さを増すことなく、VM ワークロードをコンテナ ワークロードとともに実行できます。
クラスタは、コンテナ化されたワークロードをデプロイする必要があるインスタンスに役立ちます。ただし、VM ベースのワークロードをデプロイするオプションを使用すると、GDC で Kubernetes クラスタが存在する必要はありません。
クラスタはゾーンリソースのみであり、複数のゾーンにまたがることはできません。マルチゾーン デプロイでクラスタを運用するには、各ゾーンにクラスタを手動でデプロイする必要があります。
Kubernetes クラスタの詳細については、Kubernetes クラスタを管理するをご覧ください。
サービス リソース
サービス リソースには、次のような多くのエンティティが含まれています。
- VM
- データベース
- ストレージ バケット
- コンテナ型ワークロード
- バックアップ
サービス リソースはプロジェクトに属している必要があります。コンテナ化されたワークロードの場合は、必要に応じてクラスタに属している必要があります。また、プロジェクト間で共有することはできません。つまり、プロジェクト内のサービス リソースはプロジェクト自体よりも長く存続することはなく、リソースのライフサイクル全体で制御が利用可能になります。
サービス リソースは、タイプに応じてグローバルまたはゾーンにデプロイできます。マルチゾーン デプロイ オプションについては、特定のサービスのドキュメントをご覧ください。サービス リソースはデフォルトで有効になっており、組織のポリシーを使用して無効にできます。