사례3건

3건 중 1~3번째

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-0098 ingress-nginx 에서 nginx-ingress 로 옮긴 뒤 같은 호스트를 나눠 쓰는 인그레스들의 동작이 바뀌어 cert-manager 가 새 TLS 인증서를 받지 못했다.

   2i2c2026

   증상

   새 허브를 띄우려 했는데 인그레스가 새 TLS 인증서를 받지 못해 실패했다. 얼마 전 다른 허브에서도 같은 일이 있었다.

   요청 오라우팅배포 실패

   촉발

   nginx-ingress 로 옮긴 클러스터에서 새 TLS 인증서가 필요한 허브를 새로 배포했다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   인그레스 컨트롤러cert-manager

   기여 요인

   늦게 드러난 변경

   감지

   새 허브를 띄우다 인그레스가 새 TLS 인증서를 받지 못해 실패했다. 전날 다른 허브에서도 같은 현상을 봤기 때문에 엔지니어가 웹사이트에서 장애를 직접 선언했다.

   조치

   • TLS 가 필요한 인그레스 객체에 어노테이션을 달아 cert-manager 가 edit-in-place 방식으로 인그레스를 고칠 수 있게 했다.

   후속 조치

   • 후속 작업을 2i2c-org/infrastructure 이슈 8016 으로 남겼다.
   • 후속 작업을 2i2c-org/infrastructure 이슈 3278 로 남겼다.

   교훈

   인그레스 컨트롤러를 바꾸면 같은 호스트를 나눠 쓰는 인그레스들 사이의 우선순위가 바뀔 수 있고, cert-manager 의 ACME 임시 인그레스처럼 그 동작에 기대는 구성 요소가 깨진다. 이 문제는 새 인증서가 필요한 배포에서 드러났다. 2i2c 는 내부 클러스터를 시험하면서 이 원인을 이미 알고 있었고, cert-manager 설정을 고치는 일도 빨랐다.

   사례 보기
3. IL-0501 Azure 가 배포한 Ubuntu 18.04 업데이트로 UToronto AKS 클러스터의 모든 노드에서 네트워크가 끊겨 허브에 접속할 수 없었다

   2i2c2022

   증상

   jupyter.utoronto.ca 가 응답하지 않았고 사용자는 UToronto JupyterHub 에 아예 접속하지 못했다. 신고는 Freshdesk 티켓으로 들어왔다.

   서비스 중단노드 NotReady

   촉발

   Microsoft Azure 가 모든 Ubuntu 18.04 노드에 Ubuntu 업데이트를 자동으로 배포했고, 이 업데이트가 systemd 버그 1988119 를 드러내 노드의 네트워크를 끊었다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   노드 운영체제 이미지

   기여 요인

   디버그 접근 제한

   감지

   Freshdesk 티켓으로 jupyter.utoronto.ca 가 응답하지 않는다는 신고가 들어왔다.

   조치

   • 노드를 Azure Portal 의 VM 페이지에서 찾을 수 없어서, 재부팅 대신 클러스터의 쿠버네티스 버전과 노드 버전 업그레이드를 시작했다. 업그레이드가 옛 노드를 모두 내리고 새 노드로 바꾸면서 허브가 돌아왔다.

   후속 조치

   • 쿠버네티스 노드에 SSH 로 들어가는 방법을 문서로 남긴다.
   • Azure 공지를 알림으로 받아 볼 방법을 찾는다.

   교훈

   원인을 찾고 나서는 바로 복구할 수 있었다. 쿠버네티스 클러스터의 노드에 SSH 로 들어가는 방법이 문서로 없었다. 2i2c 는 클러스터 업그레이드를 아직 하지 않아 그 선택지가 남아 있었던 것과, 고객 쪽 담당자가 Azure 공지를 보고 알려 준 것이 운이 좋았다고 적었다.

   사례 보기

원인별1