사례3건

3건 중 1~3번째

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-0028 쿠버네티스에서 Temporal History 파드가 CPU 사용률이 60% 아래인데도 CPU 스로틀링을 받아 요청 지연이 불안정했다

   Temporal2023

   증상

   자체 호스팅한 Temporal Server 의 History 서비스에서 요청 지연이 일정하지 않았다. 대시보드에서 history 파드의 CPU 사용률은 60% 아래로 나왔지만 파드는 CPU 스로틀링을 받고 있었다.

   CPU 스로틀링지연 시간 증가

   촉발

   노드는 8코어였고 history 파드의 CPU 한도는 2코어였는데, Go 로 작성된 Temporal Server 는 GOMAXPROCS 기본값대로 노드의 코어 8개를 모두 쓸 수 있다고 보고 동작했다.

   원인

   용량 한계

   구성 요소

   컨테이너 CPU 한도언어 런타임 설정Prometheus

   기여 요인

   기본 설정 방치모니터링 사각지대

   감지

   kube-prometheus 대시보드에서 history 파드의 CPU 사용률은 60% 아래였지만 스로틀링 비율은 0보다 컸다. 15초 이상 간격으로 수집하는 CPU 사용률 지표로는 0.1초 단위로 일어나는 스로틀링이 보이지 않으므로, 스로틀링 지표를 따로 보고서야 문제를 찾았다.

   조치

   • history 파드 배포에 GOMAXPROCS 환경 변수를 CPU 한도와 같은 2로 설정했다.

   후속 조치

   • Temporal 1.21.0 부터는 CPU 한도가 있고 GOMAXPROCS 환경 변수가 따로 설정되지 않았으면 서버가 GOMAXPROCS 를 CPU 한도에 맞춰 자동으로 설정한다.

   교훈

   CPU 사용률이 낮게 나와도 스로틀링은 일어날 수 있으므로 스로틀링 지표를 따로 관찰해야 한다. Go 서비스에서는 GOMAXPROCS 를 CPU 한도의 정수 코어 수에 맞춘다. GOMAXPROCS 는 CPU 요청값으로는 자동 설정되지 않으므로, CPU 한도를 쓰지 않는다면 CPU 요청값과 같거나 조금 큰 값으로 직접 설정한다. 가능하면 CPU 한도를 쓰지 말고 CPU 요청값을 적절히 잡은 뒤 노드 CPU 사용량을 지켜본다. 노드 CPU 가 자주 바닥나면 파드가 요청값을 넘어 자주 버스트한다는 뜻이므로 요청값을 다시 잡는다.

   사례 보기
3. IL-0033 kube-dns 파드 사이의 트래픽 불균형과 DNS 초당 패킷 한도 때문에 외부 DNS 조회가 많은 여러 서비스의 지연 시간이 20초까지 늘었다

   Airbnb2019

   증상

   한 서비스의 지연 시간 그래프에 5월 10일부터 스파이크가 보이기 시작했다. 처음에는 1초 안팎까지 튀었고, 이어서 5초, 다시 20초로 올라간 뒤 꽤 오랫동안 그 수준에 머물렀다.

   지연 시간 증가간헐적 타임아웃부하 불균형DNS 조회 실패

   촉발

   여러 서비스가 외부 DNS 조회를 많이 보냈고, 그 질의가 모두 kube-dns 를 거쳤다.

   원인

   용량 한계

   구성 요소

   kube-dnskube-proxy클라이언트 쪽 DNS 리졸버와 캐시

   기여 요인

   기본 설정 방치

   감지

   문제는 서비스의 지연 시간 그래프에서 처음 드러났다. 같은 모양이 여러 서비스에서 나타나자 팀은 공통점을 찾았고, kube-dns 파드별 질의량을 비교해 불균형을 찾아냈다.

   교훈

   기본 설정에서 파드는 클러스터 IP 로 DNS 서버를 찾고, dnsPolicy 기본값인 ClusterFirst 때문에 외부 이름 조회도 kube-dns 를 먼저 거친다. 쿠버네티스 DNS 해석이 필요 없는 파드는 dnsPolicy 를 Default 로 두거나, None 으로 두고 세부 값을 직접 정할 수 있다. iptables 는 로드 밸런서가 아니어서 클러스터 IP 뒤의 파드에 부하를 고르게 나누지 못한다. 발표자들은 DNS 정책을 초기부터 자주 확인하고 용도에 맞는 정책을 쓰라고 했다.

   사례 보기

원인별1