A service can have several running copies and still go offline when one machine fails: if every copy is on that machine, the failure takes them all down. High availability means arranging those copies so the application can remain operational when an individual node—or even an availability zone—fails. In Kubernetes, that means using multiple Pod replicas and spreading them across failure domains. section 8.2.1 section 1.2
Two decisions work together:
- Choose enough replicas. More Pods provide more redundancy, but use resources less efficiently. section 5.2.4
- Place replicas apart. Spreading Pods across nodes avoids a single-node failure taking down every replica; spreading across zones can protect against a zone failure. section 5.2.4 section 1.2
Size replicas around a tolerable failure
Suppose a service needs 36 workers and users would not notice if six were offline. Concentrating no more than six workers in one Pod limits the impact of losing that Pod. Six Pods with six workers each provide redundancy, though more replicas can cost more resources. section 5.2.4
Listing 8.9 Chapter08/8.2.1_TopologySpread/deploy_topology.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: timeserver
spec:
replicas: 3
selector:
matchLabels:
pod: timeserver-pod
template:
metadata:
labels:
pod: timeserver-pod
spec:
topologySpreadConstraints: #1
- maxSkew: 1 #2
topologyKey: kubernetes.io/hostname #3
whenUnsatisfiable: ScheduleAnyway #4
labelSelector: #5
matchLabels: #5
pod: timeserver-pod #5
containers:
- name: timeserver-container
image: docker.io/wdenniss/timeserver:5
resources:
requests:
cpu: 200m
memory: 250Mi
#1 The topology constraint added
#2 The maximum number of replica imbalance
#3 The node label to use for the topology
#4 The behavior to use when it’s not possible to satisfy the topology requirement
#5 Another label selector set to this template’s metadata label
This three-replica Deployment specifies a topologySpreadConstraints rule using kubernetes.io/hostname. The setting asks Kubernetes to spread matching Pods across nodes rather than letting all three land together. Check that cluster nodes carry the label named by topologyKey; some platforms already provide default spreading policies. section 8.2.1
For a small deployment, start with the replicas and nodes you need rather than assuming a multizone setup is required. As availability needs grow, topology spread policies make the intended placement explicit. Kubernetes can also roll out service updates across zones; on a managed platform, gradual node replacement can migrate workloads to avoid downtime. section 1.2 section 8.2.1
