GKE Cluster
What does zop.dev create for GKE Cluster?
zop.dev provisions a GKE cluster with its node pools, Workload Identity enabled, and the platform add-ons installed. Workload Identity is the setting that matters most of the 3: it removes the need for service account JSON keys inside the cluster entirely, so there is no long-lived credential to rotate or leak.
| Field | Value |
|---|---|
| Cloud | gcp |
Google Kubernetes Engine is GCP’s managed Kubernetes. zop.dev provisions a regional cluster with dedicated node pools, managed certificates, DNS, service accounts, and the full monitoring toolchain installed, ready for teams to deploy into.
A regional cluster with its add-ons and identities
Regional GKE cluster (Kubernetes 1.34, cost allocation on, default node pool removed), primary node pool plus optional monitoring pool (tainted workload=monitoring:NoSchedule, default e2-standard-2), load-balancer IP, Certificate Manager cert/map/entries with DNS auth, DNS records (apex A plus wildcard CNAME), 5 service accounts with keys (cloud_monitoring, cluster_autoscaler, karpenter, sql_proxy, wildcard_dns_solver), 3 custom IAM roles, about 16 IAM bindings, and Secret Manager secrets. Helm add-ons: cert-manager, kube-prometheus-stack, grafana, cluster-autoscaler, fluent-bit, kubernetes-event-exporter, karpenter-gcp (helm.zop.dev), prometheus-msteams, reloader, secrets-store-csi-driver, AppDynamics, replicator, metrics-server, ingress-nginx.
Node pool bounds, image type, and Karpenter config
node_config (min > 0, max < 30); monitoring_node_config; karpenter_configs; cluster_deletion_protection; image type ubuntu_containerd; same observability, fluent-bit, certificate, and alert configuration shapes as EKS.A vendored module plus the karpenter-gcp chart
Uses a vendored gke/ module plus a zop.dev-published karpenter-gcp Helm chart for node autoscaling.
Workload Identity replaces service account keys
Without it, a pod that needs Google Cloud access holds a service account JSON key: a long-lived credential mounted as a secret, which then needs rotating and can be exfiltrated.
Workload Identity binds a Kubernetes service account to a Google service account directly, so pods authenticate with short-lived tokens and no key exists anywhere. It is the single largest security improvement available on GKE and it is enabled here by default.
Autopilot versus Standard
Standard gives you node pools you size, patch and pay for by node-hour. Autopilot removes node management entirely and bills per pod resource request.
The economics invert depending on utilisation. Autopilot is cheaper for spiky or poorly-packed workloads because you stop paying for unused node capacity. Standard is cheaper for dense, steady workloads where you can fill the nodes you are already paying for.
The trap with Autopilot is over-requesting: since billing follows requests rather than usage, a pod requesting 4 CPU and using 0.2 pays for 4.
Node pools are where the cost decisions live
Separate pools for different workload shapes: a general pool, a memory-heavy pool, a spot pool for anything interruptible. Spot nodes on GKE run at a substantial discount and can be reclaimed with 30 seconds notice, which is fine for batch and stateless work and wrong for anything holding state.
The control plane bills separately
GKE charges a per-cluster management fee on top of node cost, so many small clusters cost more than fewer larger ones with namespace separation. That is worth weighing before splitting environments across clusters rather than namespaces.