사례3건
3건 중 1~3번째
- 증상
2025-03-18 09:36, 사용자들이 운영과 비운영 환경 모두에서 파드가 종료되고 자동으로 다시 뜨지 않는다고 알렸다. 자동 인프라 알림도 함께 울렸고, 운영 서비스에 장애가 났다.
- 촉발
EKS 1.30 업그레이드 중 디스케줄러가 cordon 된 노드의 파드를 모두 한꺼번에 다시 스케줄하려 했다.
- 원인
- 구성 요소
- 기여 요인
- 감지
팀은 자동 인프라 알림과 사용자 보고로 장애를 알았다. 09:36 에 사용자들이 파드가 종료되고 다시 뜨지 않는다고 알렸다.
- 조치
- cordon 어노테이션을 지워 파드가 다시 스케줄되게 했다.
- 멈춘 1.30 노드를 지워 새로 만들어지게 했다.
- 1.30 노드 20대로 된 새 노드 그룹을 손으로 추가했다.
- 예전 1.29 노드를 모두 cordon 하고 drain 해 워크로드를 새 1.30 노드로 옮겼다.
- 후속 조치
- AWS 에 Production System Down 지원 요청을 올려 추가 안내를 받았다. 요청 번호는 174229643100496 이다.
- 비슷한 장애의 원인을 찾을 때 컨트롤 플레인 로그를 어떻게 조회하는지 AWS 지원팀에서 안내받았다.
- 용량이 갑자기 모자랄 때 새 노드 그룹을 급히 늘리는 런북을 쓴다.
- 오토스케일링 그룹과 쿠버네티스가 보는 노드가 어긋나면 울리는 알림을 만든다.
- 디스케줄러가 왜 cordon 된 노드에서 파드를 쫓아내는지 설정을 검토하고, 가능하면 고친다.
- Pending 파드 수가 갑자기 늘면 울리는 알림을 만든다.
- 교훈
이 글은 교훈 대신 후속 조치를 적었다. 조치를 보면 팀에는 비상용 노드 그룹을 급히 추가하는 문서화된 절차가 없었다. 오토스케일링 그룹과 쿠버네티스가 보는 노드가 어긋날 때 울리는 알림도, Pending 파드가 급증할 때 울리는 알림도 없었다. 팀은 디스케줄러가 cordon 된 노드를 어떻게 다루는지도 분명히 알지 못했다.
IL-0530us-central1 의 가상 네트워크 라우터 컨트롤러가 메모리 부족으로 재시작을 되풀이해 새 VM 과 마이그레이션된 VM 의 네트워크가 오래 끊겼다Google Cloud2023- 증상
us-central1 에서 새로 만든 VM 은 네트워크가 동작하기까지 오래 기다려야 했고, 라이브 마이그레이션된 VM 은 마이그레이션 뒤 오래 연결을 잃었다. us-central1 을 오가는 리전 간 트래픽에서 패킷 손실이 났다. 기존 VM 중 마이그레이션되지 않고 상태도 바뀌지 않은 VM 은 직접 영향을 받지 않았다.
- 촉발
관리 플레인의 동작 변경이 us-central1 에 배포됐다. 이 변경은 로드 밸런서 백엔드로 쓰는 GCP Instance Group 과 Network Endpoint Group 의 API 업데이트 처리를 더 잘 분리하려는 것이었다. 이 리전의 큰 워크로드 규모 때문에 가상 네트워크 라우터 컨트롤 플레인의 메모리가 예상 밖으로 늘었다.
- 원인
- 구성 요소
- 기여 요인
- 감지
엔지니어들은 10월 4일 미국 태평양 시간 21:45 에 us-central1 가상 네트워크 컨트롤 플레인이 느리다는 알림을 받았고, 10월 5일 02:11 에 가상 네트워크 라우터 컨트롤러가 메모리를 다 써서 실패한다는 알림을 받았다. 03:08 부터는 네트워크 텔레메트리가 us-central1 을 오가는 리전 간 패킷 손실을 보여 주었다.
- 조치
- 컨트롤러에 메모리를 더 할당하는 변경을 배포했고, 이 변경은 미국 태평양 시간 05:27 부터 운영 환경에 닿았다. 08:15 에 리전 안 패킷 손실이 가라앉았다.
- 08:52 에 관리 플레인 변경의 롤백을 시작해 09:35 에 us-central1 에서 마쳤고, 이때 메모리 부족이 모두 멈췄다.
- 업데이트를 받지 않던 라우터 몇 대를 손으로 재시작했다. 이 재시작으로 패킷 손실이 더 생기지는 않았다.
- 후속 조치
- 메모리 위험과 예상 밖의 메모리 증가를 미리 알리는 알림을 만든다.
- 엔지니어가 메모리를 훨씬 빨리 다시 할당할 수 있도록 배포 설정을 다시 짠다.
- API 조정 작업의 기존 관행과 안전장치를 다시 평가하고 새 관행과 안전장치를 만든다.
- 관리 플레인 변경을 여러 팀이 더 잘 볼 수 있게 해 장애와 더 빨리 연결 짓게 한다.
- 리전 단위 API 변경 때문에 리전 전체의 메모리가 한꺼번에 바닥나는 일이 줄도록 배포 구성을 바꾼다.
- 트래픽 라우터와 컨트롤러의 메모리를 최적화해 불필요한 부담을 없앤다.
- 증상
Boskos 에서 GCP 프로젝트를 받아야 하는 Prow 테스트 작업이 밤사이 전부 실패했다. kubernetes/kubernetes 의 모든 PR 에 필수인 pull-kubernetes-e2e-gce 가 계속 실패해서 PR 을 하나도 병합할 수 없었다.
- 촉발
Prow 클러스터를 쿠버네티스 1.11 에서 1.13 으로 올리는 노드 업그레이드 중 23:04 에 Boskos 파드 하나가 돌던 노드가 drain 됐다. 새 노드에서 다시 만들어진 Boskos 파드는 StatefulSet 스펙에 적힌 새 이미지로 시작했는데, 이 이미지에 버그가 있었다.
- 원인
- 구성 요소
- 기여 요인
- 감지
알림은 울리지 않았다. Boskos 대시보드에는 실패가 뚜렷하게 보였지만 이를 잡는 알림이 없었다. 사용자들이 02:50 에 GitHub 로, 05:16 과 06:27 에 Slack 으로 장애를 알렸고, 담당자는 07:16 에 일어나 Slack 의 보고를 보고서야 알았다.
- 조치
- 버그를 찾은 뒤 고친 Boskos 이미지를 새로 빌드해 배포했고, Boskos 는 곧바로 살아났다.
- 장애 동안 반납되지 않고 열린 채로 남은 GCP 프로젝트들을 그 뒤 몇 분에 걸쳐 정리했다.
- 후속 조치
- Boskos 설정을 고쳐 배포하면 실제로 파드가 교체되게 한다.
- Boskos 배포를 자동화한다.
- Boskos 상태를 지켜보는 알림을 개선한다.
- 교훈
팀은 당직자가 오후 6시까지만 있는 날 오후 5시가 넘어 10시간짜리 배포를 시작하지 말았어야 했다고 보았다. 배포는 실제로 무언가가 바뀌었는지 확인할 수 있게 지켜봐야 하고, 그럴 수 없으면 아예 하지 않아야 한다고 정리했다. Boskos 의 StatefulSet 은 업데이트하도록 설정되어 있지 않아서 배포해도 아무것도 바뀌지 않았다. 12월의 변경은 한 번도 시험되지 않은 것으로 보였다. Prow 의 다른 부분과 달리 Boskos 는 손으로 배포해서 실수할 여지가 컸다. 담당자가 대응을 시작한 뒤로는 문제를 비교적 빨리 풀었다.
이 3건에서 가장 많이 나오는 구성 요소: 노드 풀, CI 시스템. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.