A spread topology keeps replicated Pods from landing in one failure domain. Without it, three replicas can fit on one node and disappear together when that node fails. Kubernetes can distribute them across nodes, zones, or other provider-defined domains. section 8.2.1
Configure a workload with topology spread constraints to control placement:
- Set topologySpreadConstraints in the Pod template. section 8.2.1
- Choose topologyKey, such as kubernetes.io/hostname, to make each uniquely labeled node a separate spreading domain. section 8.2.1
- Verify that every node has the label named by topologyKey; otherwise the configuration cannot work as intended. section 8.2.1
Three-replica deployment
A timeserver Deployment with three replicas uses kubernetes.io/hostname, maxSkew: 1, and whenUnsatisfiable: ScheduleAnyway. Running it on three Minikube nodes and inspecting kubectl get pods -o wide shows the resulting placement. section 8.2.1
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
Inspect the complete Deployment manifest, including the topology spread fields and matching labels. section 8.2.1
