사례2건

2건 중 1~2번째

1. IL-0097 cluster 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 용 버전이었다.

   사례 보기
2. IL-0522 ingress-nginx Helm 차트 패치 업그레이드 뒤 jenkins.io 의 Ingress 가 지워져 사이트가 HTTP/503 을 냄

   Jenkins project2021

   증상

   2021년 11월 18일 11:32 UTC, 한 사용자가 Gitter 채널 jenkinsci/jenkins 에 https://www.jenkins.io/doc/pipeline/steps/ 가 HTTP/503 오류를 낸다고 알렸다. 화면에는 Fastly 의 Varnish 가 내는 "Guru meditation" 메시지가 떴다.

   서비스 중단리소스 삭제

   촉발

   2021년 11월 18일 10:42 UTC 에 nginx Helm 차트를 패치 버전인 4.0.6 에서 4.0.8 로 올리는 배포가 성공했다. 새 버전은 `{}` 같은 Nginx 설정 블록이 든 Ingress 어노테이션을 막는 어드미션 웹훅 규칙을 새로 만들었다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   인그레스 컨트롤러어드미션 웹훅HelmCDN 과 엣지 네트워크

   기여 요인

   미검증 가정캐시로 가려진 장애모니터링 사각지대수동 조치 악화

   감지

   장애가 시작되고 25분 뒤인 11:32 UTC 에 사용자가 Gitter 채널 jenkinsci/jenkins 에 신고해 알았다. origin.jenkins.io 에는 오류를 알릴 모니터링이 없었다.

   조치

   • 13:40 UTC 에 자동화 시스템을 모두 멈춘 채 nginx Helm 차트를 이전 버전 4.0.6 으로 롤백하고, 어드미션 웹훅 구성을 손으로 지워 jenkins.io 를 되살렸다.
   • jenkins-infra/charts 에서 jenkins.io 설정의 금지된 어노테이션을 지웠다.
   • jenkins.io Helm 차트를 nginx 4.0.8 에서 제대로 동작한다고 알려진 마지막 버전으로 올렸다.
   • 필요한 수정을 모두 적용한 뒤 17:11 UTC 에 자동화 시스템이 jenkins.io Helm 차트를 다시 배포해 사이트가 돌아왔고, Fastly 에 모든 페이지의 캐시를 비우게 했다.

   후속 조치

   • 인그레스 컨트롤러를 업데이트할 때는 항상 변경 기록을 깊이 읽고, 적어도 두 사람이 실시간으로 함께 본다.
   • www.origin.jenkins.io 의 장애를 잡아내도록 Datadog 에 이 도메인의 모니터링을 더한다.
   • 이 모니터링은 Host 헤더를 www.jenkins.io 로 보내, Fastly 를 거치는 jenkins.io 로 리디렉션되지 않게 한다.
   • 첫 페이지만이 아니라 pipeline steps 페이지 같은 여러 페이지를 점검 대상에 넣는다.
   • 운영에 배포하기 전에 k3s 로 잠깐 띄웠다 지우는 엔드 투 엔드 시험 환경을 두는 방안을 다음 분기에 검토한다.

   교훈

   인그레스 컨트롤러처럼 민감한 구성 요소는 패치 버전 업그레이드라도 변경 기록을 깊이 확인해야 한다. 원본 호스트인 origin.jenkins.io 를 직접 지켜보는 모니터링이 없으면 CDN 뒤에서 난 오류를 사용자 신고로 처음 알게 된다.

   사례 보기

원인별1