사례5건

5건 중 1~5번째

1. IL-0027 CoreDNS 파드가 모두 한 노드에 몰린 채 그 노드의 메모리가 고갈되자 DNS 가 응답하지 못해 아이디어스 서비스 전체가 멈췄다

   Backpackr2025

   증상

   프로덕션 EKS 클러스터에서 원인을 바로 알기 어려운 서비스 에러가 간헐적으로 났다. RDS 나 Redis 같은 외부 서비스를 호출할 때 연결이 가끔 실패했다. DNS 요청이 몰릴 때는 도메인 조회 응답이 늦어지거나 조회가 아예 실패했다.

   DNS 조회 실패간헐적 연결 실패지연 시간 증가OOMKilled서비스 중단

   촉발

   모든 CoreDNS 파드가 같은 노드에 배치되었고, 그 노드의 메모리 사용률이 급증해 메모리가 고갈됐다.

   원인

   용량 한계

   구성 요소

   CoreDNS클라이언트 쪽 DNS 리졸버와 캐시kubelet컨테이너 메모리 한도노드 풀

   기여 요인

   기본 설정 방치단일 장애점캐시 부재

   감지

   글은 전면 장애를 어떻게 알아챘는지 적지 않았다. 그 전의 DNS 문제는 원인을 알기 어려운 서비스 에러가 간헐적으로 나면서 드러났다. 팀은 RDS 와 Redis 호출이 가끔 실패하는 현상을 추적하다가 DNS 이름 해석 실패가 근본 원인이라는 것을 확인했다.

   조치

   • CoreDNS 앞에서 DNS 질의를 받아 노드마다 캐시하는 NodeLocalDNS Cache 를 데몬셋으로 배포해 CoreDNS 부하를 줄였다.
   • CoreDNS 에 maxUnavailable: 1 인 PodDisruptionBudget 과 topology.kubernetes.io/zone 기준의 topologySpreadConstraints 를 적용해 파드가 한 곳에 몰리지 않게 했다.
   • Deployment 의 dnsConfig 로 ndots 값을 5 에서 2 로 낮춰 불필요한 DNS 조회를 줄였다.

   교훈

   쿠버네티스의 ndots:5 기본값은 점이 적은 외부 도메인을 조회할 때마다 질의를 여러 번 만든다. 이 부하는 트래픽이 큰 프로덕션 환경에서야 드러난다. CoreDNS 를 파드 2개의 기본 구성으로 두면 클러스터 전체의 단일 장애점이 된다. CoreDNS 파드는 노드와 가용 영역에 흩어 둔다. 별도 노드 그룹이나 Fargate 로 분리하면 다른 워크로드와 자원을 다투지 않는다. Affinity 와 PriorityClassName 으로 우선순위를 주면 더 안정적이다. CoreDNS 의 캐시와 bufsize 조정은 증상을 잠깐 줄였을 뿐이다. ndots 값은 여러 자료가 1이나 2를 권하지만 각 환경에 맞춰 정해야 한다.

   사례 보기
2. IL-0020 EKS 1.30 업그레이드 중 디스케줄러가 cordon 된 노드의 파드를 한꺼번에 쫓아내 운영 서비스가 멈췄다

   UK Ministry of Justice2025

   증상

   2025-03-18 09:36, 사용자들이 운영과 비운영 환경 모두에서 파드가 종료되고 자동으로 다시 뜨지 않는다고 알렸다. 자동 인프라 알림도 함께 울렸고, 운영 서비스에 장애가 났다.

   파드 축출파드 Pending서비스 중단업그레이드 정체

   촉발

   EKS 1.30 업그레이드 중 디스케줄러가 cordon 된 노드의 파드를 모두 한꺼번에 다시 스케줄하려 했다.

   원인

   배포 결함

   구성 요소

   디스케줄러노드 풀클러스터 오토스케일러

   기여 요인

   여유 용량 부재한계 경보 부재기본 설정 방치

   감지

   팀은 자동 인프라 알림과 사용자 보고로 장애를 알았다. 09:36 에 사용자들이 파드가 종료되고 다시 뜨지 않는다고 알렸다.

   조치

   • cordon 어노테이션을 지워 파드가 다시 스케줄되게 했다.
   • 멈춘 1.30 노드를 지워 새로 만들어지게 했다.
   • 1.30 노드 20대로 된 새 노드 그룹을 손으로 추가했다.
   • 예전 1.29 노드를 모두 cordon 하고 drain 해 워크로드를 새 1.30 노드로 옮겼다.

   후속 조치

   • AWS 에 Production System Down 지원 요청을 올려 추가 안내를 받았다. 요청 번호는 174229643100496 이다.
   • 비슷한 장애의 원인을 찾을 때 컨트롤 플레인 로그를 어떻게 조회하는지 AWS 지원팀에서 안내받았다.
   • 용량이 갑자기 모자랄 때 새 노드 그룹을 급히 늘리는 런북을 쓴다.
   • 오토스케일링 그룹과 쿠버네티스가 보는 노드가 어긋나면 울리는 알림을 만든다.
   • 디스케줄러가 왜 cordon 된 노드에서 파드를 쫓아내는지 설정을 검토하고, 가능하면 고친다.
   • Pending 파드 수가 갑자기 늘면 울리는 알림을 만든다.

   교훈

   이 글은 교훈 대신 후속 조치를 적었다. 조치를 보면 팀에는 비상용 노드 그룹을 급히 추가하는 문서화된 절차가 없었다. 오토스케일링 그룹과 쿠버네티스가 보는 노드가 어긋날 때 울리는 알림도, Pending 파드가 급증할 때 울리는 알림도 없었다. 팀은 디스케줄러가 cordon 된 노드를 어떻게 다루는지도 분명히 알지 못했다.

   사례 보기
3. IL-0109 로그 수집을 고치려던 EKS 노드 롤오버가 꼬이면서 Auto Scaling 그룹이 정상 워커 노드를 모두 종료해 클러스터에 노드가 하나도 남지 않았다.

   DFDS2023sev1

   증상

   2023-02-14 09:33 UTC, 최종 사용자들이 CloudWatch 로그가 제대로 들어오지 않는다고 알려 왔다. 팀은 fluentd 를 조사하다가 컨테이너 런타임이 docker-shim 이 아니라 containerd 로 바뀌어 있다는 것을 찾았다. 전날 07:30 UTC 의 정기 노드 롤오버 때 containerd 가 실수로 기본 런타임으로 설정돼 있었다.

   서비스 중단리소스 삭제모니터링 중단

   촉발

   쿠버네티스 로그가 CloudWatch 로 가지 않는 문제를 고치려고 예정에 없던 노드 롤오버를 시작했다.

   원인

   설정 변경

   구성 요소

   컨테이너 런타임노드 런치 템플릿노드 풀Terraform텔레메트리 에이전트

   기여 요인

   자동화 증폭기본 설정 방치스테이징 불일치설정 테스트 부재런북 부재수동 조치 악화

   감지

   로그 문제는 최종 사용자들이 CloudWatch 로그가 이상하다고 알려 오면서 드러났다. 노드가 사라진 장애는 사후 분석 기준으로 2분 만에 감지됐다.

   조치

   • 10:49 UTC 에 노드 롤오버 스크립트로 새 노드를 추가하려 했지만 Docker Hub 타임아웃으로 실패했다.
   • 10:52 UTC 에 노드 롤오버 스크립트를 다시 돌려 새 노드를 추가했고, 11:01 UTC 에 로드밸런서가 새 노드를 정상으로 판단해 트래픽을 다시 보냈다.

   후속 조치

   • 롤오버 절차를 문서로 남기고, 특히 롤오버가 잘못됐을 때 할 수 있는 일을 적는다.
   • 롤오버 절차를 개선할 방법을 찾는다.
   • QA 시험에 fluentd 로그 수집을 넣어 로그가 처음부터 끝까지 전달되는지 확인한다.
   • fluentd 가 보내는 로그 데이터가 부족하거나 없을 때 울리는 경보를 추가한다.
   • 스테이징 환경을 만든다.
   • 잘못된 컨테이너 런타임을 고르지 못하게 막는 장치를 넣었다.

   교훈

   상황이 심각해져도 침착해야 한다. 서둘러 고치다 피해를 키우기보다 알려진 정상 설정으로 롤백하는 편이 낫다. 새 워커 노드를 띄우는 일은 cloudinit 스크립트의 어느 단계도 실패하지 않는다는 전제에 크게 기대고 있다.

   사례 보기
4. IL-0054 GKE 에서 옛 노드 풀을 드레인하자 로드밸런서가 ingress-nginx 파드가 없는 새 노드만 가리켜 클러스터의 모든 인그레스 트래픽이 끊겼다

   DevOps Hof2019

   증상

   GKE 클러스터에서 워크로드를 새 노드 풀로 옮기려고 옛 노드들을 드레인하던 중, 클러스터의 어떤 서비스에도 ingress-nginx 를 거쳐 접속할 수 없게 됐다.

   서비스 중단프로브 실패

   촉발

   새 노드 풀로 워크로드를 옮기려고 옛 노드를 cordon 하고 드레인했다.

   원인

   운영 실수

   구성 요소

   인그레스 컨트롤러kube-proxy노드 풀

   기여 요인

   기본 설정 방치미검증 가정

   감지

   옛 노드를 드레인하던 중 클러스터의 어떤 서비스에도 ingress-nginx 를 거쳐 접속할 수 없는 것을 팀이 알아챘다.

   조치

   • 옛 노드에 남아 있던 nginx-ingress-controller 파드를 지워 새로 Ready 상태가 된 노드에 다시 스케줄되게 했다.

   교훈

   트래픽에 영향을 줄 수 있는 변경을 하기 전에는 문서를 두 번 확인한다. externalTrafficPolicy 가 Local 이면 kube-proxy 는 다른 노드로 트래픽을 넘기지 않고, 로드밸런서 헬스 체크는 엔드포인트가 없는 노드에서 실패한다. cordon 한 노드는 로드밸런서 백엔드에서 빠진다. 이 둘이 겹치면 인그레스 컨트롤러 파드가 cordon 한 노드에만 남아 있을 때 트래픽이 모두 끊긴다.

   사례 보기
5. IL-0055 실패하는 CronJob 이 기본 concurrencyPolicy 때문에 겹겹이 쌓여 재시작하는 파드가 수천 개로 늘었고 클러스터가 내려갔다

   Target2018

   증상

   CronJob 하나가 계속 실패했다. 실패한 작업이 끝나지 않은 채 다음 작업이 계속 만들어졌고, 재시작을 거듭하는 파드가 수천 개로 쌓였다. 발표자의 계산으로는 매분 실행되는 작업 하나가 사흘 동안 실패하면 재시작하는 파드가 4320개가 된다.

   서비스 중단

   촉발

   CronJob 하나가 계속 실패했다.

   원인

   설정 변경

   구성 요소

   잡과 크론잡노드 풀

   기여 요인

   기본 설정 방치자동화 증폭

   교훈

   CronJob 을 배포할 때는 concurrencyPolicy 를 Replace 나 Forbid 로 정한다. 기본값에서는 실패한 작업이 쌓여 한꺼번에 재시작한다. 오토스케일링이 켜진 클러스터에서는 이렇게 늘어난 파드가 그대로 노드 증가와 비용 증가로 이어진다. 발표자는 의존 대상에 연결하지 못할 때 바로 죽어 재시작을 반복하기보다 지수 백오프로 일정 시간 재시도한 뒤 종료하라고 권했다. readiness 검사와 liveness 검사도 쓰라고 했다.

   사례 보기

원인별4