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