사례36건

36건 중 11~15번째

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-0161 앞선 API 업데이트가 의도대로 동작하지 않아 토론토 데이터센터에서 새 LKE 클러스터 프로비저닝이 타임아웃으로 사흘 넘게 실패했다.

   Linode2024

   증상

   2024년 4월 22일 14:05 UTC 쯤 토론토 데이터센터에서 새 LKE 클러스터가 프로비저닝되지 않았다.

   클러스터·노드 생성 정체간헐적 타임아웃

   촉발

   앞서 배포한 API 업데이트가 의도대로 동작하지 않았고, 새 LKE 클러스터를 프로비저닝할 때 타임아웃을 일으켰다.

   원인

   소프트웨어 결함

   구성 요소

   노드 풀

   기여 요인

   –

   감지

   2024년 4월 22일 14:05 UTC 쯤 Linode 팀이 토론토 데이터센터에서 새 LKE 클러스터가 프로비저닝되지 않는 것을 알아채고 조사를 시작했다.

   조치

   • 4월 23일 15:03 UTC 에 문제가 된 토론토 데이터센터의 인프라를 새 LKE 클러스터 프로비저닝에 쓰지 않도록 껐다.
   • 4월 25일 16:45 UTC 쯤 의도대로 동작하지 않던 API 업데이트를 바로잡는 수정을 적용했고, 18:05 UTC 에 새 클러스터 생성이 완전히 돌아온 것을 확인했다.
   • 수정을 적용한 뒤 잠시 빼 두었던 인프라를 다시 프로비저닝에 넣었다.

   교훈

   원인은 오류가 드러난 인프라가 아니라 앞서 배포한 API 업데이트에 있었다. 그런데도 실패는 대부분 한 데이터센터의 백엔드 자원 하나에 몰렸다. 그 자원을 새 클러스터 프로비저닝에서 빼서, 근본 원인을 찾는 데 걸린 사흘 동안 고객 영향을 줄였다.

   사례 보기
4. IL-0114 클러스터 용량을 늘리던 중 버전이 고정되지 않은 VPC CNI 플러그인이 자동으로 업데이트돼 새 파드가 IP 를 받지 못하고 Pending 에 머물렀고, 메인넷 운영 환경의 정산이 약 3.5시간 멈췄다.

   CoW Protocol2024

   증상

   2024년 4월 19일 16:40 UTC 에 메인넷 운영 환경에서 정산이 멈췄다. 핵심 서비스가 내려가 있었다.

   파드 PendingIP 주소 고갈파드 축출서비스 중단

   촉발

   클러스터 용량을 늘리는 IaC 자동화가 돌면서, IaC 에 버전이 고정되지 않은 VPC CNI 플러그인이 자동으로 업데이트됐다.

   원인

   설정 변경

   구성 요소

   AWS VPC CNI노드 풀

   기여 요인

   버전 미고정장애 중첩

   감지

   장애는 16:40 UTC 에 정산이 멈추면서 시작됐다. 팀은 23분 뒤인 17:03 UTC 에 CNI 버전 불일치를 원인으로 짚었다.

   조치

   • 19:00 UTC 쯤 쿠버네티스 클러스터 업그레이드를 시작했다.
   • 새 버전의 네트워크 플러그인을 쓰는 노드 그룹을 새로 만들었다.

   교훈

   IaC 스크립트에 버전을 명시해야 의도치 않은 업데이트를 막을 수 있다. 운영 환경일수록 쉽게 되돌릴 수 있는 변경 관리가 필요하다.

   사례 보기
5. IL-0021 GKE 의 COS 노드가 NVIDIA GPU 드라이버를 403 Forbidden 으로 받지 못해 새로 만든 GPU 노드를 쓸 수 없었다

   Google Cloud2024

   증상

   2024-03-12 US/Pacific 08:00 부터 GKE 에서 Container-Optimized OS 를 쓰는 GPU 노드가 일부 NVIDIA GPU 드라이버를 받지 못했다. 새로 만들거나 다시 만든 노드는 GPU 드라이버가 작동하지 않았고, 그 드라이버를 쓰는 워크로드가 돌지 못했다.

   GPU 인식 불가노드 NotReady

   원인

   의존성 장애

   구성 요소

   GPU 드라이버노드 운영체제 이미지노드 풀

   기여 요인

   자동화 증폭

   감지

   보고서는 Google 이 장애를 어떻게 알아챘는지 적지 않았다. GKE 사용자는 GPU 노드에서 드라이버를 설치할 때 "Failed to download GPU driver installer, status: 403 Forbidden" 오류를 보고 이 장애를 알아볼 수 있었다.

   조치

   • GPU 드라이버 다운로드를 시도하는 자동 노드 재생성을 멈췄다.
   • 드라이버를 공급하는 파트너와 함께 스토리지 버킷 접근 문제를 해결했다.

   교훈

   상태 페이지 보고서는 교훈이나 후속 조치를 적지 않았다.

   사례 보기

원인별9