PodDisruptionBudget(PDB) 실전: 노드 교체/업그레이드 중 장애를 막는 최소 설정

PodDisruptionBudget(PDB) 실전: 노드 교체/업그레이드 중 장애를 막는 최소 설정

PDB가 없으면 노드 교체/업그레이드 때 '정상'인데도 서비스가 비는 순간이 생깁니다.
minAvailable/maxUnavailable을 어떻게 잡아야 안전한지 실무 기준으로 정리합니다.

이 글의 목표는 '개념 정리'보다, "어떤 기준으로 결정할지"와 "어떻게 운영에서 사고를 줄일지"를 남기는 것입니다.

왜 이게 어려운가(운영 관점)

운영 이슈는 대부분 한 설정이 아니라 '정렬되지 않은 설정 조합'에서 나옵니다(타임아웃, 종료, 리소스, 재시도).

따라서 증상 -> 원인 -> 검증 루틴을 팀 표준으로 만들면, 장애 대응 시간이 크게 줄어듭니다.

실전 내용(바로 적용)

PDB가 없으면 노드 교체/업그레이드 때 '정상'인데도 서비스가 비는 순간이 생깁니다.
minAvailable/maxUnavailable을 어떻게 잡아야 안전한지 실무 기준으로 정리합니다.

핵심 요약(결론부터)

• 기준(정책)을 먼저 정하고, 구현/도구는 그 다음에 선택한다
• 실패/예외/회귀를 운영 체크리스트로 막는다
• 공식 문서를 최종 근거로 삼고, 팀 문서로 재가공한다

PDB가 막는 것

eviction(자발적 disruption) 중 가용성 붕괴
노드 유지보수에서의 동시 종료

실무 팁

HPA/Replica 수와 같이 설계해야 한다
너무 빡빡하면 클러스터 업그레이드가 멈춘다

PDB 예시

apiVersion: policy/v1
kind: PodDisruptionBudget
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: api

운영 체크리스트(바로 적용)

• Replica 수가 1이면 PDB는 의미가 없다(먼저 복제부터)
• 업그레이드/드레인 시나리오를 리허설한다
• PDB로 인해 드레인이 막히는 상황을 운영 문서에 포함한다

FAQ

Q. PDB를 빡세게 잡으면 무조건 안전해지나요?
A. 아니요. 너무 빡세면 노드 드레인이 멈춰 운영이 막힙니다. 서비스 SLO와 운영 가능성 사이 균형이 필요합니다.

마무리: 다음 액션

• 팀의 기본값(정책)을 1페이지로 문서화한다
• 대표 시나리오 1개를 코드/설정 예시로 고정한다
• 배포 전후 지표(p95/p99, 오류율)를 비교해 효과를 확인한다

자주 하는 실수(사고 패턴)

• 증상만 보고 timeout/limit을 크게 늘려 원인을 숨긴다
• 프로브/스케일/리소스를 따로따로 튜닝해 전체 QoS가 흔들린다
• 변경 후 효과를 지표로 검증하지 않아 회귀가 반복된다
• 운영 자동화(CI/CD)에서 권한/보안 경계를 느슨하게 둔다

적용 순서(추천)

• 1) 지표로 증상을 고립한다(오류율/지연/재시도율/리소스)
• 2) 타임아웃을 레이어별로 정렬한다(client > proxy > server > db)
• 3) 스케일(파드/노드)과 워밍업(readiness)을 같이 설계한다
• 4) 변경은 작게/단계적으로 하고, 알람/롤백을 같이 준비한다
• 5) 운영 기준을 문서로 고정하고, 체크리스트로 반복 가능하게 만든다

검증/회귀 방지

• 재현: 스파이크/롤링업데이트/대용량 업다운로드 같은 시나리오를 고정
• 로그: upstream time, 종료 이벤트, 재시도 횟수 같은 필드를 고정
• 알람: OOMKilled, throttling, 5xx burst, p99 spike를 조기 경보로 운영

팀 합의 템플릿(복붙용)

# 장애 대응 템플릿(복붙용)
증상: (오류율/지연/시점/영향 범위)
가설: (타임아웃/리소스/종료/프록시/코드)
검증: (재현/로그/지표 링크)
조치: (설정 변경/배포/롤백)
재발 방지: (알람/체크리스트/문서)

FAQ

Q. PDB를 빡세게 잡으면 무조건 안전해지나요?
A. 아니요. 너무 빡세면 노드 드레인이 멈춰 운영이 막힙니다. 서비스 SLO와 운영 가능성 사이 균형이 필요합니다.

참고/출처

버전/환경에 따라 동작이 달라질 수 있으니, 최종 기준은 공식 문서를 확인합니다.

• Kubernetes: Pod Disruption Budgets