사례2건
2건 중 1~2번째
IL-0097cluster autoscaler 버전을 올린 뒤 Kubernetes 1.33 에 남아 있던 클러스터에서 스케일업이 일어나지 않아 새 노드가 만들어지지 않았다2i2c2026- 증상
2026-03-31 15:10 부쿠레슈티 시각에 PagerDuty 알림 "[FIRING:1] At least two servers failed to start in the last 30m cluster=berkeley-geojupyter hub=prod (provider=aws immediate action needed)" 이 울렸다. 이 알림은 서버를 못 띄운 사용자의 신고가 아니라 자동 상태 점검에서 나왔다.
- 촉발
하루 전에 머지한 업그레이드에서 cluster autoscaler 버전이 올라갔다. berkeley-geojupyter 클러스터는 대다수 클러스터보다 오래된 Kubernetes 1.33 을 쓰고 있었고, 새 autoscaler 버전과 맞지 않았다.
- 원인
- 구성 요소
- 기여 요인
- 감지
15:10 에 자동 상태 점검이 서버 시작 실패를 잡아 PagerDuty 알림 "[FIRING:1] At least two servers failed to start in the last 30m" 을 API 로 띄웠고, 장애 #2057 이 열렸다. 실제 사용자가 서버를 못 띄워 알게 된 것이 아니었다.
- 조치
- 클러스터의 Kubernetes 버전을 1.33 에서 1.34 로 올렸다.
- cluster autoscaler 를 한 패치 버전 내려 k8s 1.34 용인 9.55.0 으로 맞췄다.
- 후속 조치
- 2i2c-org/infrastructure 저장소의 PR 8008 로 후속 수정을 한다.
- recurrent-k8s-aws-upgrades.yaml 워크플로가 만드는 정기 업그레이드 이슈를 통해 클러스터마다 다른 Kubernetes 버전을 하나로 맞춘다.
- 교훈
대응자들이 autoscaler 버전을 올린 맥락을 생생히 기억하고 있어서 처음부터 올바른 방향으로 조사했다. 반면 팀이 업그레이드 묶음을 설계할 때 1.32 클러스터만 염두에 둬서 1.33 클러스터가 빠졌다. 이번에 맞춘 autoscaler 9.55.0 은 Kubernetes 1.34 용 버전이었다.
- 증상
2025년 9월 14일, 이미 떠 있던 노드는 계속 돌았지만 새로 만들어지는 노드는 하나도 클러스터에 제대로 들어오지 못했다. 스팟 인스턴스에서 돌던 백그라운드 워커, 리포트 서비스, 주문 할당 시스템이 완전히 멈췄다. API 는 기존 노드에서 계속 응답했지만 부하가 늘어도 확장할 수 없었다.
- 촉발
노드 풀의 자동 업그레이드를 꺼 두었는데도 Google 이 버전 지원 종료 기한을 이유로 컨트롤 플레인을 v1.32.x 에서 v1.33.2 로 강제 업그레이드했다.
- 원인
- 구성 요소
- 기여 요인
- 조치
- 강제 업그레이드와 같은 버전인 v1.33 으로 새 GKE 클러스터를 만들었다.
- 쿠버네티스 1.33 과 호환되도록 Istio 를 1.27.1 로 올렸다.
- 쿠버네티스 1.33 에 맞게 cert-manager 설정을 갱신했다.
- 모든 운영 워크로드를 새 클러스터로 옮기고, 파드 스케줄링, DNS 조회, PVC 마운트, 외부 연동이 정상인지 확인했다.
- 손상된 기존 클러스터를 폐기했다.
- 후속 조치
- 모든 클러스터를 GKE stable 릴리스 채널로 설정한다.
- 2025년 4분기까지 Argo CD 와 모니터링 같은 관리용 구성 요소를 따로 돌리는 관리 클러스터를 만든다.
- 중요한 워크로드의 스팟 인스턴스 사용을 다시 검토하고, 온디맨드 대체 노드 풀을 추가한다.
- SRE 업그레이드 절차를 문서로 남긴다. 관리 클러스터를 먼저 올리고, 며칠 동안 지켜본 뒤 운영 클러스터를 올린다.
- 쿠버네티스, Istio, cert-manager 사이의 호환 표를 문서로 남긴다.
- 업그레이드를 자동으로 시험하는 파이프라인을 만든다.
- 빠르게 이전할 수 있도록 고정 IP 를 예약해 둔다.
- Istio, cert-manager, CSI, DNS 애드온의 버전을 고정한다.
- 지원 종료 기한에 몰리지 않도록 stable 릴리스를 따라 제때 올리고, GKE 알림과 공지를 정기적으로 확인한다.
- 교훈
Google 은 자동 업그레이드를 꺼 두어도 버전 지원 종료 기한이 되면 컨트롤 플레인을 강제로 올린다. 강제 업그레이드를 피하려면 지원 버전 범위 안에 머물러야 한다. 기존 노드가 멀쩡해도 새 노드 초기화는 완전히 실패할 수 있다. 선점된 스팟 노드가 클러스터에 돌아오지 못하면 장애가 연쇄로 번진다. 컨트롤 플레인을 올린 뒤 노드 초기화가 되돌릴 수 없게 망가지면 클러스터를 통째로 다시 만들어야 할 수도 있다. 예측할 수 있고 검증된 릴리스 주기를 원하면 GKE stable 채널을 쓴다. 쿠버네티스를 올릴 때는 Istio, cert-manager 같은 의존 구성 요소를 함께 맞춰야 한다. 같은 클라우드에 대기 클러스터가 없으면 바로 넘어갈 곳이 없다. SRE 가 롤아웃을 단계적으로 관리하면 업그레이드 위험이 줄어든다.
이 2건에서 가장 많이 나오는 구성 요소: 클러스터 오토스케일러, 컨피그맵과 시크릿. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.