사례1건
1건 중 1~1번째
- 증상
2025-03-13 eu-west1 리전에서 Managed Services for Kubernetes 고객의 파드가 거의 모두 13:36 에서 18:11 UTC 사이에 적어도 한동안 네트워크 연결을 잃었다. Nebius 팀은 15:13 UTC 에 문제를 알아챘다. eu-north1 리전은 영향을 받지 않았다.
- 촉발
eu-west1 에 배포한 VPC 컨트롤 플레인 구성 요소의 릴리스가 새 기능에 필요한 route distinguisher 값을 바꿨다. 이 변경으로 오래전부터 코드에 있던 버그가 실제로 드러났다.
- 원인
- 구성 요소
- 기여 요인
- 조치
- 문제가 난 노드에서 구성 요소를 재시작하면 그 노드가 풀린다는 것을 찾고, 영향을 받은 모든 노드에서 구성 요소를 한 번에 한 노드씩 재시작하기 시작했다.
- 17:57 UTC 에 구성 요소 재시작만으로 고쳐진다고 확신하고 병렬 재시작을 시작했다. 18:11 UTC 에 영향이 완전히 해소되었다.
- 후속 조치
- 버그 자체를 바로잡는다.
- 경로 수가 어긋나면 울리는 알림을 더한다.
- 데이터 플레인의 패킷 drop 수를 보는 알림을 더한다.
- 호스트 VPC 구성 요소를 재시작하지 않고도 엔드포인트를 초기화하는 방법을 만든다.
- VPC 의 상시 e2e 테스트 가상 머신을 카나리 호스트로 옮긴다.
- Managed Services for Kubernetes 용 상시 e2e 테스트를 더한다.
- e2e 테스트를 더 자주 돌린다.
- 중요하지 않은 내부 서비스가 가장 먼저 업데이트를 받는 배포 단계를 새로 둔다.
- 교훈
문제를 재현하려면 두 조건이 함께 맞아야 해서 테스트 환경과 카나리의 e2e 테스트로는 잡지 못했다. 기술 지표가 평소 값에서 벗어날 때 울리는 알림이 모자라 대응이 늦어졌다. 이번 경우에는 경로 수와 패킷 drop 수가 민감하게 반응한 지표였다.
내 클러스터에도 있는지 확인하기
이 사례에서 가장 많이 나오는 구성 요소: BGP 라우팅, 네트워크 컨트롤 플레인. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.