Google Distributed Cloud Edge overview

Google Distributed Cloud Edge enables you to run Kubernetes 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.

Deploy workloads on 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 using the Google Cloud console in a way similar to provisioning Kubernetes-based Clusters. Your application owners can then deploy workloads to those Clusters.

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 can access Google Cloud services and your applications running within Google Cloud and your Virtual Private Cloud through a secure Cloud VPN connection.

See How Distributed Cloud Edge works for a technical overview of Distributed Cloud Edge.

When to use Distributed Cloud Edge

Distributed Cloud Edge is specifically designed to address the following scenarios in which conventional Google Cloud deployments may 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 and/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.
  • Workload restrictions. Distributed Cloud Edge places a number of restrictions on your workloads, as described in Limitations for Distributed Cloud Edge workloads.
  • Anthos features. Distributed Cloud Edge does not support Anthos features such as Anthos Service Mesh or Anthos Config Management.
  • KubeVirt namespace restriction. To deploy a KubeVirt virtual machine on Distributed Cloud Edge, you must patch its target namespace when you first create it, and refresh the associated secret each time you start it. For more information, see Manage virtual machines.

Known issues in this release of Distributed Cloud Edge

This release of Distributed Cloud Edge has the following known issues:

  • NodePort Service is not supported. This release of Distributed Cloud Edge only supports the LoadBalancer and ClusterIP Kubernetes Services. The NodePort Service is not supported.
  • The Kubernetes control planes associated with Distributed Cloud Clusters can briefly go down during Distributed Cloud Cluster software updates.
  • 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.

What's next