Stay organized with collections
Save and categorize content based on your preferences.
This page provides an overview of Google Distributed Cloud Edge, including
information about when to use it and its limitations and known issues.
Distributed Cloud Edge enables you to run
Google Kubernetes Engine (GKE) clusters on dedicated hardware provided and
maintained by Google that is separate from
the traditional Google Cloud data center. Google delivers and installs the
Distributed Cloud Edge hardware on your premises.
Deploying workloads on a Distributed Cloud Edge installation
functions in a similar way to deploying workloads on cloud-based
GKE clusters. After the hardware has been deployed, your cluster
administrator provisions Distributed Cloud Edge clusters by using
the Google Cloud console or the Google Cloud CLI. In addition, your network
administrator configures the Distributed Cloud Edge
networking components so that your workloads can communicate with your local
network and each other. Your application owners can then deploy workloads to
those clusters. Distributed Cloud Edge
supports running workloads in Kubernetes containers and on virtual machines,
including GPU-based workloads, which run on NVIDIA Tesla T4 GPUs.
Google remotely monitors and maintains your
Distributed Cloud Edge installation, which includes installing
software updates and security patches, resolving configuration issues, and
diagnosing the Distributed Cloud Edge hardware. To resolve an
issue that can't be resolved remotely, you must provide Google's
authorized personnel physical access to the
Distributed Cloud Edge hardware.
Your Distributed Cloud Edge deployment uses a secure Cloud VPN
connection to access Google Cloud services and your applications that run
within Google Cloud and your Virtual Private Cloud (VPC) network.
Distributed Cloud Edge is specifically designed to address the
following scenarios in which conventional Google Cloud deployments might
not be sufficient:
Your applications require a very stable network connection and cannot tolerate
potential traffic disruptions that commonly occur when transferring data over
the internet.
Your applications require the lowest attainable network latency and are
sensitive to latency spikes or jitter. Distributed Cloud Edge
also supports high-performance network technologies such as single root
input/output virtualization (SR-IOV) and the Data Plane Development Kit (DPDK)
for even more advanced scenarios that utilize the
Network function operator.
Your applications generate large amounts of data that would be
performance-prohibitive or cost-prohibitive to transfer to and from
Google Cloud.
Your local laws or regulations dictate that your data must remain on-premises
and must not be stored either outside of your business or outside of a
specific geographic jurisdiction.
Limitations of Distributed Cloud Edge
A Distributed Cloud zone has the following limitations compared
to a conventional cloud-based GKE zone:
Processing capacity. Unlike a conventional cloud-based zone, your
Distributed Cloud Edge installation has limited processing
capacity. Be mindful of this limitation when planning and deploying your
workloads.
GKE Enterprise features. Distributed Cloud Edge does not
support GKE Enterprise features such as Cloud Service Mesh
except for the ConfigSync feature of Config Management.
Known issues in this release of Distributed Cloud Edge
This release of Distributed Cloud Edge has the following known
issues:
A large number of webhook calls might cause the Konnectivity proxy to
temporarily fail.
The metrics agents running on Distributed Cloud Edge nodes can
accumulate a backlog of events and stall, preventing the capture of further
metrics.
Garbage collection intermittently fails to clean up terminated Pods.
BGP sessions do not recover when the corresponding network interface goes down
and then comes back up.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-09-04 UTC."],[[["\u003cp\u003eDistributed Cloud Edge provides on-premises Google Kubernetes Engine (GKE) clusters on dedicated hardware maintained by Google, separate from traditional Google Cloud data centers.\u003c/p\u003e\n"],["\u003cp\u003eIt addresses scenarios requiring stable network connections, low latency, or where data must remain on-premises due to performance, cost, or regulatory constraints.\u003c/p\u003e\n"],["\u003cp\u003eWorkloads on Distributed Cloud Edge function similarly to cloud-based GKE clusters and can run in Kubernetes containers or on virtual machines, including GPU-based applications.\u003c/p\u003e\n"],["\u003cp\u003eGoogle remotely monitors and maintains the Distributed Cloud Edge installation, including updates, security patches, and hardware diagnostics, but physical access may be required for certain issues.\u003c/p\u003e\n"],["\u003cp\u003eDistributed Cloud Edge has limitations in processing capacity, workload restrictions, and support for GKE Enterprise features, and has known issues like temporary Konnectivity proxy failures and stalled metrics agents.\u003c/p\u003e\n"]]],[],null,["# Google Distributed Cloud Edge overview\n\nThis page provides an overview of Google Distributed Cloud Edge, including\ninformation about when to use it and its limitations and known issues.\n\nDistributed Cloud Edge enables you to run\nGoogle Kubernetes Engine (GKE) clusters on dedicated hardware provided and\nmaintained by Google that is separate from\nthe traditional Google Cloud data center. Google delivers and installs the\nDistributed Cloud Edge hardware on your premises.\n\nDeploying workloads on a Distributed Cloud Edge installation\nfunctions in a similar way to deploying workloads on cloud-based\nGKE clusters. After the hardware has been deployed, your cluster\nadministrator provisions Distributed Cloud Edge clusters by using\nthe Google Cloud console or the Google Cloud CLI. In addition, your network\nadministrator configures the Distributed Cloud Edge\nnetworking components so that your workloads can communicate with your local\nnetwork and each other. Your application owners can then deploy workloads to\nthose clusters. Distributed Cloud Edge\nsupports running workloads in Kubernetes containers and on virtual machines,\nincluding GPU-based workloads, which run on NVIDIA Tesla T4 GPUs.\n\nGoogle remotely monitors and maintains your\nDistributed Cloud Edge installation, which includes installing\nsoftware updates and security patches, resolving configuration issues, and\ndiagnosing the Distributed Cloud Edge hardware. To resolve an\nissue that can't be resolved remotely, you must provide Google's\nauthorized personnel physical access to the\nDistributed Cloud Edge hardware.\n\nYour Distributed Cloud Edge deployment uses a secure Cloud VPN\nconnection to access Google Cloud services and your applications that run\nwithin Google Cloud and your Virtual Private Cloud (VPC) network.\n\nFor a technical overview of Distributed Cloud Edge, see\n[How Distributed Cloud Edge works](/distributed-cloud/edge/1.5.1/docs/how-it-works).\n\nWhen to use Distributed Cloud Edge\n----------------------------------\n\nDistributed Cloud Edge is specifically designed to address the\nfollowing scenarios in which conventional Google Cloud deployments might\nnot be sufficient:\n\n- Your applications require a very stable network connection and cannot tolerate potential traffic disruptions that commonly occur when transferring data over the internet.\n- Your applications require the lowest attainable network latency and are\n sensitive to latency spikes or jitter. Distributed Cloud Edge\n also supports high-performance network technologies such as single root\n input/output virtualization (SR-IOV) and the Data Plane Development Kit (DPDK)\n for even more advanced scenarios that utilize the\n [Network function operator](/distributed-cloud/edge/1.5.1/docs/network-function).\n\n- Your applications generate large amounts of data that would be\n performance-prohibitive or cost-prohibitive to transfer to and from\n Google Cloud.\n\n- Your local laws or regulations dictate that your data must remain on-premises\n and must not be stored either outside of your business or outside of a\n specific geographic jurisdiction.\n\nLimitations of Distributed Cloud Edge\n-------------------------------------\n\nA Distributed Cloud zone has the following limitations compared\nto a conventional cloud-based GKE zone:\n\n- **Processing capacity.** Unlike a conventional cloud-based zone, your Distributed Cloud Edge installation has limited processing capacity. Be mindful of this limitation when planning and deploying your workloads.\n- **Workload restrictions.** Distributed Cloud Edge [places several restrictions on your\n workloads](/distributed-cloud/edge/1.5.1/docs/deploy#workload-limitations).\n- **GKE Enterprise features.** Distributed Cloud Edge does not support GKE Enterprise features such as Cloud Service Mesh except for the ConfigSync feature of Config Management.\n\nKnown issues in this release of Distributed Cloud Edge\n------------------------------------------------------\n\nThis release of Distributed Cloud Edge has the following known\nissues:\n\n- A large number of webhook calls might cause the Konnectivity proxy to temporarily fail.\n- The metrics agents running on Distributed Cloud Edge nodes can accumulate a backlog of events and stall, preventing the capture of further metrics.\n- Garbage collection intermittently fails to clean up terminated Pods.\n- BGP sessions do not recover when the corresponding network interface goes down and then comes back up.\n\nWhat's next\n-----------\n\n- [How Distributed Cloud Edge works](/distributed-cloud/edge/1.5.1/docs/how-it-works)"]]
