Google Kubernetes Engine (GKE)

The problem it solves

Kubernetes is made of two parts: the control plane, that is the API server, the scheduler, the controllers and the etcd database that holds the state of the cluster, and the nodes, the machines where the containers run. Running a highly available cluster is a project in its own right: redundancy, backups, certificates and version upgrades all have to be taken care of. Kubernetes was born at Google, out of the internal experience with Borg, and GKE was the first managed service to offer it, in 2015. GKE runs the control plane on your behalf, replicates it, upgrades it and backs it with an SLA; in Autopilot mode it manages the nodes as well.

Shared responsibility

In Autopilot the node is managed automatically: you pay for the vCPUs, memory and ephemeral storage that the pods request, per second, and Google takes care of packing them onto ephemeral machines. A pod that declares no requests receives 0.5 vCPU and 2 GiB of RAM by default, and requests below the allowed minimums are raised automatically. Workloads that need specific hardware, GPUs, TPUs or a given machine family, are billed per node instead, with a management premium.

Standard remains for the cases Autopilot does not cover: Windows nodes, agents that need system privileges, a custom kernel, or when you want finer control over the node lifecycle, since Autopilot tends to consolidate nodes aggressively, causing a fair number of pod evictions unless precautions are taken. Since September 2025 the two modes are no longer an either-or choice: a Standard cluster can run workloads in Autopilot mode by selecting a dedicated compute class, and the boundary moves pod by pod.

How it works

Clusters are VPC-native: pods and Services get addresses from secondary ranges of the subnet, and the ranges are best designed up front. To expose services, GKE has its own controller that supports the Gateway API and creates Google Cloud load balancers.

The cluster accepts Google Cloud IAM identities directly. Administrators sign in with their own account, and pods that need to call Google APIs use Workload Identity Federation, which binds a Kubernetes service account to an IAM identity. Access to the API server can be restricted to the private network, and since 2025 there is a per-cluster DNS endpoint protected by IAM, which removes the need for bastions and VPNs.

Standard clusters can be zonal, with a single control plane, or regional, with the control plane replicated across several zones. The SLA is 99.5% for the former and 99.95% for the latter, and during an upgrade the zonal control plane is unreachable. Autopilot is always regional.

Version upgrades

This is where GKE stands apart. The control plane upgrades itself, always. Nodes upgrade themselves in Autopilot and by default in Standard. The pace is set by the release channel: Rapid follows Kubernetes within one or two weeks, Regular, the default channel, at about two months, Stable three or four months after Regular. The Extended channel lets you stay on a version for up to 24 months, but beyond the 14 months of standard support the control plane fee goes up.

What remains under the customer's control is the when: maintenance windows, and exclusions that pause upgrades. A full exclusion lasts at most 90 days; one that blocks only minor version jumps can last longer.

Google Cloud in Italy

Google Cloud has two regions in Italy: Milan, europe-west8, and Turin, europe-west12. GKE is available in both. The usual caveat for small regions applies: GPUs and recent machine families arrive elsewhere first, so check availability before committing to a region.

Where to start

In GKE projects I usually follow these steps:

1. Project and network before the cluster. Organization of the Google Cloud projects, network design with properly sized VPCs, private access to the control plane.
2. Everything in Terraform (or another Infrastructure as Code tool), clusters and node pools included.
3. Gateway API instead of Ingress for new clusters.
4. GitOps releases and observability from day one.
5. Maintenance windows agreed with whoever runs the system, so that automatic upgrades never come as a surprise.

Maturity

I have worked on Google Cloud and on GKE for years. The service is stable and mature. If you are evaluating Kubernetes on Google Cloud, or want to review a cluster you already have, the Kubernetes consulting and cloud consulting pages explain how I work.