A Kubernetes cluster is a unit for running and managing containerized workloads. Clusters may be deployed in Google Cloud, other clouds, on bare metal, or at the edge. Automated creation lowers the barrier to deployment, but administrators still need to understand how cluster components interact to troubleshoot failures; developers need to understand the resources and scheduling rules that govern their workloads. section 3.0 section 2.4.4 section 8.3.1
Separate a cluster’s architecture from decisions about where and how many clusters to run:
- In a Google Distributed Cloud Edge deployment, the control plane runs in a GCP region, while physical worker nodes at the customer site are grouped into node pools. A zone is a failure domain; applications needing protection against zone failures must span multiple zones in the same region. section 8.3.1
- Multiple smaller clusters, such as clusters per team, contrast with fewer larger clusters, such as separate Dev, Test, and Prod clusters. Choose according to deployment practices, geography, data-location requirements, and operational capacity rather than assuming one layout is best. section 11.1.1
- Across a fleet, inspect location, type, labels, warnings, Kubernetes version, available CPU and memory, and enabled features. Plan routine logging, monitoring, upgrades, and scaling alongside workload deployment. section 2.4.4 section 5.7
Targeted rollout across local clusters
For restaurant clusters managed with Anthos Config Management, give each cluster a distinct registry name and labels for country, region, and rollout status. Define nonoverlapping ClusterSelectors for testers and non-testers, then annotate separate Deployments to send a newer image to testers and the established image elsewhere. A country selector can restrict a location-specific application to eligible clusters. Check selector overlap: otherwise two deployments intended for different groups can target the same cluster. section 11.3.3
---
kind: ClusterSelector
apiVersion: configmanagement.gke.io/v1
metadata:
name: rollout-testers
spec:
selector:
matchLabels:
is-rollout-tester: true
---
kind: ClusterSelector
apiVersion: configmanagement.gke.io/v1
metadata:
name: non-testers
spec:
selector:
matchExpressions:
- key: is-rollout-tester
operator: DoesNotExist
---
kind: ClusterSelector
apiVersion: configmanagement.gke.io/v1
metadata:
name: country-us
spec:
selector:
matchLabels:
country: us
The ClusterSelector definitions show how label matches and a missing-label expression divide tester, non-tester, and country-specific clusters. section 11.3.3
A cluster is also a deployment destination: a Marketplace installation can select a GKE cluster and namespace before placing Elasticsearch there. After deployment, cluster-level CPU, memory, and disk information helps operators assess the result. Declarative fleet management can reduce repeated configuration work across on-premises and cloud clusters, but it does not replace understanding the underlying components. section 14.2.1 section 11.4 section 3.0
