Description
When several Deployment Pods share a node, a single node failure can significantly affect service availability. Increasing replica count alone does not establish high availability.
Pod anti-affinity or topology spread constraints can express distribution requirements. The absence of explicit anti-affinity does not mean Pods necessarily share one node.
Potential impact
- One node failure can affect several replicas at once.
- Overly strict placement rules can prevent Pods from starting when suitable nodes are unavailable.
Remediation
- Configure affinity.podAntiAffinity or topology spread constraints to match availability needs, and check selectors and node topology labels.
- Preferred rules favor distribution but do not guarantee it. Review the scheduling restrictions and capacity needed by required rules, then verify actual Pod placement.
Examples
Replace the historical image version with a maintained, verified version before deployment. The second configuration requires at least three suitable nodes with distinct hostnames.
Before
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-server
spec:
replicas: 3
selector:
matchLabels:
app: web-store
template:
metadata:
labels:
app: web-store
spec:
containers:
- name: web-app
image: nginx:1.16-alpine
Without an explicit distribution rule, several replicas may be placed on the same node.
After
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-server
spec:
replicas: 3
selector:
matchLabels:
app: web-store
template:
metadata:
labels:
app: web-store
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchLabels:
app: web-store
topologyKey: kubernetes.io/hostname
containers:
- name: web-app
image: nginx:1.16-alpine
Pods labeled app=web-store in the same namespace cannot be scheduled on the same hostname. This does not automatically redistribute already running Pods.