사례2건
2건 중 1~2번째
- 증상
2025-03-05 01:00 UTC 무렵부터 일부 고객의 LKE 클러스터가 IP ACL 을 켠 상태에서 오토스케일링에 실패했고, 서비스 장애로 이어졌다.
- 촉발
가장 최근에 배포한 LKE 소프트웨어 릴리스에 결함이 있었다.
- 원인
- 구성 요소
- 기여 요인
- –
- 감지
고객 쪽 문제는 01:00 UTC 무렵 시작됐고, 상태 페이지의 첫 조사 공지는 06:49 UTC 에 올라왔다.
- 조치
- 임시 조치로 게이트웨이 파드를 재시작했지만 잠깐만 효과가 있었다.
- 문제가 된 소프트웨어 릴리스를 롤백했고, 15:00 UTC 무렵 영향받은 모든 클러스터에서 롤백을 마쳤다.
- 후속 조치
- 근본 원인을 계속 조사하고 알맞은 재발 방지 조치를 한다.
- 교훈
결함은 IP ACL 을 켠 클러스터에서만 문제를 일으켰고, autoscaler 가 노드를 추가하려 할 때 드러났다. 게이트웨이 파드 재시작은 효과가 오래가지 않았고, 릴리스를 롤백하자 장애가 끝났다.
- 증상
2024년 4월 22일 14:05 UTC 쯤 토론토 데이터센터에서 새 LKE 클러스터가 프로비저닝되지 않았다.
- 촉발
앞서 배포한 API 업데이트가 의도대로 동작하지 않았고, 새 LKE 클러스터를 프로비저닝할 때 타임아웃을 일으켰다.
- 원인
- 구성 요소
- 기여 요인
- –
- 감지
2024년 4월 22일 14:05 UTC 쯤 Linode 팀이 토론토 데이터센터에서 새 LKE 클러스터가 프로비저닝되지 않는 것을 알아채고 조사를 시작했다.
- 조치
- 4월 23일 15:03 UTC 에 문제가 된 토론토 데이터센터의 인프라를 새 LKE 클러스터 프로비저닝에 쓰지 않도록 껐다.
- 4월 25일 16:45 UTC 쯤 의도대로 동작하지 않던 API 업데이트를 바로잡는 수정을 적용했고, 18:05 UTC 에 새 클러스터 생성이 완전히 돌아온 것을 확인했다.
- 수정을 적용한 뒤 잠시 빼 두었던 인프라를 다시 프로비저닝에 넣었다.
- 교훈
원인은 오류가 드러난 인프라가 아니라 앞서 배포한 API 업데이트에 있었다. 그런데도 실패는 대부분 한 데이터센터의 백엔드 자원 하나에 몰렸다. 그 자원을 새 클러스터 프로비저닝에서 빼서, 근본 원인을 찾는 데 걸린 사흘 동안 고객 영향을 줄였다.
이 2건에서 가장 많이 나오는 구성 요소: 클러스터 오토스케일러, 노드 풀. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.