gcp
Root cause
GKE is a managed Kubernetes service, and that word - managed - is the key to understanding this whole class of outage. Google runs the control plane for you: the API server that kubectl and your CI talk to, the scheduler that places pods, and the controller manager that keeps the cluster reconciled toward your desired state. You run the data plane: the nodes, the container runtime on each node, kube-proxy, and the pods themselves. These two planes are deliberately decoupled, and that decoupling is exactly what determines what breaks and what survives when the control plane fails.
A GKE control-plane incident typically starts with one of a few triggers: a configuration change
to a control-plane component that goes wrong, capacity pressure on the multi-tenant API server
in a region, or degradation of a backing dependency such as the datastore that holds cluster
state. Because the control plane is regional and multi-tenant, a fault does not hit one
customer's cluster - it hits many clusters in the region at once. When it happens, the symptom is
sharp and specific: kubectl times out, kubectl apply fails, and the console cannot read cluster
state.
The reason this is a survivable outage rather than a total one is the decoupling. A node that is already running does not phone home to the control plane to keep serving its existing pods. The container runtime keeps the containers up, and kube-proxy keeps routing Service traffic using the last state it received. So the control plane can be completely down while your production traffic flows normally - the classic split brain where management is broken but serving is fine.
Business impact
What you lose in a control-plane outage is not availability but agency. You cannot deploy (no new rollouts land), you cannot scale (the Horizontal Pod Autoscaler and cluster autoscaler are blind), and you lose self-healing (if a node dies during the window, its pods will not be rescheduled until the control plane returns). For a stable, steady-state service this is a non-event that customers never notice. For a service in the middle of a deploy, a traffic spike, or a node failure, it is genuinely dangerous - the automation you rely on to absorb those situations is exactly what is offline.
That is why the SLA answer is nuanced. If your workloads kept serving, you may have suffered a real operational outage with no SLA breach at all, because the availability SLO measures the Kubernetes API endpoint, not your management convenience. To sort out whether a given incident actually crosses the threshold, the GCP SLA credit calculator lets you model the API unavailability against the monthly SLO.
The severity of a control-plane outage is therefore almost entirely a function of timing and architecture, not of the outage itself. Two companies can experience the exact same GKE incident and walk away with completely different stories. The first was running a steady service with ample capacity headroom, no in-flight deploy, and no node failures during the window - it never noticed. The second was mid-rollout when the API server went dark, could not roll forward or back, and then lost a node it could not reschedule, cascading a partial deploy into a real user-facing outage. Same root cause, opposite outcomes. That variance is precisely why the prevention advice below is about your design choices: you cannot stop Google's control plane from occasionally failing, but you have almost total control over how much it costs you when it does.
Prevention and lessons
- Never put the Kubernetes API on your request hot path. Applications that call the API server to serve user requests turn a control-plane outage into a customer-facing one. Read cluster state at startup and cache it; keep steady-state serving independent of the control plane. The GKE high availability guide covers this pattern in depth.
- Pre-provision capacity; do not depend on autoscaling during an incident. If autoscaling is what saves you under load, a control-plane outage removes your safety margin at the worst moment. Run enough headroom that a scaling freeze is survivable.
- Go multi-region for anything critical. The control plane is regional, so a second region is the clean escape hatch. A tested traffic-shift to a healthy region turns a regional control-plane outage into a blip - the same lesson as the June 2019 network congestion event and the multi-region GCP architecture guide.
- Know your global versus regional dependencies. GKE control planes are regional; other GCP layers like Service Control and Cloud Load Balancing are global. When you do have a claimable outage, the GCP credit playbook covers Google's tight 30-day filing window, and Next Signal can watch provider status and assemble the evidence for you.