Kubernetes: 30% 노드 장애 테스트

생산 환경에서 노드 30%를 종료하는 쿠버네티스 장애 복구 훈련

팀은 OKD 기반 쿠버네티스 클러스터의 30% 노드를 종료하여 시스템 내재적 회복력에 숨겨진 약점을 파악했다. 이 훈련은 제어 평면, 인프라 구성 요소 및 애플리케이션 서비스가 대규모 인프라 장애에 어떻게 반응하는지를 검증했다. 일상 운영에서는 드러나지 않았던 웹훅 컨트롤러 문제와 리플리카 분포 불균형이 명확히 드러났다.

테스트 중인 클러스터 아키텍처

클러스터는 세 개의 가용성 존에 걸쳐 클라우드에서 운영되며, 각 존은 별도의 데이터 센터에 위치하고 서로 간 지연 시간은 1ms 미만이다. 완전한 메시 구조는 로컬 네트워크 동작을 모방한다.

핵심 구성 요소:

• 사용자 트래픽 로드 밸런서: 백엔드는 Ingress 파드와 지속적 볼륨 컨트롤러를 실행하는 3개의 인프라 노드.
• API 로드 밸런서: 백엔드는 제어 평면을 호스팅하는 3개의 마스터 노드.
• 워커 노드: 존에 균등하게 분포, 총 N대.

이 구조는 클러스터의 다수 결정권을 유지하면서 전체 존 장애를 시뮬레이션할 수 있게 한다. etcd는 3개 마스터 노드 중 최대 1개 손실에도 견딜 수 있다.

재난 훈련 준비 단계

계획에는 8단계가 포함되었다:

• 기본 클러스터 및 서비스 상태 확인.
• 마스터 및 인프라 노드의 스냅샷 생성 (빠른 롤백용).
• 한 존의 모든 노드 비활성화 (또는 1개 마스터, 1개 인프라 + 30% 워커 노드).
• 1~2시간 동안 모니터링: 로그 오류 수집, 메트릭 추적, 지원 팀 협업.
• 비활성화된 노드 복원.
• 클러스터 상태 재검증.
• 훈련 완료.
• 작업 항목 문서화.

훈련 시 스냅샷은 etcd 백업보다 선호된다. 복구 속도가 빠르고 위험도 낮기 때문이다. 워커 노드는 상태가 etcd에 저장되기 때문에 백업하지 않는다. 반면 인프라 노드는 지속적 볼륨이 존재하므로 백업이 필요하다.

30%는 현실적인 실패 시나리오를 테스트하기에 적절한 수치이며, 치명적인 피해는 피할 수 있다. 마스터 노드의 다수 결정권은 최대 33% 손실까지 유지 가능하다.

성공 기준:

• API 접근 가능 여부 유지.
• 파드 생성 및 삭제 정상 수행.
• 지속적 볼륨 사용 가능.
• 서비스 정상 작동.
• 리플리카 복구 시간 10~15분 이내.
• 알림은 오프라인 노드 외에는 모두 해결됨.

훈련 #1: 개발 클러스터

1/3(1개 마스터, 1개 인프라, 약 80개 워커 코어) 비활성화. 로드 밸런서는 1분 내에 불량 백엔드를 제거했다. API는 응답 가능했지만, 노드는 300초간 '알 수 없음' 상태로 전환되었으며, 이후 'NotReady/Unreachable' 상태로 전환됐다.

파드는 10분 동안 재시작되지 않았다. 새 파드 생성 시 다음과 같은 오류 발생:

Error from server (InternalError): error when creating "pod.yaml": Internal error occurred: failed calling webhook "mutate.kyverno.svc-fail": failed to call webhook: Post "https://infra-kyverno-svc.infra-kyverno.svc:443/mutate/fail?timeout=30s": dial tcp 10.128.4.174:9443: connect: connection refused

Kyverno(어드미션/변경 웹훅)는 각 유형별로 1개 파드를 운영했으며, 그중 2/3이 비활성화된 존에 위치해 이미 'Terminating' 상태였다. 활성 웹훅이 없으면 변경 사항은 절대 etcd에 도달하지 못한다. 시스템 네임스페이스는 데드락을 방지하기 위해 Kyverno에서 제외된다.

Kyverno 리플리카 수 증가. 이벤트에서 자원 부족으로 인한 스케줄링 차단 현상 확인 (문맥상 암시됨).

문제점과 해결책

Kyverno: 각 웹훅 유형당 3개 이상의 리플리카를 설정하고 존 인식형 토폴로지 스프레드 적용.

스케줄러 차단: 영향 받은 네임스페이스의 리소스 할당량과 제한값 확인.

실제 운영 환경(훈련 #2 및 #3)에서는 유사한 상황이 확대되어, 적절한 반친화도 없이 PDB 위반이 발생했으며, PV 이동 지연도 발견됐다.

애플리케이션 팀에게 제공된 체크리스트:

• 최소 3개의 리플리카 보장.
• minAvailable를 설정한 PodDisruptionBudget(PDB).
• TopologySpreadConstraints 또는 nodeAffinity 활용.
• 리소스 요청/제한 설정.
• 합리적인 타임아웃을 가진 라이브니스/레디니스 프로브.

가장 중요한 점들

• 노드 30%를 종료하면 일반 조건에서는 나타나지 않는 웹훅 및 스케줄링 문제를 드러낸다.
• Kyverno는 존에 균등하게 분포된 1개 이상의 리플리카가 필요하다.
• 300초의 NotReady/Unreachable 타임아웃은 표준이지만, 여유 자원 확보가 필수다.
• 인프라/마스터 노드 스냅샷은 안전한 훈련을 위한 필수 조건이다.
• 완전 복구: 리플리카 복구 + 알림 해소까지 10~15분 소요.

팀을 위한 권고사항

서비스 개발자에게:

• PDB 설정: minAvailable: 50%.
• 존 분포를 위한 topologySpreadConstraints 사용.
• 관측된 피크의 80% 수준으로 CPU/RAM 요청/제한 설정.
• 5~10초 타임아웃, 3회 재시도를 갖춘 프로브 사용.

쿠버네티스 관리자에게:

• Kyverno 및 기타 웹훅이 고가용성으로 3개 이상의 리플리카를 확보하도록 하기.
• etcd 리더 선출 모니터링.
• +30% 여유 용량을 고려한 용량 계획 수립.
• 매번 훈련 전 자동 스냅샷 생성.

100개 이상의 노드를 보유한 모든 생산 클러스터에 반드시 실시해야 하는 훈련이다.

— Editorial Team