このドキュメントでは、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 のセクションをご覧ください。
プロジェクト
プロジェクトは、すべてのサービスが統合する必要があるテナンシー ユニットです。プロジェクトは、サービス リソースの論理グループを提供します。プロジェクトはグローバルであり、ユニバース内のすべてのゾーンにまたがります。
プロジェクトを使用すると、組織内のサービス リソースをセグメント化し、リソースを管理するためのライフサイクルとポリシーの境界を定義できます。プロジェクト内のサービス リソースがプロジェクト自体よりも長く存続したり、プロジェクト間で移動したりすることはありません。これにより、リソースの存続期間中、制御が可能になります。したがって、プロジェクトの名前空間内に任意の種類のリソースをデプロイする必要があります。
プロジェクトは、組織内の複数の共有クラスタにまたがる適切な Kubernetes Namespace と見なされます。Namespace の同一性により、同じ組織内のすべての共有クラスタで、指定された名前のすべての Namespace が同じ Namespace と見なされます。単一の Namespace には、共有クラスタのセット全体で一貫したオーナーが存在します。サービス プロバイダは、Namespace にコントロール プレーンとデータプレーンのコンポーネントを作成して、プロジェクト スコープのサービスを作成します。
プロジェクトの名前空間は、次のものをホストします。
- プロジェクト スコープのサービス API。
- プロジェクト レベルのポリシー構成（ロールやロール バインディングなど）。
プロジェクトは、組織内の共有クラスタのサブセットにのみ接続できます。コンテナ化されたワークロードは、プロジェクトの名前空間内のこれらの共有クラスタにデプロイできます。Namespace の同一性のコンセプトは、これらの共有クラスタのプロジェクト Namespace に適用されます。ロールベース アクセス（RBAC）ポリシーなどの名前空間スコープのポリシーは、これらのすべての名前空間に適用されます。
プロジェクトの詳細については、プロジェクトの概要をご覧ください。
共有 Kubernetes クラスタ
Kubernetes クラスタは、GKE on GDC の一部としてコンテナ化されたワークロードを実行するノードのセットです。Kubernetes クラスタをプロビジョニングして、アプリケーションのコンピューティング要件をサポートできます。
共有クラスタは、組織をスコープとするクラスタ構成であり、1 つ以上のプロジェクトに接続する必要があります。標準クラスタは、単一のプロジェクト内でのみ動作する別のクラスタ構成ですが、リソース階層ではサービス リソースと見なされます。これらの Kubernetes クラスタ構成は、テスト、開発、本番環境などのソフトウェア開発環境全体でコンテナ管理オプションを提供する Kubernetes アーキテクチャを構築するように設計されています。コンテナ ワークロードの分離のベスト プラクティスの詳細については、ワークロードの分離を設計するをご覧ください。
GDC のさまざまなクラスタタイプの詳細については、Kubernetes クラスタの構成をご覧ください。
共有クラスタは、インフラストラクチャ リソースを分離されたプールに分割し、組織内のプロジェクトで使用できるようにします。クラスタは、異なる障害発生ドメインと分離保証を提供するために、互いに論理的に分離されています。組織ごとにポリシーを適用することで、共有クラスタをチームやユーザー間で共有しながら、パフォーマンスとリソースの保証を維持できます。さらに、組織のポリシーにより、運用の複雑さを増すことなく、VM ワークロードをコンテナ ワークロードと並行して実行できます。
クラスタは、コンテナ化されたワークロードをデプロイする必要がある場合に役立ちます。ただし、VM ベースのワークロードをデプロイするオプションを使用する場合、GDC に Kubernetes クラスタは必要ありません。
クラスタはゾーンリソースのみであり、複数のゾーンにまたがることはできません。マルチゾーン デプロイでクラスタを運用するには、各ゾーンにクラスタを手動でデプロイする必要があります。
Kubernetes クラスタの詳細については、Kubernetes クラスタの概要をご覧ください。
サービス リソース
サービス リソースには、次のような多くのエンティティが含まれます。
- VM
- 標準の Kubernetes クラスタ
- データベース
- ストレージ バケット
- コンテナ型ワークロード
- バックアップ
サービス リソースはプロジェクトに属している必要があり、プロジェクト間で共有することはできません。このプロジェクト固有のライフサイクルは、プロジェクト内のサービス リソースがプロジェクト自体よりも長く存続することはないことを意味し、リソースの存続期間中に制御が利用可能であることを保証します。
サービス リソースは、タイプに応じてグローバルまたはゾーンにデプロイできます。マルチゾーン デプロイ オプションの詳細については、特定のサービスのドキュメントをご覧ください。サービス リソースはデフォルトで有効になっていますが、組織のポリシーを使用して無効にできます。