사례36건

36건 중 6~10번째

1. IL-0101 자동 업그레이드를 꺼 둔 GKE 클러스터의 컨트롤 플레인이 지원 종료 기한에 1.33.2 로 강제 업그레이드된 뒤 새 노드가 모두 초기화에 실패해, 오토스케일링과 스팟 노드 복구가 15시간 멈췄다.

   Wealthy2025sev1

   증상

   2025년 9월 14일, 이미 떠 있던 노드는 계속 돌았지만 새로 만들어지는 노드는 하나도 클러스터에 제대로 들어오지 못했다. 스팟 인스턴스에서 돌던 백그라운드 워커, 리포트 서비스, 주문 할당 시스템이 완전히 멈췄다. API 는 기존 노드에서 계속 응답했지만 부하가 늘어도 확장할 수 없었다.

   노드 증설 실패컨테이너 재시작 반복서비스 중단DNS 조회 실패

   촉발

   노드 풀의 자동 업그레이드를 꺼 두었는데도 Google 이 버전 지원 종료 기한을 이유로 컨트롤 플레인을 v1.32.x 에서 v1.33.2 로 강제 업그레이드했다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   GKE 컨트롤 플레인노드 풀클라이언트 쪽 DNS 리졸버와 캐시영구 볼륨과 스테이트풀셋컨피그맵과 시크릿

   기여 요인

   미뤄 둔 업그레이드단일 장애점롤백 무효여유 용량 부재

   조치

   • 강제 업그레이드와 같은 버전인 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. IL-0147 AKS 202508 노드 이미지가 캐시되지 않은 쿠버네티스 바이너리를 받을 때 HTTP 프록시 설정을 쓰지 않아, 프록시 뒤에 있는 노드의 프로비저닝이 CSE 종료 코드 31 로 실패했다.

   Microsoft2025

   증상

   모든 아웃바운드 트래픽을 사내 프록시로 보내야 하는 환경에서 AKS 1.31.0 부터 1.31.8 까지의 노드 풀을 만들거나 늘리면 VMSS 인스턴스 프로비저닝이 실패했다. 계획된 유지 보수로 노드 이미지가 202507.* 에서 202508.* 로 자동 업그레이드된 뒤부터였다.

   노드 증설 실패업그레이드 정체

   촉발

   계획된 유지 보수로 노드 이미지가 202507.* 에서 202508.* 로 자동 업그레이드됐다.

   원인

   소프트웨어 결함

   구성 요소

   노드 운영체제 이미지노드 풀

   기여 요인

   캐시로 가려진 장애자동화 증폭

   감지

   고객이 VMSS 활동 로그와 CSE 출력에서 프로비저닝 실패를 보고 원인을 좁힌 뒤 2025년 8월 27일 Azure/AKS GitHub 이슈로 보고했다.

   조치

   • 고객은 AKS 1.31.8 클러스터의 노드 이미지를 202507.* 로 고정해 프로비저닝을 되살렸다.
   • 고객은 202508.* 이미지를 쓰는 클러스터를 AKS 1.31.9 나 1.31.10 으로 올려 문제를 피했다.
   • AKS 팀은 캐시되지 않은 바이너리를 내려받을 때 프록시 설정을 쓰도록 VHD 20250811 에 핫픽스를 넣어 9월 4일 모든 퍼블릭 리전에 배포했다. VHD 20250820 에도 핫픽스를 넣겠다고 알렸다.
   • AKS 팀은 사용자에게 az aks nodepool upgrade -n <nodepool-name> --cluster-name <clustername> -g <resourcegroup-name> --node-image-only 로 노드에 이미지를 다시 설치하라고 안내했다.

   후속 조치

   • 앞으로 나오는 모든 VHD 에 같은 수정을 넣는다.

   교훈

   노드 이미지에 캐시된 쿠버네티스 버전이면 바이너리를 내려받지 않으므로 프록시 처리가 망가져도 드러나지 않는다. 캐시는 마이너 버전마다 최근 패치 두 개뿐이라, 오래된 패치 버전을 쓰는 클러스터만 내려받기 경로를 타서 이 버그를 겪었다. 보고한 사용자는 AKS 이슈 #5200 에서 요청한 노드 풀 자동 롤백 기능이 있었다면 이런 상황에서 도움이 됐을 것이라고 적었다.

   사례 보기
3. IL-0082 EKS 노드 교체 중 CoreDNS 파드 하나가 종료되자 남은 CoreDNS 파드가 늘어난 부하를 버티지 못해 DNS 조회가 느려지고 타임아웃이 났다.

   RebelMouse2025

   증상

   2025년 5월 19일 13:42 UTC 에 RebelMouse 모니터링 도구가 오류율 상승과 서비스 성능 저하를 잡아냈다.

   DNS 조회 실패지연 시간 증가오류율 상승서비스 중단

   촉발

   보안 패치를 적용하는 정기 EKS 노드 교체 중에 계획된 EC2 인스턴스 종료가 자동으로 실행됐고, 그 인스턴스에서 돌던 CoreDNS 파드 하나도 함께 종료됐다.

   원인

   용량 한계

   구성 요소

   CoreDNS노드 풀

   기여 요인

   피크 시간 변경

   감지

   13:42 UTC 에 RebelMouse 모니터링 도구가 오류율 상승과 서비스 성능 저하를 잡아냈다. 노드 교체를 시작한 지 27분 뒤였다. 기술팀은 2분 뒤인 13:44 UTC 에 조사를 시작했다.

   조치

   • 영향을 받은 CoreDNS 파드를 새 EC2 인스턴스로 다시 스케줄했다.
   • CoreDNS 디플로이먼트를 스케일 업해 레플리카 수를 늘리고, 부하가 모든 파드에 고르게 나뉘게 했다.

   후속 조치

   • 부하가 몰리는 시간대에 CoreDNS 파드가 예기치 않게 종료되지 않도록 스케일 인 보호 장치를 넣는다.
   • CoreDNS 파드의 수직 확장이 제대로 되도록 CoreDNS 설정을 다시 살펴본다.
   • CoreDNS 디플로이먼트가 최대 부하를 감당할 만큼 준비돼 있는지 정기적으로 용량을 점검한다.

   사례 보기
4. IL-0099 메모리 상한 없이 8GB 만 보장한 프로필 때문에 워크숍 중 사용자 파드가 서로를 축출해 서버 시작이 15분을 넘고 커널이 죽었다.

   2i2c2025

   증상

   2025년 5월 12일 20:15 EEST 에 Freshdesk 지원 티켓이 들어왔다. 워크숍 중 사용자 서버가 시작하는 데 15분 넘게 걸리고 커널이 죽는다는 내용이었다. 같은 허브를 다른 용도로 쓰던 강사들도 영향을 받았다.

   파드 축출

   촉발

   워크숍 사용자들이 메모리 상한이 없는 프로필로 보장량 8GB 보다 많은 메모리를 꾸준히 썼다.

   원인

   용량 한계

   구성 요소

   컨테이너 메모리 한도노드 풀

   기여 요인

   리소스 요청과 한도 미설정

   감지

   커뮤니티가 Freshdesk 지원 티켓으로 알렸다. 티켓은 20:15 에 열렸고 20:49 에 #support-freshdesk 슬랙 채널로 팀에 전달됐으며, 20:57 에 첫 엔지니어가 확인했다.

   조치

   • 5월 12일 21:05 에 helm 롤아웃과 허브 재배포를 했고 상황이 일부 나아졌다.
   • 5월 13일 15:51 에 medium 프로필을 열었고, 그 메모리 보장량을 올려 오버커밋을 줄였다.
   • 17:15 에 30명 워크숍을 위해 노드 15개를 미리 띄웠다.
   • 5월 14일 워크숍 전에 작은 노드용 프로필의 메모리 보장량과 상한을 같게 맞춰 명시적인 메모리 상한을 두는 변경을 배포했다.

   후속 조치

   • 장애 보고서를 쓴다.
   • 내부 회고를 열어 이번 장애에서 배울 점을 정리한다.

   교훈

   메모리 상한 없이 보장량만 둔 프로필에서는 노드를 나눠 쓰는 사용자끼리 서로를 축출할 수 있다. 메모리 보장량과 상한을 같게 두면 한 사용자의 메모리 급증이 같은 노드의 다른 사용자에게 번지지 않는다. 이번에는 로그에 뚜렷한 오류가 없었고 원인은 프로필 설정에 있었다. 워크숍 직전에는 프로필 구조를 바꾸지 않고 노드를 미리 띄우는 쪽으로 대응했다.

   사례 보기
5. IL-0078 EKS 업그레이드 중 Terraform 으로 KMS 시크릿 암호화를 켜자 워커 노드의 IAM 권한이 빠져 운영 ZenML Pro 워크스페이스에 모두 접속할 수 없게 됐다

   ZenML2025

   증상

   2025-05-11 0시부터 8시 사이, 중부유럽 서머타임인 CEST 기준으로 ZenML Pro 워크스페이스 서버에 모두 접속할 수 없었다.

   서비스 중단

   촉발

   EKS 모듈을 업그레이드하면서 Terraform 으로 AWS KMS 시크릿 암호화를 켰다. 이 작업이 문서에 없는 버그에 걸려 워커 노드의 IAM 권한이 빠졌다.

   원인

   소프트웨어 결함

   구성 요소

   Terraform노드 풀

   기여 요인

   스테이징 불일치미뤄 둔 업그레이드

   감지

   팀은 밤새 돌게 둔 업그레이드를 이어서 보려고 5월 11일 06:00 에 클러스터를 다시 보다가 비정상 상태를 발견했다.

   조치

   • 영향받은 EKS 노드 그룹을 올바른 IAM 권한과 설정으로 다시 만들었다.
   • 영향받은 모든 ZenML Pro 환경에서 서비스 접근을 복구했다.

   후속 조치

   • EKS 와 VPC Terraform 모듈을 모두 현재 지원되는 버전으로 올렸다.
   • 계획한 EKS 클러스터 업그레이드를 마쳤다.
   • 재발을 막도록 쿠버네티스와 인프라의 정기 업그레이드 전략을 검토한다.

   교훈

   팀은 규모가 훨씬 작은 스테이징 클러스터에서 업그레이드가 성공한 것을 보고 운영에서 같은 변경의 위험을 낮게 봤다. 쿠버네티스와 모듈 버전을 건너뛰는 사이 업그레이드 복잡도가 쌓여, 업그레이드 한 번에 많은 변경이 한꺼번에 실렸다.

   사례 보기

원인별9