Kubernetes High Availability: What It Really Means
High availability (HA) in Kubernetes means the cluster can continue operating despite failures of individual components. True HA requires redundancy at multiple levels: the control plane, worker nodes, and application pods.
Control Plane HA
A single control plane node is a single point of failure. If it goes down, no new pods can be scheduled, and the cluster cannot self-heal.
Production HA requires: - 3 or 5 control plane nodes (for etcd quorum) - Load balancer in front of API server endpoints - etcd cluster with automatic leader election - Each control plane component running on multiple nodes
An odd number of etcd nodes (3 or 5) is required for quorum. A 3-node cluster tolerates 1 failure; a 5-node cluster tolerates 2 failures.
Worker Node Redundancy
Spread worker nodes across failure domains: - Multiple physical servers (different racks) - Multiple availability zones if using cloud infrastructure - Different power circuits and network paths
If all worker nodes are on the same rack, a rack-level failure (power, network switch) takes down all your workloads.
Pod-Level HA
Multiple Replicas
Run at least 2 replicas of every production service. With a single replica, any pod disruption (node failure, rolling update, resource pressure) causes downtime.
Pod Anti-Affinity
Pod anti-affinity rules prevent Kubernetes from scheduling all replicas on the same node:
affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchExpressions: - key: app operator: In values: [my-app] topologyKey: kubernetes.io/hostname
This ensures replicas are spread across different nodes.
Pod Disruption Budgets (PDB)
A PDB limits the number of pods that can be voluntarily disrupted simultaneously:
apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: my-app-pdb spec: minAvailable: 2 selector: matchLabels: app: my-app
This ensures at least 2 pods are always available during voluntary disruptions (node drain, cluster upgrade).
Database HA
Database high availability on Kubernetes typically involves: - StatefulSets for stable pod identity and storage - Primary-replica replication - Automatic failover (operator-managed) - Persistent storage with replication
Database HA is more complex than application HA because databases are stateful.
Network HA
- Run multiple ingress controller replicas
- Use load balancers with health checks
- Ensure CNI plugin supports node failure without network disruption
What HA Does NOT Guarantee
- Zero downtime: even with HA, brief disruptions during failover are possible
- Protection from application bugs: HA protects against infrastructure failures, not software failures
- Protection from correlated failures: if all nodes share the same cloud availability zone, a zone-wide outage affects all nodes
Conclusion
Kubernetes HA requires redundancy at every level: control plane, worker nodes, network, storage, and application pods. The investment in HA should be proportional to the application's availability requirements. Not every workload needs multi-node control plane HA; evaluate your actual requirements before adding complexity.