This document explains the configuration options available for your Kubernetes clusters. You can create Kubernetes clusters that function within a single project, or span across multiple projects, to align with your strategy for managing container workloads in Google Distributed Cloud (GDC) air-gapped. Cluster configurations also offer different permissions-based controls for administrative actions, so your container workload settings can be managed by GDC or manually configured based on your use case for more flexibility.
This document is for IT administrators within the platform administrator group who are responsible for creating Kubernetes clusters to host container workloads, and application developers within the application operator group who are responsible for developing container applications in an air-gapped environment. For more information, see Audiences for GDC air-gapped documentation.
Configuration options
In GDC, there are two cluster configurations that offer different levels of management and flexibility:
- Shared cluster: A multi-project Kubernetes cluster managed by the platform administrator group that offers a full suite of integrated and managed services on the organization level.
- Standard cluster: A single-project, self-service Kubernetes cluster managed by the application operator group that offers greater flexibility for custom workloads that might conflict with the managed services in a shared environment.
The following table describes the differences between the shared and standard Kubernetes clusters:
| Feature | Shared clusters | Standard clusters |
|---|---|---|
| Owner | Platform administrator group | Application operator group |
| Cluster administrator | Platform administrator group | Platform administrator group or application operator group |
| Tenancy | Multiple projects | Single project |
| Lifecycle Management | Create, Read, Update, Delete, and Upgrade | Create, Read, Update, Delete, and Upgrade |
| Monitoring | Prometheus with Grafana Dashboards for Kubernetes | Prometheus with Grafana Dashboards for Kubernetes |
| Ingress and egress across projects | Managed by GDC | Configurable |
| Backup and restore | Cluster, project, and workload | Cluster, project, and workload |
| Kubernetes namespace management | Managed by GDC | Configurable |
| Custom resource and controller | Managed by GDC | Configurable |
| Logging | Managed by GDC | Managed by GDC |
| Audit and Billing | Managed by GDC | Configurable |
| Resource type | Zonal only | Zonal only |
| Surface support | GDC console, API, and Terraform | API and Terraform |
| Managed services | Includes a comprehensive set of protected services that are not configurable. | Includes a minimal set of essential services, providing more service flexibility. |
| Marketplace services | Includes seamless integration with marketplace services. | Not available for integration. |
For more information, see the following cluster configuration sections.
Shared cluster
The shared cluster provides a system-managed cluster that includes a
comprehensive set of protected services, such as Istio, Gatekeeper, Managed
Harbor Service, Nginx, and more. The system-managed approach for your cluster
provides an opinionated Kubernetes cluster configuration that runs in the
platform namespace, and can attach to any of your existing projects.
Because the shared cluster can span multiple projects, it is organization-scoped, which means its availability to some audience groups is limited. The platform administrator group is primarily tasked with creating and managing the shared cluster with very little oversight from an application developer.
Cross-project ingress and egress networking traffic is managed by GDC. Networking policies are typically handled using a project network policy.
The primary use cases for the shared cluster are the following:
- You need a cluster that offers a full ecosystem of managed capabilities by default with little customization required.
- You want to manage your container workloads across multiple projects.
- You have no requirements for migrating workloads from existing cloud environments.
For more information about creating a shared cluster, see Create a shared cluster.
Standard cluster
The standard cluster provides a configurable Kubernetes cluster that includes a minimal set of services, such as Prometheus and Grafana. Only essential services are included to provide necessary Kubernetes container workload functionality, letting you install your own additional services to customize the cluster based on your use case.
The standard cluster is scoped within a project only, which gives application developers that are confined within a project direct control over how it functions. The application operator group is primarily tasked with creating and managing the shared cluster with very little oversight needed from platform administrators.
Cluster networking is controlled by application developers using standard Kubernetes networking APIs in many cases, instead of the reliance on GDC-specific networking configurations. However, standard clusters can configure a subset of GDC-specific networking configurations, such as the following:
- Policies
- Load balancing
- Cloud NAT
The primary use cases for the standard cluster are the following:
- You need a cluster that offers minimal services by default, which allows for comprehensive configurations to fit your needs.
- You want more control over deeper Kubernetes constructs like custom resource definitions or namespaces.
- You want to manage your container workloads within a single project only.
- You have existing container workloads on an existing cloud environment you want to migrate into your GDC air-gapped environment.
For more information about creating a standard cluster, see Create a standard cluster.