[[["易于理解","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-03。"],[],[],null,["Google Distributed Cloud supports multiple deployment models to meet different\navailability, isolation, and resource footprint needs. This page defines the\nconcepts all deployment models share, and describes each deployment model.\n\nThis page is for Admins and architects and Operators who define IT\nsolutions and system architecture in accordance with company strategy in\ncoordination with key stakeholders. To learn more about common roles and example\ntasks that we reference in Google Cloud content, see\n[Common GKE user roles and tasks](/kubernetes-engine/enterprise/docs/concepts/roles-tasks).\n| **Note:** With Google Distributed Cloud, you can specify one of four types of clusters: admin, user, standalone, or hybrid. These cluster types are key in shaping different deployment models. The cluster type is specified with the [`spec.type`](/kubernetes-engine/distributed-cloud/bare-metal/docs/reference/cluster-config-ref#type) field in the cluster configuration file. This field is immutable. Once you create a cluster, you can't change the type.\n\nUser clusters\n\nA *user cluster* is a Kubernetes cluster that runs your containerized workloads.\nIt consists of *control plane nodes* and *worker nodes* . Google Distributed Cloud\nsupports one or more user clusters. User clusters must contain one or more\nworker nodes that run *user workloads*.\n\nAdmin clusters\n\nAn *admin cluster* is a Kubernetes cluster that manages one or more user\nclusters. Your admin cluster can perform the following tasks:\n\n- Create user clusters\n- Upgrade user clusters\n- Update user clusters\n- Delete user clusters\n\nTo create a user cluster, your admin cluster sets up the Google Distributed Cloud\ncomponents on the user cluster's control plane and worker nodes. Your admin\ncluster only has control plane nodes because the Google Distributed Cloud\ncomponents run on the control plane nodes.\n\nYour admin cluster contains the following types of sensitive data:\n\n- SSH credentials: Used to enable remote installation\n- Google Cloud service account keys: Used to access features like Artifact Registry\n\nTo protect the sensitive data, restrict access to your admin cluster.\n\nHigh availability\n\nYou can run admin or user clusters in [high\navailability](https://en.wikipedia.org/wiki/High_availability) (HA) mode. This\nmode requires three or more (odd number) control plane nodes running in your\ncluster. If you run a cluster in non-HA mode, your cluster requires only one\ncontrol plane node.\n\nTo avoid having a single point of failure, use the HA mode for production\ndeployments. Use the non-HA mode for non-mission critical environments, for\nexample a testing environment, where you can recreate the cluster if the single\ncontrol plane node fails. An HA user cluster must have two or more worker nodes\nin case a worker node fails.\n\nWhen you upgrade your clusters, an HA deployment also reduces the risk of the\ncluster becoming inaccessible if there's an error.\n\nDeployment models\n\nGoogle Distributed Cloud supports the following deployment models to meet\ndifferent requirements:\n\n- [Admin and user cluster deployment](#admin_user_model)\n- [Hybrid cluster deployment](#hybrid_model)\n- [Standalone cluster deployment](#standalone_model)\n\nAdmin and user cluster deployment\n\nUse this deployment model if you have multiple clusters in the same data center\nthat you want to manage from a centralized place, and for larger deployments\nthat need isolation between different teams or between development and\nproduction workloads.\n[](/static/kubernetes-engine/distributed-cloud/bare-metal/docs/installing/images/abm-arch-diagram-admin_user.svg) High-availability admin and user cluster deployment (Click to enlarge)\n\nThis deployment model consists of the following clusters:\n\n- One admin cluster: The central management point that provides an API to manage user clusters. Your admin cluster only runs management components.\n- One or more user clusters: Contain the control plane nodes and the worker nodes, which run user workloads.\n\nThis model meets the following requirements:\n\n- Provides a centralized control plane and API to manage your user clusters' lifecycles.\n- Provides isolation between different teams.\n- Provides isolation between development and production workloads.\n- You don't have to share SSH credentials and service account keys with cluster owners.\n- You can integrate your deployment with your own control planes\n\nFootprint\n\nAn admin and user cluster deployment requires the following nodes:\n\n- Admin cluster\n\n - One control plane node for non-HA\n - Three or more control plane nodes for HA\n- User clusters - You can configure HA for each user cluster independently.\n\n - Control plane nodes:\n\n - One control plane node for non-HA\n - Three or more control plane nodes for HA\n - Worker nodes:\n\n - One or more worker nodes for non-HA\n - Two or more worker nodes for HA\n\nHybrid cluster deployment\n\nThis deployment model is a specialized multi-cluster deployment. A hybrid\ncluster is an admin cluster that can run user workloads. Your hybrid cluster\nstill manages additional user clusters.\n[](/static/kubernetes-engine/distributed-cloud/bare-metal/docs/installing/images/abm-arch-diagram-hybrid.svg) High-availability hybrid cluster deployment (Click to enlarge)\n\nFeatures of this model:\n\n- Allocating a set of machines for an admin cluster is often wasteful because admin clusters use relatively few resources. The hybrid cluster deployment lets you reclaim unused capacity on those machines because it lets you run user workloads within the admin cluster.\n- The admin cluster contains sensitive data such as SSH credentials (used by the admin cluster to manage user clusters on remote machines) and Google Cloud service account keys (used by the admin cluster to access Google Cloud services such as Cloud Storage). Hybrid cluster deployments run user workloads within the admin cluster, and this potentially exposes the admin cluster's sensitive data to user workloads.\n\nFootprint\n\nA hybrid cluster deployment requires the following nodes:\n\n- Hybrid cluster\n\n - Control plane nodes:\n\n - One control plane node for non-HA\n - Three or more control plane nodes for HA\n - Worker nodes:\n\n - One or more worker nodes for non-HA\n - Two or more worker nodes for HA and depending on workload type\n- User clusters - You can configure HA for each user cluster independently.\n\n - Control plane nodes:\n\n - One control plane node for non-HA\n - Three or more control plane nodes for HA\n - Worker nodes:\n\n - One or more worker nodes for non-HA\n - Two or more worker nodes for HA\n\nStandalone cluster deployment\n\nThis deployment model has a single cluster that serves as a user cluster and as an admin cluster.\n[](/static/kubernetes-engine/distributed-cloud/bare-metal/docs/installing/images/abm-arch-diagram-standalone.svg) High-availability standalone cluster deployment (Click to enlarge)\n\nThis model has the following advantages:\n\n- It doesn't require a separate admin cluster\n- It supports the edge profile, which has significantly reduced system resource requirements and is recommended for edge devices with high resource constraints.\n\nThis model has some security tradeoffs, because workloads can run on a cluster\nwith the following sensitive data:\n\n- SSH credentials\n- Google Cloud service account keys\n\nUse this model if you meet any of the following conditions:\n\n- You manage every cluster independently.\n- You have a small number of worker nodes.\n- You support a single team.\n- You run a single workload type.\n\nThis model works well in the following situations:\n\n- Every cluster is independently managed with different SSH keys and Google Cloud credentials\n- Clusters run in network isolated partitions, separated from untrusted networks\n- Clusters run in edge locations\n\nFootprint\n\nA standalone cluster deployment requires the following nodes:\n\n- Control plane nodes:\n\n - One control plane node for non-HA\n - Three or more control plane nodes for HA\n- Worker nodes:\n\n - One or more worker nodes for non-HA\n - Two or more worker nodes for HA\n\nEdge profile\n\nStandalone clusters support an *edge profile* , which minimizes resource\nconsumption for the cluster. You enable the edge profile when you create a\nstandalone cluster by setting\n[`profile`](/kubernetes-engine/distributed-cloud/bare-metal/docs/reference/cluster-config-ref#profile) in the cluster\nconfiguration file to `edge`. The edge profile is recommended for edge devices\nwith restrictive resource constraints. For hardware requirements associated with\nthe edge profile, see\n[Resource requirements for standalone clusters using the edge profile](/kubernetes-engine/distributed-cloud/bare-metal/docs/installing/node-machine-prerequisites#resource_requirements_for_standalone_clusters_using_the_edge_profile).\n\nIn a standalone cluster configured to use the edge profile, the *control plane\nnodes are automatically configured to accept user workloads* . This means you\ndon't need a worker node pool. However, reducing the footprint by running\nworkloads on the control plane weakens security and resource isolation between\nthe control and data planes. If the reduced footprint is worth this trade-off,\nyou can configure a standalone cluster with the edge profile to run on a\n[single control plane node](/kubernetes-engine/distributed-cloud/bare-metal/docs/reference/config-samples#edge-basic) or\non [multiple control plane nodes](/kubernetes-engine/distributed-cloud/bare-metal/docs/reference/config-samples#edge-ha)\nfor high availability.\n| **Note:** If you require a small footprint for edge use cases, but you would prefer to have Google to manage the hardware, consider [Google Distributed Cloud\n| connected](/distributed-cloud/edge/latest/docs/overview). With Google Distributed Cloud connected, Google delivers, installs, and maintains the Distributed Cloud hardware on your premises."]]