사례53건

53건 중 6~10번째

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-0104 Istio 의 공격적인 DNS 캐시 갱신과 클라이언트 포트 재사용, kube-proxy 가 종료된 파드의 conntrack 항목을 정리하지 않는 문제, 2분짜리 UDP conntrack 기본 타임아웃이 겹쳐 CoreDNS 파드가 OOMKilled 됐다.

   Cisco ThousandEyes2025

   증상

   2025년 9월 4일, CoreDNS 파드 하나가 OOMKilled 됐다.

   DNS 조회 실패오래된 엔드포인트 라우팅OOMKilled

   촉발

   CoreDNS 파드 하나가 OOMKilled 됐다.

   원인

   소프트웨어 결함

   구성 요소

   CoreDNSkube-proxyconntrack 테이블Istio

   기여 요인

   기본 설정 방치

   교훈

   장애는 Istio, kube-proxy, conntrack 각각의 동작이 겹쳐 생겼다. Istio 는 DNS 캐시를 공격적으로 갱신하며 클라이언트 포트를 다시 썼고, kube-proxy 는 conntrack 항목을 정리하지 않았고, conntrack 의 UDP 기본 타임아웃은 2분이었다. kube-proxy 쪽 문제는 쿠버네티스 v1.32 에서 고쳐졌다. 발표자는 Istio 가 아주 복잡한 일은 단순하게 만들지만 아주 단순한 일은 복잡하게 만든다고 평했다. 발표자는 또 Cilium 을 소개했다. Cilium 은 iptables 체인을 차례로 훑는 대신 맵으로 Service 를 찾고, eBPF 데이터 경로로 kube-proxy 를 완전히 대체할 수 있다.

   사례 보기
4. IL-0048 대형 EKS 클러스터에서 CoreDNS 가 VPC DNS 리졸버로 보내는 질의가 링크 로컬 트래픽의 초당 1024 패킷 한도에 걸려 DNS 조회가 간헐적으로 타임아웃됐다.

   unknown2025

   증상

   처음 들어온 보고는 CI 가 간헐적으로 실패한다는 것이었다. 실패는 tensorstore 안에서 났고, 오류는 ./tensorstore/util/result.h:420: Status not ok: status(): UNAVAILABLE: CURL error Could not resolve hostname: Could not resolve host: company-bucket.s3.amazonaws.com 이었다.

   DNS 조회 실패간헐적 타임아웃

   촉발

   호스트 네트워크를 쓰는 시스템 관리용 파드가 몇 초마다 sudo 명령을 실행했다. sudo 는 기본 설정에서 실행할 때마다 노드 자신의 호스트 이름을 조회했다. 파드의 resolv.conf 에 있는 ndots:5 와 검색 도메인 네 개 때문에 이 조회 하나가 A 와 AAAA 를 합쳐 질의 열 번이 됐고, CoreDNS 캐시에 걸리지 않은 질의가 VPC DNS 리졸버로 몰렸다.

   원인

   용량 한계

   구성 요소

   CoreDNS클라이언트 쪽 DNS 리졸버와 캐시VPC DNS 리졸버

   기여 요인

   한계 미인지기본 설정 방치

   감지

   CI 가 간헐적으로 실패한다는 보고가 시작이었다. tensorstore 가 company-bucket.s3.amazonaws.com 의 DNS 조회에 실패했다는 오류를 냈다. 글쓴이는 kubectl logs 로 CoreDNS 파드 로그를 뒤져 i/o timeout 오류를 찾았다.

   조치

   • 컨테이너 이미지에 /etc/sudoers.d/00-no-fqdn 파일로 Defaults !fqdn 을 넣어 sudo 가 호스트 이름을 조회하지 않게 했다.

   교훈

   EC2 에서 링크 로컬 주소로 가는 VPC DNS 질의에는 초당 1024 패킷의 한도가 있다. 한도를 넘은 UDP 패킷은 버려지는데, 보낸 쪽은 이를 알 수 없다. 노드에서 ethtool -S eth0 | grep linklocal_allowance_exceeded 로 이 한도에 걸렸는지 볼 수 있다. ndots:5 와 검색 도메인 때문에 FQDN 이 아닌 이름 하나가 질의 다섯 번이 되고, AAAA 까지 물으면 열 번이 된다. sudo 는 기본 설정에서 실행할 때마다 호스트 이름을 조회하므로, sudo 를 자주 부르는 파드는 DNS 트래픽을 많이 만든다.

   사례 보기
5. IL-0247 쿠버네티스로 옮긴 검색 시스템 Manas 에서 요청 백만 건에 한 건이 평소보다 100배 느려졌다

   Pinterest2025

   증상

   2025년 초 쿠버네티스 플랫폼 PinCompute 로 옮긴 검색 시스템 Manas 의 시험 클러스터에 트래픽을 보내자, 적지만 꾸준한 비율의 요청이 타임아웃을 냈다.

   지연 시간 증가간헐적 타임아웃

   원인

   소프트웨어 결함

   구성 요소

   텔레메트리 에이전트리눅스 커널

   기여 요인

   기본 설정 방치

   감지

   이전을 검증하려고 시험 클러스터에 트래픽을 보내며 성능 시험을 하던 중, 적지만 꾸준한 비율의 요청이 타임아웃을 내는 것을 발견했다.

   조치

   • 한 줄 설정 변경으로 모든 PinCompute 노드에서 cAdvisor 의 작업 집합 크기 추정을 껐다. 같은 내용을 cAdvisor 저장소에 GitHub 이슈로 올렸다.

   교훈

   자원 격리는 까다롭다. CPU 격리를 해도 프로세스가 이웃 프로세스의 영향에서 완전히 벗어나지는 않는다. 문제 범위를 좁히는 일이 중요했다. PinCompute AMI 가 원인이 아님을 확인하자 범위가 좁아졌고, 소득 없는 조사를 많이 피할 수 있었다. 시스템이 제대로 동작하지 않게 될 때까지 하나씩 꺼 보는 단순한 블랙박스 디버깅도 효과가 있었다. 이것도 문제를 반씩 나눠 범위를 좁히는 방법의 하나다.

   사례 보기

원인별10