Cloud / Google Kubernetes Engine (GKE) Interview questions

Google Kubernetes Engine (GKE) is Google Cloud's managed Kubernetes service. You describe workloads with standard Kubernetes objects, and Google runs, patches and scales the control plane for you.

On top of upstream Kubernetes you get:

• A managed control plane (API server, etcd, scheduler, controller manager)
• Node pools backed by Compute Engine VMs, or fully managed nodes in Autopilot
• Built-in integration with Cloud IAM, VPC, Cloud Load Balancing, Cloud Logging and Cloud Monitoring
• Automatic upgrades, node auto-repair and autoscaling

Since GKE is a certified Kubernetes distribution, the same manifests and kubectl commands you use elsewhere work unchanged.

A GKE cluster has two parts: the control plane and the nodes.

Add-ons such as CoreDNS, the metrics agent and the logging agent run as Pods on the nodes, so they consume some node capacity.

GKE offers Autopilot and Standard modes.

In Autopilot, Google manages the control plane and the nodes. You deploy Pods and are billed for the resources the Pods request. Node sizing, scaling and upgrades are handled for you, and security defaults are locked down.

In Standard, Google manages only the control plane. You choose machine types, create node pools, tune autoscaling and pay for the VMs whether or not Pods fill them.

Pick Autopilot for least operational work and Standard when you need node-level control, such as custom kernel settings or privileged workloads.

GKE Autopilot is a mode where Google provisions, scales, upgrades and secures the nodes for you. You only define Pods, and capacity appears based on what they request.

Key characteristics:

• Billing is based on the vCPU, memory and ephemeral storage requested by running Pods (in the default model)
• Clusters are regional, VPC-native and use Workload Identity Federation by default
• Hardened defaults: no privileged containers and limited host access
• Resource requests are mandatory in practice, because Autopilot sizes capacity from them

Because node access is restricted, DaemonSets that need host-level privileges or SSH-based debugging may not work.

A node pool is a group of nodes in a cluster that share the same configuration: machine type, disk, labels, taints, image type and Kubernetes version.

A cluster can have several pools, which lets you mix workloads. For example, a general-purpose pool for web Pods, a high-memory pool for caches, and a GPU pool for training jobs.

Each pool can be autoscaled, upgraded and repaired independently. You steer Pods to a pool with nodeSelector, node affinity or taints and tolerations.

gcloud container node-pools create highmem-pool \
  --cluster=demo --region=us-central1 \
  --machine-type=n2-highmem-4 --num-nodes=1

Release channels control how quickly your cluster receives new Kubernetes versions and patches. You subscribe a cluster to a channel and GKE upgrades it automatically within that channel's rules.

A common pattern is Rapid for a sandbox, Regular for staging and Stable for production, so version problems surface early.

Use gcloud container clusters create-auto for Autopilot or gcloud container clusters create for Standard.

# Autopilot
gcloud container clusters create-auto demo-auto \
  --region=us-central1

# Standard, regional, 1 node per zone
gcloud container clusters create demo-std \
  --region=us-central1 --num-nodes=1 \
  --release-channel=regular

Make sure the Kubernetes Engine API is enabled in the project first (gcloud services enable container.googleapis.com). Passing --zone instead of --region creates a zonal cluster.

Autopilot clusters are always regional, so create-auto takes a region. Add --network and --subnetwork to place the cluster in an existing VPC instead of the default network.

Run gcloud container clusters get-credentials. It writes a context for the cluster into your kubeconfig, and kubectl uses it from then on.

gcloud container clusters get-credentials demo-std \
  --region=us-central1 --project=my-project

kubectl get nodes

Authentication is handled by the gke-gcloud-auth-plugin, which turns your gcloud identity into a short-lived token. If kubectl complains about a missing plugin, install it with gcloud components install gke-gcloud-auth-plugin.

For private clusters your IP must also be allowed by the control plane's authorized networks, or you must connect from inside the VPC.

Use kubectl config get-contexts to list the clusters in your kubeconfig and kubectl config use-context to switch between them. The token is refreshed automatically, so there is no long-lived password to manage.

A VPC-native cluster uses alias IP ranges: Pod IPs and Service IPs come from secondary ranges on the cluster's subnet, so they are real, routable addresses inside your VPC.

Benefits:

• Pod IPs are natively routable, with no custom routes needed
• Pods can be reached by other VPC resources and over VPN or Interconnect
• Enables container-native load balancing with NEGs
• VPC firewall rules and flow logs apply cleanly to Pod traffic

It is the default for new clusters, and Autopilot is always VPC-native. The older routes-based mode relied on custom routes and is limited by route quotas.

GKE supports the standard Kubernetes Service types, and each maps to specific Google Cloud behavior.

For HTTP(S) routing, use Ingress or the Gateway API instead of one LoadBalancer Service per app.

GKE Ingress is the built-in controller that turns a Kubernetes Ingress resource into a Google Cloud Application Load Balancer (Layer 7). The controller runs in the Google-managed control plane, so you do not install anything.

Creating an Ingress provisions a forwarding rule, target proxy, URL map and backend services. Host and path rules in the Ingress become URL map entries.

Customize behavior with:

• BackendConfig for health checks, timeouts, Cloud CDN, IAP and Cloud Armor
• FrontendConfig for HTTPS redirects and SSL policies
• ManagedCertificate for Google-managed TLS certificates

The Gateway API is the newer, role-oriented successor to Ingress. GKE implements it with a Gateway controller that creates Google Cloud load balancers.

It splits responsibilities across resources:

1. GatewayClass - the load balancer type, such as gke-l7-global-external-managed
2. Gateway - the listener and address, owned by the platform team
3. HTTPRoute - host, path and header rules, owned by app teams

Compared with Ingress it supports traffic splitting, header-based routing, cross-namespace routes and multi-cluster Gateways without vendor annotations.

In practice, a platform team defines one shared Gateway with HTTPS listeners, and each application team attaches its own HTTPRoute, so teams can ship routing changes without touching shared load balancer settings.

Container-native load balancing lets a Google Cloud load balancer send traffic straight to Pod IPs using Network Endpoint Groups (NEGs), instead of sending it to nodes first.

Without it, traffic hits a node's NodePort and kube-proxy may forward it to a Pod on a different node, adding a hop and obscuring the client IP. With NEGs, the load balancer health-checks each Pod and balances evenly across them.

You enable it per Service with the annotation below. It requires a VPC-native cluster.

metadata:
  annotations:
    cloud.google.com/neg: '{"ingress": true}'

Workload Identity Federation for GKE (formerly Workload Identity) lets Pods call Google Cloud APIs using their Kubernetes identity, with no exported service account keys.

You grant IAM roles directly to the Kubernetes ServiceAccount principal, or let the KSA impersonate a Google service account. Credentials are short-lived tokens issued at runtime.

It beats key files because there is nothing to leak, rotate or mount as a Secret, and each Pod can have its own least-privilege identity instead of inheriting the node's service account.

GKE supports several storage back ends, mostly through CSI drivers.

Persistent Disks are zonal (or regional for replicated disks), so a Pod using one must schedule in the disk's zone. Use volumeBindingMode: WaitForFirstConsumer to avoid zone mismatches.

In a private cluster, nodes get only internal IP addresses, so they are not reachable from the internet. Pods that need outbound access, such as pulling public images, go through Cloud NAT, or use Private Google Access for Google APIs.

The control plane endpoint can be public (restricted by authorized networks), or private only. With a private endpoint, you reach it from inside the VPC, over VPN or through a bastion.

It reduces attack surface because the nodes cannot be probed directly. The trade-off is added networking setup for egress and admin access.

Shielded GKE Nodes run on Shielded VMs with three protections:

• Secure Boot - only signed boot components load
• vTPM - a virtual trusted module that records boot measurements
• Integrity monitoring - compares boot state against a known-good baseline

They also help GKE verify that a node requesting cluster credentials is a genuine node of that cluster, which limits the damage from a stolen bootstrap credential. They are enabled by default on current clusters.

The integrity results appear in Cloud Logging and Monitoring, so you can alert when a node fails its integrity check.

Binary Authorization is a deploy-time control that lets only trusted container images run in a cluster. A policy decides which images are allowed, and GKE's admission control enforces it.

Typical flow: your CI pipeline builds an image, scans it, and an attestor signs an attestation. At deploy time the policy checks for the required attestations, and rejects the Pod otherwise.

It also supports a dry-run mode that logs violations without blocking, and a break-glass annotation for emergencies. It protects the supply chain by ensuring images came through your approved pipeline.

A zonal cluster has one control plane in one zone. A regional cluster runs three control plane replicas across three zones and spreads nodes across them too.

Choose regional for production. Note that --num-nodes=3 on a regional cluster means three nodes per zone, so nine in total.

The core difference is who owns the nodes. In Autopilot Google does; in Standard you do.

Autopilot avoids paying for idle node capacity, while Standard can be cheaper when you keep nodes densely packed or use committed use discounts well.

The cluster autoscaler adds or removes nodes in a node pool based on Pod demand, within the pool's minimum and maximum size.

Scale up: when the scheduler cannot place a Pod because no node has enough requested CPU or memory, the Pod stays Pending and the autoscaler adds a node that would fit it.

Scale down: when a node's requested resources stay below a threshold for a period, the autoscaler drains it, respecting Pod Disruption Budgets, and deletes it.

Decisions use requests, not actual usage, so unrealistic requests lead to waste or stuck Pending Pods. The optimize-utilization profile scales down more aggressively than balanced.

flowchart LR
  A["Pod Pending: no node fits"] --> B["Autoscaler simulates new node"]
  B --> C["Node added to pool"]
  C --> D["Pod scheduled"]
  D --> E{Node underused for a while?}
  E -- Yes --> F["Drain and delete node"]
  E -- No --> D

HPA changes the number of Pod replicas. VPA changes the size (CPU and memory requests) of each Pod.

Do not let HPA and VPA both act on the same CPU or memory metric, as they will fight. A common safe pairing is VPA in recommendation mode with HPA doing the actual scaling.

Node auto-provisioning (NAP) lets Standard clusters create and delete entire node pools automatically, choosing machine shapes that fit pending Pods.

The regular cluster autoscaler only resizes pools that already exist. NAP goes further: if a Pod requests a GPU or a large amount of memory that no existing pool can serve, it creates a suitable pool, then removes it when empty.

You set cluster-wide limits (total CPU, memory, accelerators) so cost cannot run away. Autopilot behaves similarly by design, since it always provisions nodes to match Pods.

Auto-upgrade keeps nodes on the version allowed by the cluster's release channel. When the control plane upgrades, nodes follow in a rolling manner, within your maintenance window.

Auto-repair checks node health. If a node reports NotReady (or fails checks) for about 10 minutes, GKE drains and recreates it.

You can steer timing with maintenance windows (when upgrades may start) and maintenance exclusions (periods like a holiday freeze when they must not). Both are on by default in Autopilot and recommended in Standard.

Both are node pool upgrade strategies. They differ in how replacement nodes are rolled in.

Surge upgrade (default) upgrades nodes in a rolling fashion. maxSurge adds extra nodes temporarily and maxUnavailable limits how many can be down at once. Defaults are surge 1, unavailable 0.

Blue-green upgrade creates a full second ("green") set of nodes, cordons the old ("blue") set, drains it gradually, and keeps blue for a soak period so you can roll back.

Blue-green gives safer rollback but temporarily needs about double the capacity, so it costs more and needs quota headroom.

They are two permission layers, and GKE checks both. Cloud IAM controls who can manage the cluster itself and, via roles such as roles/container.developer, can also grant access to Kubernetes objects. Kubernetes RBAC controls what a user or ServiceAccount can do inside the cluster, per namespace.

Authorization is additive: a request is allowed if either IAM or RBAC permits it. That means a broad IAM role can quietly override a tight RBAC setup.

Good practice is to give people minimal IAM (for example roles/container.clusterViewer so they can fetch credentials) and grant day-to-day permissions through RoleBindings, ideally bound to Google Groups.

Kubernetes NetworkPolicy objects only take effect if the cluster has a policy engine enabled. On GKE you get one by using Dataplane V2 (Cilium-based, always on in Autopilot) or by enabling Calico network policy.

A good starting pattern is a default-deny rule for a namespace, then explicit allows:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: payments
spec:
  podSelector: {}
  policyTypes:
  - Ingress

Without an enforcing engine the object is accepted but silently does nothing, which is a common audit finding.

Dataplane V2 is GKE's eBPF-based networking dataplane built on Cilium. It replaces the kube-proxy and iptables approach for Service routing and brings policy enforcement into the same layer.

What you gain:

• Built-in Kubernetes NetworkPolicy enforcement, no Calico add-on
• Network policy logging to see allowed and denied connections
• Better scaling with many Services, since eBPF maps replace long iptables chains

It is always enabled on Autopilot. On Standard it is chosen at cluster creation, and an existing cluster generally cannot switch to it, so decide early.

Use Spot VMs for fault-tolerant, interruptible work such as batch jobs, CI runners, rendering and stateless workers that can retry. They are heavily discounted, but Compute Engine can reclaim them at any time with only about 30 seconds' notice.

Avoid them for single-replica databases or anything that cannot tolerate sudden loss.

Practical setup: create a separate Spot node pool, then schedule Pods onto it with the built-in label:

nodeSelector:
  cloud.google.com/gke-spot: "true"
terminationGracePeriodSeconds: 25

Keep a regular on-demand pool for critical Pods, and use Pod Disruption Budgets plus replicas so a reclaimed node does not take a service down.

Create a node pool with an accelerator attached, make sure the NVIDIA driver is installed, and request the GPU in the Pod spec.

gcloud container node-pools create gpu-pool \
  --cluster=demo --region=us-central1 \
  --machine-type=g2-standard-8 \
  --accelerator=type=nvidia-l4,count=1,gpu-driver-version=default

Then ask for it in the container:

resources:
  limits:
    nvidia.com/gpu: 1

GKE taints GPU nodes so only Pods requesting GPUs land there. To share expensive GPUs, use time-sharing or multi-instance GPU (MIG) on supported cards. On Autopilot you request GPUs through Pod specs and node selectors instead of managing pools.

Reserve a global static IP, create a ManagedCertificate, then reference both from an Ingress.

apiVersion: networking.gke.io/v1
kind: ManagedCertificate
metadata:
  name: web-cert
spec:
  domains:
  - www.example.com
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web
  annotations:
    kubernetes.io/ingress.global-static-ip-name: web-ip
    networking.gke.io/managed-certificates: web-cert

Point your DNS A record at the static IP. Google provisions the certificate only after DNS resolves to the load balancer, which can take several minutes up to an hour. For Gateway API setups, use Certificate Manager instead.

Check progress with kubectl describe managedcertificate web-cert. The status moves from Provisioning to Active, and a Failed status usually means the DNS record is wrong.

GKE integrates with Google Cloud's observability stack out of the box.

• Cloud Logging collects system logs and, if enabled, workload stdout and stderr
• Cloud Monitoring shows cluster, node and Pod metrics in prebuilt GKE dashboards
• Managed Service for Prometheus scrapes Prometheus-format metrics using PodMonitoring resources, with PromQL queries
• Kubernetes events and Cloud Audit Logs track API activity

Set alerting policies on symptoms like Pod restarts, node memory pressure and pending Pods. Use the kubectl top command for a quick check, but rely on Monitoring for history.

Start with the scheduler's explanation:

kubectl describe pod web-7d9f --namespace=prod

Read the Events section. Common causes on GKE:

1. Insufficient CPU or memory - requests exceed any node, or the autoscaler hit its pool maximum
2. Compute Engine quota - the autoscaler cannot add VMs (check quotas and the autoscaler events)
3. Taints or selectors - Pod lacks a toleration, or no node matches the label
4. Volume zone mismatch - a PersistentVolume lives in a zone with no free nodes
5. IP exhaustion - the Pod range has no free addresses

If events mention NotTriggerScaleUp, the autoscaler explains why it did not add a node.

Run kubectl describe pod and read the exact pull error. Then check the usual suspects:

1. Wrong path or tag - verify the Artifact Registry URL, repository region and tag
2. Missing permission - the node service account (or Workload Identity principal) needs roles/artifactregistry.reader
3. Registry in another project - grant the reader role on that project's repository
4. No egress in a private cluster - enable Private Google Access or Cloud NAT so nodes can reach the registry
5. Image pull secret - required for third-party private registries

A 403 or denied message points at permissions, while not found points at the path or tag.

Neither is universally better. It depends on how much control and Kubernetes compatibility you need.

Choose Cloud Run for stateless HTTP services, event handlers and jobs where simplicity and scale-to-zero matter. Choose GKE for complex microservice platforms, StatefulSets, custom controllers, GPUs at scale, or when you must stay portable across Kubernetes environments.

Plain Kubernetes Secrets are only base64-encoded, so add layers around them.

• Secret Manager add-on - mounts secrets from Google Secret Manager into Pods using a CSI driver, so the source of truth stays outside the cluster
• Application-layer secrets encryption - encrypts etcd-stored Secrets with a Cloud KMS key you control
• Workload Identity Federation - gives each Pod IAM access to only the secrets it needs
• RBAC - restrict who can get or list Secrets

Avoid putting secrets in environment variables baked into images or in Git. If you use Secrets directly, rotate them and restrict namespace access.

The node controller notices missed heartbeats and marks the node NotReady, then adds the taints node.kubernetes.io/not-ready or unreachable.

Pods tolerate those taints for 300 seconds by default (tolerationSeconds). After that they are evicted and recreated on healthy nodes by their controllers (Deployments, StatefulSets).

In parallel, node auto-repair will drain and recreate the node if it stays unhealthy for about 10 minutes.

Watch out for StatefulSets with zonal disks: replacements must schedule in the same zone as the volume. Lower tolerationSeconds if you need faster failover.

flowchart TD
  A["Heartbeats stop"] --> B["Node marked NotReady and tainted"]
  B --> C["Wait tolerationSeconds, default 300"]
  C --> D["Pods evicted and rescheduled"]
  B --> E["Unhealthy about 10 min"]
  E --> F["Auto-repair recreates node"]

A PodDisruptionBudget (PDB) limits how many replicas of an app can be voluntarily evicted at once. During node upgrades, GKE drains nodes through the eviction API, so PDBs are honored.

For surge upgrades GKE respects a PDB for up to about one hour per node. After that it proceeds anyway, so a badly set PDB delays upgrades but cannot block them forever.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: web

Avoid minAvailable equal to the replica count, since that leaves no room to drain a node. PDBs do not protect against involuntary failures such as a node crash.

On Autopilot, capacity is created on demand from the Pod's requests, so the lifecycle has an extra provisioning phase.

1. You apply the manifest and the API server stores the Pod as Pending.
2. Autopilot checks the requests (and compute class, if set), adjusting them to allowed minimums and ratios.
3. If no node has room, Autopilot provisions a new node. This is why first-time scheduling can take a minute or more.
4. The scheduler binds the Pod to the node and the kubelet pulls the image.
5. Init containers run, then app containers start and probes mark the Pod Ready.
6. On delete, SIGTERM is sent, the grace period elapses, and empty nodes are later removed.

flowchart LR
  A["Pod created: Pending"] --> B["Requests validated and adjusted"]
  B --> C{Node with room?}
  C -- No --> D["New node provisioned"]
  C -- Yes --> E[Scheduled]
  D --> E
  E --> F["Image pulled, containers start"]
  F --> G["Ready probes pass"]
  G --> H["Running, then terminated and node reclaimed"]

A client request travels through Google's edge and load balancer before it reaches a Pod.

1. DNS resolves the hostname to the load balancer's global anycast IP.
2. The request enters Google's edge and the forwarding rule hands it to the target HTTPS proxy, which terminates TLS.
3. The URL map matches host and path to a backend service.
4. The backend service picks a healthy endpoint in a NEG (container-native) or a node (instance groups).
5. The request reaches the Pod, which answers back along the same path.

Health checks run per backend, so a Pod failing its readiness probe is removed from rotation before users see errors.

sequenceDiagram
  participant C as Client
  participant LB as Application Load Balancer
  participant U as URL map
  participant N as NEG
  participant P as Pod
  C->>LB: HTTPS request
  LB->>U: Match host and path
  U->>N: Choose backend service
  N->>P: Send to healthy Pod IP
  P-->>C: Response

The mechanism relies on a node-level metadata server that stands in for the normal Compute Engine one.

1. The Pod's client library asks the GKE metadata server on the node for a token.
2. The server identifies the calling Pod and its Kubernetes ServiceAccount.
3. It requests a KSA token and exchanges it through the Security Token Service against the cluster's workload identity pool (PROJECT_ID.svc.id.goog).
4. If IAM has a binding for that principal, a short-lived federated token is returned, optionally used to impersonate a Google service account.
5. The library uses the token to call the Google API.

The principal looks like principal://iam.googleapis.com/projects/NUM/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA.

sequenceDiagram
  participant Pod
  participant MS as GKE metadata server
  participant STS as Security Token Service
  participant API as Google API
  Pod->>MS: Request token
  MS->>STS: Exchange KSA token
  STS-->>MS: Federated access token
  MS-->>Pod: Short-lived token
  Pod->>API: Call with token

Register clusters to a fleet, then use fleet features to connect them.

• Multi-cluster Services (MCS) - exports a Service with ServiceExport so other clusters resolve it as name.namespace.svc.clusterset.local
• Multi-cluster Gateway - one Google Cloud load balancer spreads external traffic across backends in several clusters and regions
• Config Sync - applies the same configuration to every cluster from Git

Typical reasons are regional failover, data residency and blast-radius reduction. Clusters should share a VPC (or have routable Pod ranges) so cross-cluster traffic works, and you must keep Namespace names consistent because services are matched by namespace.

Config Sync continuously pulls Kubernetes manifests from a Git repository (or OCI image) and applies them to your clusters, treating Git as the source of truth.

1. Enable the feature on a fleet-registered cluster.
2. Create a RootSync (cluster-wide) or RepoSync (namespace-scoped) pointing at the repo, branch and directory.
3. Authenticate with a token, SSH key or Workload Identity Federation.
4. Commit changes. Config Sync reconciles and reverts manual drift.

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceFormat: unstructured
  git:
    repo: https://github.com/example/platform-config
    branch: main
    dir: clusters/prod
    auth: none

Pair it with Policy Controller to block non-compliant resources before they land.

Remove single points of failure at every layer: zone, node and Pod.

1. Use a regional cluster so the control plane and nodes span three zones.
2. Run at least three replicas and spread them with topologySpreadConstraints on topology.kubernetes.io/zone.
3. Add readiness and liveness probes so traffic reaches only healthy Pods.
4. Set a PodDisruptionBudget so upgrades and drains never remove too many replicas.
5. Set realistic resource requests and enable HPA for load spikes.
6. Keep state in regional storage, such as regional persistent disks or managed databases.

topologySpreadConstraints:
- maxSkew: 1
  topologyKey: topology.kubernetes.io/zone
  whenUnsatisfiable: DoNotSchedule
  labelSelector:
    matchLabels:
      app: web

Because Pod and Service ranges are set at creation and are hard to change, running out of IPs is one of the most common scaling failures.

Each node reserves a Pod CIDR block. In Standard, the default is 110 Pods per node with a /24 block (256 IPs). Autopilot allows up to 32 Pods per node, using a smaller block.

Avoid overlap with on-premises ranges you will connect through VPN. If space is tight, lower max Pods per node so each node uses a smaller block, and consider adding additional Pod ranges later.

Cost mostly follows requested capacity, so start by making requests honest.

1. Right-size requests using VPA recommendations and Monitoring data, since Autopilot bills and the autoscaler decides on requests.
2. Autoscale Pods with HPA and nodes with the cluster autoscaler, using the optimize-utilization profile where tolerable.
3. Use Spot VMs for fault-tolerant workloads.
4. Commit with committed use discounts for steady baseline capacity.
5. Turn off idle clusters and scale dev and test namespaces to zero outside working hours.
6. Track spend with cost allocation by namespace and label.

Also compare Autopilot and Standard for each workload, since the cheaper model depends on how well nodes are packed.

Upgrade in order: control plane first, then node pools, with safeguards on the workload side.

1. Check the deprecation insights and release notes for removed APIs.
2. Test the target version in a staging cluster, ideally on a faster release channel.
3. Use a regional cluster so the API stays available while control plane replicas upgrade one at a time.
4. Confirm every critical app has multiple replicas, readiness probes and a PDB.
5. Upgrade node pools with surge settings (for example maxSurge 1 and maxUnavailable 0), or use blue-green for fast rollback.
6. Watch metrics and error rates, and pause if they degrade.

Remember the version skew rule: nodes cannot run a newer version than the control plane.

GKE has two editions that sit on top of the Autopilot and Standard operation modes.

Pick Enterprise when many teams and clusters need consistent policy, configuration and traffic management. A single team with one or two clusters is usually fine on Standard edition. Check current pricing and feature lists, since packaging changes over time.

Combine network restrictions with identity controls.

• Authorized networks - allow only specific CIDR ranges to reach the public endpoint
• Private endpoint - disable the public endpoint so the API is reachable only from within the VPC, VPN or Interconnect
• DNS-based endpoint - access the control plane through a Google-managed DNS name protected by IAM, avoiding IP allowlists
• IAM and RBAC - restrict who can fetch credentials and what they can do

gcloud container clusters update demo --region=us-central1 \
  --enable-master-authorized-networks \
  --master-authorized-networks=203.0.113.0/24

If your CI runners have changing IPs, prefer the DNS-based endpoint or run them inside the VPC.

In the default Autopilot model you pay for the resources your Pods request (vCPU, memory and ephemeral storage) for the time they run, plus a cluster management fee. Each billing account gets a free-tier credit that offsets the fee for one cluster.

You do not pay for idle nodes, system overhead or unscheduled capacity. Specialized compute classes and accelerators can be billed differently, so check the current rate card.

Because requests drive the bill, set accurate values. Over-requesting wastes money, and Autopilot also enforces minimum request sizes and CPU-to-memory ratios.