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