사례96건

96건 중 11~15번째

1. IL-0188 EKS 롤링 업데이트 때 Kubernetes 는 새 파드가 Ready 가 되자마자 옛 파드를 지웠지만 ALB 는 새 파드를 아직 healthy 로 보지 않아, 배포마다 약 30초 동안 502 가 났다.

   Yonghyun Kim2025

   증상

   새벽 3시에 "배포는 성공했는데, 서비스는 죽었다"는 Slack 메시지가 왔다. 모든 파드는 Ready 였고 Datadog 도 초록불이었지만, 사용자는 계속 오류 화면을 보고 있었다.

   오류율 상승서비스 중단

   촉발

   롤링 업데이트에서 새 파드가 readinessProbe 를 통과해 Ready 가 되자 Kubernetes 가 곧바로 옛 파드를 지웠다. 그때 ALB 는 새 파드 IP 를 대상 그룹에 막 등록해 initial 상태로 헬스 체크를 하고 있었다.

   원인

   배포 결함

   구성 요소

   클라우드 로드 밸런서인그레스 컨트롤러파드 종료 처리

   기여 요인

   미검증 가정기본 설정 방치모니터링 사각지대

   감지

   새벽 3시에 "배포는 성공했는데, 서비스는 죽었다"는 Slack 메시지로 알았다. 파드 상태와 Datadog 대시보드는 모두 정상이었고, 장애는 사용자가 보는 화면에만 나타났다.

   조치

   • 네임스페이스에 elbv2.k8s.aws/pod-readiness-gate-inject=enabled 레이블을 붙였다. AWS Load Balancer Controller 의 웹훅이 파드에 ReadinessGate 를 넣었다. 새 파드는 ALB 대상이 healthy 가 된 뒤에야 Ready 가 됐고, 그제야 옛 파드가 지워졌다.

   교훈

   Kubernetes 의 Ready 와 ALB 의 healthy 는 서로 다른 시점에 정해지므로, 둘을 잇는 장치가 없으면 롤링 업데이트 때 502 가 날 수 있다. 파드 상태와 대시보드가 모두 정상이어도 사용자는 오류를 볼 수 있다. terminationGracePeriodSeconds 를 늘려 시간을 버는 방식은 배포만 느리게 하고 새 파드가 뜰 때의 공백은 막지 못한다. ReadinessGate 는 ALB 대상 유형이 ip 일 때만 의미가 있고, instance 모드에서는 노드가 대상이라 쓸 수 없다. ReadinessGate 를 쓰면 파드가 Ready 가 되기까지 30초에서 40초가 더 걸리므로 급한 스케일 아웃에 대비해 레플리카나 HPA 를 넉넉히 잡는다. 웹훅의 failurePolicy 를 Ignore 로 두면 컨트롤러가 죽어도 배포가 막히지 않는다.

   사례 보기
2. IL-0187 Spring Cloud Config Server 가 잠깐 내려가자 이를 헬스 체크에 포함한 모든 앱의 Liveness Probe 가 실패해 쿠버네티스가 파드를 계속 죽이고 다시 띄우면서 한 계열사 서비스가 마비됐다.

   Yonghyun Kim2025

   증상

   Config Server 업그레이드로 서버가 잠깐 응답하지 않는 동안, 클라이언트 앱 전부가 Liveness Probe 요청에 Config Server 와 연결되지 않는다며 실패로 응답했다.

   프로브 실패컨테이너 재시작 반복서비스 중단

   촉발

   Config Server 를 다운타임이 있는 방식으로 업그레이드하면서 서버가 잠깐 응답하지 않았다.

   원인

   의존성 장애

   구성 요소

   라이브니스·레디니스 프로브

   기여 요인

   기본 설정 방치자동화 증폭과도한 영향 범위

   교훈

   Liveness Probe 가 앱 자신이 아니라 외부 의존성의 상태까지 판단하면, 잠깐의 외부 장애나 네트워크 문제에도 쿠버네티스가 멀쩡한 앱을 죽인다. 일시적인 부하나 외부 서버 다운은 앱을 죽일 이유가 아니며, Readiness Probe 로 잠시 트래픽만 막으면 된다. 글쓴이는 특별한 이유가 없으면 Liveness Probe 를 끄라고 권한다. 꼭 써야 한다면 헬스 체크 경로에서 DataSourceHealthIndicator, ConfigServerHealthIndicator 같은 외부 Health Indicator 를 빼거나 /healthz 같은 별도 경로를 만들어야 한다. initialDelaySeconds 는 앱이 뜨는 데 걸리는 최대 시간보다 길게, failureThreshold 와 periodSeconds 는 넉넉하게 잡는다. 예를 들어 failureThreshold: 10, periodSeconds: 6 이면 60초 동안 연속으로 실패해야 재시작된다. 글쓴이가 운영한 레브잇 환경은 Liveness Probe 없이 2년 동안 안정적으로 서비스했다.

   사례 보기
3. 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 가 롤아웃을 단계적으로 관리하면 업그레이드 위험이 줄어든다.

   사례 보기
4. IL-0095 엔지니어가 kubectl 이 다른 클러스터를 가리키는 줄 모르고 prod 네임스페이스를 지워 LEAP JupyterHub 가 약 1시간 동안 멈췄다.

   2i2c2025

   증상

   새 temple 클러스터에 허브를 배포하던 엔지니어가 NFS 문제를 만나 prod 네임스페이스를 지웠는데 삭제가 멈춘 채 끝나지 않았다. 파드 목록을 보니 다른 클러스터의 사용자 파드가 잔뜩 있었다.

   리소스 삭제서비스 중단

   촉발

   2i2c 엔지니어가 새 허브의 NFS 배포 버그를 우회하던 중, kubectl 이 LEAP 클러스터를 가리키고 있는 줄 모르고 prod 네임스페이스를 지웠다.

   원인

   운영 실수

   구성 요소

   영구 볼륨과 스테이트풀셋잡과 크론잡인그레스 컨트롤러Terraform

   기여 요인

   파괴적 변경 보호 장치 부재런북 부재

   감지

   네임스페이스를 지운 엔지니어가 삭제가 멈춘 것을 보고 파드 목록을 확인하다 다른 클러스터의 사용자 파드를 발견했고, 17:00 BST 에 장애를 선언했다. 모니터링 알림보다 먼저였다. 업타임 검사 실패 알림은 17:32 에 왔고 사용자의 404 제보는 17:37 에 들어왔다.

   조치

   • prod 네임스페이스에 남아 있던 사용자 파드 하나를 지워 멈춰 있던 네임스페이스 삭제를 끝냈다.
   • 재배포를 막고 있던 nfs-share-creator 잡을 종료했다.
   • 바뀐 NFS 서버 IP 주소로 prod 허브를 다시 배포했다.
   • 배포 도중 사용자가 서버를 띄우지 못하게 prod 인그레스를 지웠다.

   후속 조치

   • 장애 보고서를 쓴다.
   • "I deleted prod, what next?" 같은 상황에서 바로 볼 수 있는 짧은 장애 대응 문서를 쓴다.
   • jupyterhub-home-nfs 를 업그레이드하고 nfs-share-creator 잡을 없앤다.
   • deployer 시스템에 kubeconfig 컨텍스트가 중첩되는 것을 막는 보호 장치를 넣었다. 기본으로는 꺼져 있고 쓰는 사람이 켜야 동작한다.
   • 해당 엔지니어의 셸 설정을 바꿔 kubeconfig 컨텍스트를 더 쉽게 구분하게 했다.

   교훈

   쿠버네티스 리소스를 잃는 경우에 대비해 영구 스토리지를 Terraform 으로 따로 프로비저닝해 둔 설계 덕분에 사용자 데이터가 살아남았다. 반면 엔지니어에게 지금 어느 클러스터를 다루고 있는지 알려 주는 단서가 없었던 것이 실수로 이어졌다. 복구 방법을 알고 있어도 데이터 손실 위험을 확인해 줄 사람이 다른 시간대에 있어 재배포가 늦어졌다. NFS 배포의 순환 의존과 nfs-share-creator 잡도 복구를 늦췄다.

   사례 보기
5. IL-0067 Redis 마스터의 50Mi 영구 볼륨이 가득 차 AOF 가 깨졌고, Redis 파드가 크래시 루프에 빠져 Klamm 운영 서비스가 멈췄다

   BC Government2025sev1

   증상

   2025년 7월 9일 OpenShift 위의 Klamm 캐시 Redis 클러스터가 멈췄다. Redis 로그에는 "Fail to fsync the AOF file: No space left on device" 오류가 남았다. AOF 는 Redis 가 쓰기 명령을 차례로 덧붙여 저장하는 파일이다.

   서비스 중단컨테이너 재시작 반복영구 볼륨 가득 참

   촉발

   Klamm Laravel 워커 하나에서 I/O 작업이 예상하지 못하게 급증해 Redis 캐시 요청이 크게 늘었고, AOF 가 빠르게 커지면서 Redis 마스터의 영구 볼륨을 채웠다.

   원인

   용량 한계

   구성 요소

   영구 볼륨과 스테이트풀셋인메모리 캐시

   기여 요인

   용량 계획 부재

   조치

   • Redis 스테이트풀셋과 디플로이먼트를 멈췄다.
   • 깨진 PVC 를 지우고 다시 만들었다. 이 과정에서 Redis 볼륨의 데이터를 잃었다.
   • 스테이트풀셋과 디플로이먼트를 다시 시작했다.

   후속 조치

   • Klamm Redis 캐시 볼륨을 100Mi 로 늘린다.
   • 네임스페이스에 Sysdig 모니터링을 설정한다.
   • Redis 클러스터에서 레플리카 파드를 쓰도록 설정한다.

   사례 보기

원인별11