[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-09-04。"],[[["\u003cp\u003eThe Google Distributed Cloud (GDC) air-gapped resource hierarchy organizes resources with a parent-child structure, enabling lifecycle management and access control inheritance.\u003c/p\u003e\n"],["\u003cp\u003eThe hierarchy consists of organizations, projects, Kubernetes clusters, and service resources, with organizations at the top, providing central visibility and control.\u003c/p\u003e\n"],["\u003cp\u003eProjects and clusters, which are organization-scoped, offer flexibility in organizing service resources and workloads, but function independently of each other.\u003c/p\u003e\n"],["\u003cp\u003eService resources, like VMs and databases, must belong to either a project or a cluster, ensuring they cannot be shared across projects and their lifecycle is tied to their parent.\u003c/p\u003e\n"],["\u003cp\u003eOrganizations define a security boundary, and the IAM access control policies set at the organization level apply throughout the hierarchy to all resources within it.\u003c/p\u003e\n"]]],[],null,["# Resource hierarchy\n\nThis document describes the Google Distributed Cloud (GDC) air-gapped resource hierarchy\nand how resources are managed in an air-gapped instance. For concepts on\nmanaging resources across multiple zones, see the\n[Multi-zone overview](/distributed-cloud/hosted/docs/latest/gdch/resources/multi-zone/mz-overview).\n\nThe purpose of the GDC resource hierarchy is twofold:\n\n- Provide a hierarchy of ownership, which binds the lifecycle of a resource to its immediate parent in the hierarchy.\n- Provide attach points and inheritance for access control and organization policies.\n\nThe GDC resource hierarchy resembles the file system\nfound in operating systems as a way of organizing and managing entities\nhierarchically. Generally, each resource has exactly one parent. This\nhierarchical organization of resources lets you set access control policies,\nsuch as Identity and Access Management (IAM), which are inherited by child resources.\n\nFor more information on best practices for organizing your access boundaries, see\n[Design access boundaries between resources](/distributed-cloud/hosted/docs/latest/gdch/resources/access-boundaries).\n\nResource structure in detail\n----------------------------\n\nThe following entities are resource types recognized in the\nGDC resource hierarchy:\n\n- [Organization](#organization)\n- [Project](#project)\n- [Kubernetes cluster](#cluster)\n- [Service resource](#service-resource)\n\nGDC resources are organized hierarchically. Most\nresources in the resource hierarchy have exactly one parent. The exception only\napplies to the highest resource. At the lowest level, service resources are the\nfundamental components that make up all GDC services.\n\nAn organization is the top of the GDC resource\nhierarchy, and all resources that belong to an organization are grouped under\nthe organization resource. This provides central visibility and control over\nevery resource that belongs to an organization.\n\nBoth projects and clusters are organization-scoped. They can be attached to\none another to organize service resources. However, projects and clusters\nfunction independently from one another. This flexibility provides many\ndifferent options for how to organize services and workloads. For example, you\ncan have a cluster dedicated to a single project. Likewise, a cluster can span\nacross multiple projects.\n\nService resources are entities that must belong to a project or a cluster, and\ncannot be shared across projects or clusters. Examples of service\nresources include virtual machines (VMs), databases, storage buckets, and\nbackups. Most of these lower-level resources have project resources as their\nparents.\n\nThe following diagram represents an example GDC resource\nhierarchy:\n\nFor more information on best practices for organizing your resource hierarchy\nfor optimal workload management, see\n[Design user workload separation](/distributed-cloud/hosted/docs/latest/gdch/resources/workload-separation).\n\nOrganization\n------------\n\nThe organization resource represents an administrative unit or a business\nfunction, such as a company, and is the top-level resource in the\nGDC resource hierarchy. An organization defines a\nsecurity boundary that encloses infrastructure resources to be administered\ntogether so that users can deploy application workloads. Organizations are\nglobal and span all zones in a universe. Within an organization, service\nresources such as VMs and storage volumes are logically grouped by projects.\n\nAll projects, clusters, and service resources belong to your organization\ninstead of their creators. This means that any resource type for an organization\nis not deleted if the user who created it leaves the organization. Instead, all\nresource types follow the organization's lifecycle in\nGDC.\n\nThe IAM access control policies applied to the organization\nresource apply throughout the hierarchy on all resources in the organization.\nFor more information on granting organization-wide policies and permissions, see\nthe [Organization policies](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/org-policy) and\n[IAM](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/iam/set-up-role-bindings) sections.\n\nProject\n-------\n\nA project is a tenancy unit that every service must integrate. Projects provide\nlogical grouping of service resources. Projects are global and span all zones in\na universe.\n\nProjects enable segmentation of service resources within an organization and\nprovide a lifecycle and policy boundary for managing resources. Service\nresources inside a project can never outlive the project itself or move between\nprojects, ensuring that control is available for the life of a resource.\nTherefore, you must deploy resources of any type within a project namespace.\n\nA project is considered a proper Kubernetes namespace that spans across multiple\nclusters in an organization. *Namespace sameness* considers all namespaces of a given name the same\nnamespace for all clusters within the same organization. The single namespace has a\nconsistent owner across the set of clusters. Service providers create\nproject-scoped services by creating control plane and data plane components in\nthe namespace.\n\nThe namespace for a project hosts the following:\n\n- Project-scoped service APIs.\n- Project-level policy configurations, such as roles and role bindings.\n\nYou can attach a project to only a subset of clusters in an\norganization. You can deploy containerized workloads on these clusters within\na project namespace. The namespace sameness concept applies to the project\nnamespace on these clusters. Namespace-scoped policies, such as role-based\naccess (RBAC) policies, apply to all those namespaces.\n\nFor more information on projects, see the\n[Projects overview](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/project-management).\n\nKubernetes cluster\n------------------\n\nA Kubernetes cluster is a set of nodes that run containerized workloads as part\nof GKE on GDC. You can provision Kubernetes clusters to support the\ncompute requirements of your applications. Clusters are organization-scoped,\nand must be attached to one or more projects.\n\nClusters subdivide infrastructure resources into isolated pools to be consumed\nby projects within an organization. Clusters are also logically separated from\neach other to provide different failure domains and isolation guarantees. The\nenforcement of policies per organization ensures clusters can be shared across\nteams and users while also maintaining performance and resource guarantees.\nAdditionally, organization policies enables VM workloads to run alongside container workloads\nwithout introducing operational complexity.\n\nClusters are beneficial for instances where you must deploy containerized\nworkloads. However, with the option to deploy VM-based workloads, the existence\nof a Kubernetes cluster is not required in GDC.\n\nClusters are a zonal resource only and cannot span multiple zones. To operate\nclusters in a multi-zone deployment, you must manually deploy clusters in each\nzone.\n\nFor more information on Kubernetes clusters, see the\n[Manage Kubernetes clusters](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/clusters) section.\n\nService resource\n----------------\n\nService resources include many entities, such as:\n\n- VMs\n- Databases\n- Storage buckets\n- Containerized workloads\n- Backups\n\nService resources must belong to a project, or optionally a cluster for\ncontainerized workloads, and they cannot be shared across projects. This means\nthat service resources inside a project can never outlive the project itself,\nensuring that control is available for the life of the resource.\n\nService resources can be deployed globally or zonally depending on the type.\nReference the specific service's documentation for information on multi-zone\ndeployment options. Service resources are enabled by default and can be disabled\nusing an [organization policy](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/org-policy)."]]