설명
Deployment의 여러 파드가 같은 노드에 함께 배치되면 단일 노드 장애가 서비스 가용성에 큰 영향을 줄 수 있습니다. 복제 수만 늘린다고 고가용성이 확보되는 것은 아닙니다.
Pod anti-affinity나 topology spread constraints로 분산 요구를 표현할 수 있습니다. 명시적인 anti-affinity가 없다고 실제 파드가 반드시 한 노드에 몰리는 것은 아닙니다.
잠재적 영향
- 노드 한 대의 장애로 여러 복제본이 동시에 영향을 받을 수 있습니다.
- 과도하게 엄격한 배치 조건은 가용 노드가 부족할 때 파드의 시작을 막을 수 있습니다.
해결 방법
- 가용성 요구에 맞춰 affinity.podAntiAffinity 또는 topology spread constraints를 구성하고 selector와 노드의 topology 라벨을 확인하세요.
- preferred 규칙은 분산을 선호할 뿐 보장하지 않습니다. required 규칙의 스케줄링 제약과 노드 용량을 검토하고 실제 파드 배치를 확인하세요.
예시
기존 이미지 버전은 실제 배포 전에 유지보수되는 검증된 버전으로 바꾸세요. 변경 후 규칙에는 서로 다른 hostname을 가진 적합한 노드가 최소 세 대 필요합니다.
변경 전
yaml
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
명시적인 분산 규칙이 없어 여러 복제본이 같은 노드에 배치될 수 있습니다.
변경 후
yaml
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
같은 네임스페이스의 app=web-store 파드가 같은 hostname에 스케줄링되지 않도록 제한합니다. 이미 실행 중인 파드를 자동으로 재배치하는 규칙은 아닙니다.