Google Distributed Cloud brings cloud services to diverse physical locations, also known as distributed environments, and can run on premises, public clouds, as well as Google's network edge.
Google Distributed Cloud extends Google Cloud's infrastructure and services to the edge, data center, and multiple clouds.
Google Distributed Cloud offers two distinct solutions:
Google Distributed Cloud Edge (GDC Edge) brings Google Cloud infrastructure and services closer to where data is being generated and consumed.
Google Distributed Cloud Hosted (GDC Hosted) enables you to host, control, and manage infrastructure and services directly on your premises.
Google Distributed Cloud Hosted (GDCH) does not require connectivity to Google Cloud and helps customers meet compliance and regulatory requirements. Key advantages of using the GDCH platform include but are not limited to the following:
- Open: Leveraging open source and commercial off-the-shelf hardware tapping into industry innovation and open ISV ecosystem.
- Intelligence: Based on the Google AI portfolio, enabling real time decisioning and automation in the platform and as a service.
- Consistent: Provides a consistent application experience across Google Cloud, Google edges, operator edges and customer edges, and data centers.
- Modern: Modern Cloud approach based on Google leadership in Kubernetes and GKE Enterprise leading hybrid-cloud solution.
- Proven: Leveraging proven best practices at scale and technologies used for Google core services.
- Secure: Security spanning Core Google Cloud, Google Global Network, Google Edge Infrastructure, and end-user devices.
This section describes the GDCH resource hierarchy and how resources are managed in a GDCH instance.
The purpose of the GDCH resource hierarchy is twofold:
- Provide a hierarchy of ownership, which binds the lifecycle of a resource to its immediate parent in the hierarchy.
- Provide attach points and inheritance for access control and organization policies.
The GDCH resource hierarchy resembles the file system found in traditional operating systems as a way of organizing and managing entities hierarchically. Generally, each resource has exactly one parent. This hierarchical organization of resources enables you to set access control policies, such as Identity and Access Management (IAM), which are inherited by child resources.
Resource structure in detail
The following entities are resource types recognized in the GDCH resource hierarchy:
GDCH resources are organized hierarchically. Most resources in the resource hierarchy have exactly one parent. The exception only applies to the highest resource. At the lowest level, service resources are the fundamental components that make up all GDCH services.
An organization is the top of the GDCH resource hierarchy, and all resources that belong to an organization are grouped under the organization resource. This provides central visibility and control over every resource that belongs to an organization.
Both projects and clusters are organization-scoped. They can be associated with one another to organize service resources. However, projects and clusters function independently from one another. This flexibility provides many different options for how to organize services and workloads. For example, you can have a cluster dedicated to a single project. Likewise, a cluster can span across multiple projects.
Service resources are entities that must belong to a project or a cluster, and cannot be shared across projects or clusters. Examples of service resources include virtual machines (VMs), databases, storage buckets, and backups. Most of these lower-level resources have project resources as their parents.
The following diagram represents an example GDCH resource hierarchy:
For more information on best practices for organizing your resource hierarchy, see the Resource hierarchy and access control guide.
The organization resource represents an organization, such as a company, and is the top-level resource in the GDCH resource hierarchy. An organization defines a security boundary that encloses infrastructure resources to be administered together so that users can deploy application workloads. Within an organization, service resources such as VMs and storage volumes are logically grouped by projects.
All projects, clusters, and service resources belong to your organization instead of their creators. This means that any resource type for an organization is not deleted if the user who created it leaves the organization. Instead, all resource types follow the organization's lifecycle in GDCH.
The IAM access control policies applied to the organization resource apply throughout the hierarchy on all resources in the organization. For more information on granting organization-wide policies and permissions, see the Organization policies and IAM sections.
A project is a tenancy unit that every service must integrate. It provides logical grouping of service resources.
Projects enable segmentation of service resources within an organization and provide a lifecycle and policy boundary for managing resources. Service resources inside a project can never outlive the project itself or move between projects, ensuring that control is guaranteed for the life of a resource.
A project is considered a proper Kubernetes namespace that spans across multiple clusters in an organization. Namespace sameness considers all namespaces of a given name the same namespace for all clusters within the same organization. The single namespace has a consistent owner across the set of clusters. Service providers create project-scoped services by creating control plane and data plane components in the namespace.
The namespace for a project hosts the following:
- Project-scoped service APIs.
- Project-level policy configurations, such as roles and role bindings.
You can associate a project with only a subset of clusters in an organization. Users can deploy containerized workloads on these clusters within a project namespace. The namespace sameness concept applies to the project namespace on these clusters. Namespace-scoped policies, such as role-based access (RBAC) policies, apply to all those namespaces.
For more information on projects, see the Project management section.
A Kubernetes cluster is a set of nodes that run containerized workloads as part of the Kubernetes Cluster Service. Users can provision Kubernetes clusters to support the compute requirements of their applications. Clusters are organization-scoped, and must be associated with one or more projects.
Clusters subdivide infrastructure resources into isolated pools to be consumed by projects within an organization. Clusters are also logically separated from each other to provide different failure domains and isolation guarantees. The enforcement of policies per organization ensures clusters can be shared across teams and users while also maintaining performance and resource guarantees. Additionally, this enables VM workloads to run alongside container workloads without introducing operational complexity.
User clusters are beneficial for instances where users must deploy containerized workloads. However, with the option to deploy VM-based workloads, the existence of a user cluster is not required in GDCH.
For more information on Kubernetes clusters, see the Manage Kubernetes clusters section.
Service resources include the following entities:
- Storage buckets
- Containerized workloads
Service resources must belong to a project, or optionally a cluster for cluster deployments, and they cannot be shared across projects. This means that service resources inside a project can never outlive the project itself, ensuring that control is guaranteed for the life of the resource. Service resources are enabled by default and can be disabled using an organization policy.
The Google Distributed Cloud Hosted (GDCH) architecture is hierarchical and consists of three tiers that map to the following personas:
Infrastructure Operator (IO) has full access to administer the GDCH hardware, not the data or customer applications. IO is responsible for managing and maintaining the infrastructure, hardware, and security of the operational system.
Platform Administrator (PA) manages organization resources, policies, and teams. PA interacts with IO to secure additional bulk resources, get support, plan for upgrades, and request specific configuration changes. PA can create and delete clusters on demand for any of the customers.
Application Operator (AO) has full access to a set of Kubernetes namespaces within a user cluster assigned by a Platform Administrator (PA). AO interacts with PA to secure more resources, get policy exemptions, and troubleshoot larger issues.
The following table introduces major tasks and responsibilities of existing GDCH personas.
|Infrastructure Operator||Platform Administrator||Application Operator|
Before deploying Google Distributed Cloud Hosted (GDCH) on your premises, Google runs a site survey to ensure your location parameters such as space, power, cooling, and connectivity are physically compliant.
Based on your requirements, Google generates a solution design and provides a planning document to the cloud hardware provider that ships the required hardware to your data center.
GDCH hardware comes fully integrated into racks and securely delivered to your premises. We partner with OEM hardware vendors to provide customers with the latest, best-in-class enterprise equipment that is backed by comprehensive services and support.
GDCH can run on minimal hardware to provide flexibility, availability, and performance.
In an isolated environment, you cannot download GDCH binaries directly to a network. Before deploying GDCH on an air-gapped system, it is important to have:
- Internet access to Google Cloud to download the GDCH distribution from.
- A portable storage device to transfer downloaded GDCH to, for example, an external hard drive or a thumb drive.
- On-premise hardware to upload the downloaded files to.
- SHA256 or MD5 checksum to verify the integrity of the downloaded GDCH software.
- Nodes and clusters with enough CPU, RAM, and storage resources to meet the needs of clusters and workloads you are running regardless of your Distributed Cloud Hosted configuration.
- Downloaded GDCH documentation to use offline.
GDCH provides a FIPS 140-2 certified Ubuntu 20.04 long-term support (LTS) operating system (OS) image that runs on GDCH bare metal servers and virtual machines. The certified OS image meets all security and compliance requirements.
Major technical features
Google Distributed Cloud Hosted (GDCH) delivers a multitude of features that let enterprises use the full functionality of a private isolated environment with no internet access.
The extensive collection of GDCH services includes data management, artificial intelligence, machine learning, security, observability, and computing services. GDCH supports both Kubernetes and virtual machine-based workloads.
To build a robust infrastructure and store data across an air-gapped cloud environment, GDCH provides Block and Object storage services. The underlying storage hardware includes high-performing all-flash solutions for Block and more cost-efficient solutions for Object storage.
High availability and data backup
To conform to the data sovereignty requirements, GDCH delivers an integrated backup solution for data recovery and the ability to control data residency either in a local or remote data center.
Highly available and scalable GDCH enables enterprises to perform rolling non-disruptive hardware upgrades as needed.
GDCH provides secure networking and high-speed performance for compute services and cloud storage.
Data plane and Management plane networks connect all cloud components hosted in an on-premises environment to ensure data sovereignty. The networks secure data and enable customers to scale and optimize their infrastructure.
The network load balancing service distributes TCP and UDP traffic among clusters and gives absolute control over handling traffic in the GDCH environment.
The Cloud Support API may not be available for use with GDCH. Consult your account manager for details.