TIL

11. Disruptions

• 공식 문서 - Disruptions
• pod가 사라지는 사건을 두 종류로 나누어 다루는 개념
  • voluntary — “자발적”, 즉 사람이나 시스템이 의도하고 일으킨 종료 (ex. 노드 점검, 배포)
  • involuntary — “비자발적”, 즉 사고로 일어난 종료 (ex. 하드웨어 고장, OOM)
• PodDisruptionBudget(PDB)으로 voluntary disruption의 동시 종료 수를 제한해 무중단을 유지

TL;DR

• pod는 두 종류 disruption에 노출됨 — voluntary(의도된 종료) / involuntary(사고성 종료)
• PDB는 voluntary disruption만 막을 수 있음 — HW 장애·OOM·kubectl delete pod는 못 막음
• 단일 replica로는 voluntary disruption에서도 무중단 불가능 — replicas≥2가 출발점
• Deployment의 maxUnavailable과 PDB의 maxUnavailable은 서로 다른 상황에서 동작하는 별개의 설정. 둘 다 설정해야 진짜 무중단

1. Voluntary vs Involuntary Disruption

• voluntary = “자발적” — 운영자나 시스템이 계획해서 일으킨 종료. 예측 가능하고 절차를 거침
• involuntary = “비자발적” — pod 입장에서 갑자기 당한 종료. 예고 없이 발생

구분	정의	대표 예시
Voluntary	운영자·시스템 컴포넌트가 의도적으로 종료	kubectl drain, 노드 업그레이드, Cluster Autoscaler scale-down, Deployment rollout
Involuntary	의도하지 않은 사고로 종료	하드웨어 장애, 커널 패닉, 노드 네트워크 단절, 노드 OOM으로 인한 강제 종료, kubelet 비정상 종료

• 이 구분이 중요한 이유 — PDB는 voluntary disruption에만 적용되기 때문
  • involuntary는 그 정의상 막을 방법이 없음 (장애가 PDB를 물어보고 일어나진 않음)
• voluntary는 “누가/무엇이 evict 요청을 보내는가” 의 차이일 뿐 모두 같은 흐름(Eviction API)을 탄다

2. Voluntary Disruption이 일어나는 시나리오

• 노드 운영 작업
  • kubectl drain — 노드를 비우고 점검·교체할 때
  • Node 업그레이드 — 컨트롤 플레인·kubelet 버전 업
• 클러스터 오토스케일링
  • Cluster Autoscaler ScaleDown ⭐ — 사용률이 낮은 노드를 회수할 때, 그 위 pod는 evict 됨
  • 평소엔 잘 안 보이다가 트래픽이 잠잠해진 새벽·점심시간에 갑자기 발생
• Spot/Preemptible 인스턴스 회수
  • 클라우드 사업자가 사전 통지(예: 30s~2m) 후 회수 — 통지 구간은 voluntary로 취급되지만 시간이 짧음
• 워크로드 자체의 교체
  • Deployment rollout, StatefulSet 업데이트 — 새 ReplicaSet으로 교체되는 동안 기존 pod는 종료됨
• 핵심: “운영자나 시스템이 의도적으로 종료하는 모든 경로” 는 voluntary. 따라서 PDB로 보호 가능.

3. Eviction API의 동작

• voluntary disruption의 종료 경로는 모두 Eviction API를 거친다
  • kubectl drain, Cluster Autoscaler, descheduler 등이 내부적으로 Eviction API 호출
• DELETE pod ≠ Eviction
  • kubectl delete pod는 PDB를 무시하고 즉시 삭제 — eviction을 우회함
  • 즉, 같은 “pod 사라짐”이라도 경로에 따라 PDB 적용 여부가 다름
• Eviction 처리 순서
  1. PDB 체크 — 지금 evict해도 AllowedDisruptions ≥ 1인지 확인. 0이면 거부(429 Too Many Requests)
  2. terminationGracePeriodSeconds 존중 — preStop hook → SIGTERM → grace 경과 후 SIGKILL
  3. (구현체별) 장기 차단 시 강제 evict — 일정 시간(예: 1시간) PDB가 풀리지 않으면 일부 구현체는 강제 진행할 수 있음 (GKE 등 환경마다 동작 다름)
• 결국 PDB는 “동시 종료 수를 제한”할 뿐 “영원히 종료를 막는 장치” 가 아니다

4. PodDisruptionBudget

4-1. spec

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  selector:
    matchLabels:
      app: my-app
  minAvailable: 2          # 또는 maxUnavailable 중 택1

• selector — 보호 대상 pod 셀렉터
• minAvailable — 항상 가용해야 할 최소 pod 수. 절대값 또는 백분율
• maxUnavailable — 동시에 unavailable 될 수 있는 최대 pod 수. 절대값 또는 백분율
• minAvailable과 maxUnavailable은 XOR — 둘 중 하나만 지정 (둘 다 쓰면 거부됨)

4-2. 동작 메커니즘

• 컨트롤러가 보호 대상 pod의 ownerReferences를 따라가 상위 워크로드의 desired replicas를 산출
  • ex) Deployment의 spec.replicas 값을 참조
• 그 desired 값과 minAvailable/maxUnavailable로 현재 허용 가능한 evict 수(AllowedDisruptions) 를 계산
  • 예: replicas=5, minAvailable=4 → AllowedDisruptions = 5 - 4 = 1
• Eviction API는 호출 시점에 AllowedDisruptions를 1 감소시키고, pod가 다시 ready가 되면 회복
• 즉 PDB는 “동시에 몇 개까지 빠져도 되는가” 의 토큰 버킷처럼 동작

4-3. 안티패턴 — replicas=1 + minAvailable=1

• 단일 pod 워크로드에 minAvailable: 1을 걸면 eviction이 영원히 거부됨
  • 1개를 evict하는 순간 available이 0이 되어 PDB 위반
  • kubectl drain이 멈추고, Cluster Autoscaler가 노드를 회수하지 못함
• 왜 안 되는가 — PDB는 “빠져도 되는 수” 를 정의하는 것이므로 desired와 같은 값을 minAvailable로 두면 0이 되는 것을 허용하지 않게 됨
• 해결책
  • replicas≥2 + minAvailable: 1 (또는 maxUnavailable: 1) — 가장 일반적
  • 정말 단일 인스턴스가 강제라면 PDB를 걸지 않거나, unhealthyPodEvictionPolicy: AlwaysAllow로 우회 가능성 확보

4-4. unhealthyPodEvictionPolicy

값	동작	사용 시점
IfHealthyBudget (기본)	ready인 pod도 PDB budget 안에서만 evict. unhealthy pod라도 PDB를 위반하면 막힘	안정성 우선. 정상 pod를 갑자기 빼앗기지 않음
AlwaysAllow	unhealthy(non-ready) pod는 PDB와 무관하게 항상 evict 허용	죽은 pod 때문에 drain이 멈추는 상황 해소

• 기본값 IfHealthyBudget의 함정
  • pod가 crash loop·readiness 실패로 unhealthy인 상태에서 노드 drain을 시도하면 죽은 pod조차 evict 못함
  • PDB가 “정상 pod N개 유지”를 보장하지 못하는 상태이므로 컨트롤러가 더 빠지는 것을 거부
• AlwaysAllow는 그 교착을 푸는 안전판 — 운영 자동화가 멈추는 사고를 줄임

5. PDB가 막을 수 없는 것

• Involuntary disruption — HW 장애, 노드 OOM, 커널 패닉, 네트워크 단절
  • 사건 자체가 Eviction API를 거치지 않음
• kubectl delete pod — eviction을 우회한 직접 삭제. PDB는 무시됨
• liveness probe 실패로 인한 재시작 — kubelet이 컨테이너를 죽이는 동작이며 evict가 아님

• 노드 종료에 의한 graceful node shutdown — 환경에 따라 PDB를 고려하기도/안 하기도 함

• 한 줄 요약 — “PDB는 예의 바른 종료만 막는다”

6. Deployment의 maxUnavailable vs PDB의 maxUnavailable

• 이름이 같아 헷갈리지만 서로 다른 상황에 적용되는 별개의 설정 — 한쪽이 다른 쪽을 대체하지 못함

구분	Deployment maxUnavailable	PDB maxUnavailable
적용 시점	rollout 진행 중	모든 voluntary disruption 시점
누가 사용	Deployment Controller가 새 ReplicaSet으로 교체할 때	Eviction API가 evict 허용 여부 판단할 때
보호 대상	rollout 진행 속도	노드 drain·오토스케일 등 외부 evict
단독으로 막는가	rollout 외에는 무력	rollout 자체에는 적용되지 않음 (rollout은 PDB 우회)

• 둘 다 필요한 이유
  • Deployment maxUnavailable=0 만 있으면 — rollout은 안전하지만 노드 drain 한 번에 다 빠질 수 있음
  • PDB maxUnavailable=1 만 있으면 — drain은 안전하지만 rollout이 한꺼번에 25%(기본) 빠질 수 있음
• 무중단 운영은 rollout 안전 + voluntary disruption 안전 두 가지를 모두 잠가야 한다
• cross-ref: 04. Deployment - 업데이트 전략

7. 무중단 운영 종합 체크리스트

1. replicas ≥ 2 (또는 HPA minReplicas ≥ 2)
   • 단일 pod로는 어떤 메커니즘으로도 무중단 불가능
2. Deployment strategy — maxSurge ≥ 1, maxUnavailable: 0
   • rollout 중 사용 가능 수가 떨어지지 않음
3. PDB — minAvailable 또는 maxUnavailable을 desired보다 작게 설정
   • replicas=3 → minAvailable: 2 또는 maxUnavailable: 1
4. readinessProbe 정확성
   • “단순 startup ≠ 트래픽 처리 가능”. 의존 자원 연결까지 끝났을 때 ready를 반환해야 의미가 있음
5. preStop hook + terminationGracePeriodSeconds
   • SIGTERM 후 트래픽이 끊길 때까지 짧게 sleep하고 그 다음 정상 종료
   • cross-ref: 09. Container Lifecycle Hooks
6. PodAntiAffinity (선택)
   • 같은 노드에 모든 replica가 몰리면 노드 한 대 사고로 동시 종료
   • 호스트 단위로 분산하면 involuntary disruption 영향도 함께 완화

8. 빠르게 점검하기

• 클러스터의 모든 PDB와 현재 상태 확인

  kubectl get pdb -A
  

  NAMESPACE   NAME         MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
  default     my-app-pdb   2               N/A               1                     3d
  

  • ALLOWED DISRUPTIONS — 지금 시점에 evict 허용되는 pod 수
    • 0이면 노드 drain·오토스케일이 막힌 상태. unhealthy pod 존재 또는 desired 부족이 흔한 원인
• 실제로 evict 가능한지 미리 확인

  kubectl drain <node> --dry-run=server --ignore-daemonsets
  

  • 실제 evict는 안 하면서 서버측 admission(PDB 포함) 통과 여부만 검사
• 특정 pod만 evict 시뮬레이션

  kubectl get pdb my-app-pdb -o yaml
  

  • status.disruptionsAllowed, status.currentHealthy 값을 직접 확인해 디버깅