[Kubernetes 프로덕션] Day 5: 가용성과 운영 - 업그레이드 가능한 클러스터 만들기
이 글은 AI(Claude)의 도움을 받아 작성하고, 작성자가 검토·편집했습니다.
서론: 오늘의 문제
정상 상태에서 실행되는 것만으로 프로덕션 준비가 끝나지 않는다. 노드 교체, 존 장애, 버전 업그레이드와 운영자 실수를 견딜 수 있도록 중단 예산과 관측, 복구 절차를 준비한다.
1. PodDisruptionBudget의 범위
PDB는 노드 드레인 같은 자발적 중단에서 동시에 사라질 수 있는 복제본 수를 제한한다. 애플리케이션 자체 장애나 노드의 갑작스러운 고장까지 막아 주는 장치는 아니다.
2. 다중 장애 도메인
복제본과 상태 저장 데이터를 서로 다른 노드와 존에 분산한다. 분산했다는 선언만 믿지 말고 실제 스케줄 결과와 스토리지의 존 종속성을 정기적으로 확인한다.
3. 업그레이드 호환성
API 폐기와 노드 버전 차이, CNI와 CSI 호환성을 사전에 검사한다. 작은 환경에서 같은 순서로 리허설하고 control plane과 node pool 변경을 분리한다.
4. 백업과 복원 시험
etcd 또는 관리형 제어면 백업만으로 애플리케이션 데이터가 보호되지는 않는다. 매니페스트, 외부 데이터 저장소, 비밀과 인증서의 복원 목표를 각각 정의한다.
5. Runbook과 게임데이
Pending, CrashLoopBackOff, DNS 장애, 이미지 풀 실패처럼 반복되는 증상은 진단 순서를 Runbook으로 만든다. 게임데이에서 실제 권한과 도구로 복구 시간을 측정한다.
6. 자주 실패하는 방식
PDB와 강한 스케줄링 제약을 함께 쓰면 노드 드레인이 영원히 끝나지 않을 수 있다. 백업 성공 알림만 확인하고 복원하지 않으면 장애 시점에 권한, 형식, 의존성 문제를 처음 발견하게 된다.
7. 관측과 검증
SLO 소진율, 노드 압박, 드레인 소요 시간, 존별 복제본 분포, 백업 복원 시간, Runbook 단계별 복구 시간을 운영 지표로 둔다. 기준값은 정상 시간대와 변경 전후를 비교해 정하고, 점검 결과가 실제 행동으로 이어지는지 정기적으로 확인한다.
실행 흐름
1
2
3
4
5
6
7
8
9
1. PodDisruptionBudget의 범위
↓
2. 다중 장애 도메인
↓
3. 업그레이드 호환성
↓
4. 백업과 복원 시험
↓
5. Runbook과 게임데이
개별 도구보다 이 순서를 팀의 설계 리뷰와 Runbook에 남기는 것이 중요하다. 상황이 달라져도 판단 근거와 검증 결과가 이어져야 한다.
실전 체크리스트
- PodDisruptionBudget의 범위: 기준과 책임자를 문서화했다.
- 다중 장애 도메인: 기준과 책임자를 문서화했다.
- 업그레이드 호환성: 기준과 책임자를 문서화했다.
- 백업과 복원 시험: 기준과 책임자를 문서화했다.
- Runbook과 게임데이: 기준과 책임자를 문서화했다.
- 실패 패턴을 재현하고 안전한 복구 경로를 확인했다.
- 핵심 신호를 대시보드와 변경 검증에 연결했다.
참고 자료
시리즈 마무리
이번 연재에서 다룬 원칙을 실제 시스템의 설계·배포·운영 흐름에 연결해 반복 가능한 기준으로 만들자.