사례7건

7건 중 1~5번째

1. 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 를 완전히 대체할 수 있다.

   사례 보기
2. IL-0079 GKE 노드가 새 ubuntu_containerd 이미지로 자동 업그레이드된 뒤 커널에서 kube-proxy 가 쓰는 iptables 확장이 빠져, 여러 GKE 클러스터의 인그레스 트래픽이 완전히 끊겼다.

   Altinity2025

   증상

   토요일인 5월 17일 이른 시각에 OpsGenie 알림이 울렸다. Altinity.Cloud 의 ClickHouse 클러스터 하나가 갑자기 조용해졌다. 쿼리도, 지표도, 접속하려는 고객의 로그도 들어오지 않았다. 파드는 모두 Running 이었고 노드도 정상으로 보였지만 데이터베이스까지 오는 트래픽이 없었다.

   서비스 중단

   촉발

   GKE 가 노드를 ubuntu_containerd 1.32.3-gke.1785003 이미지와 커널 6.8.0-1022-gke 로 자동 업그레이드했다. 이 커널은 nf_tables 모듈의 패키징이나 로딩 방식에 회귀가 있어 kube-proxy 가 쓰는 iptables 확장을 지원하지 않았다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   kube-proxy노드 운영체제 이미지리눅스 커널클라우드 로드 밸런서

   기여 요인

   미패치 알려진 버그단계적 배포 부재

   감지

   OpsGenie 알림으로 알았다. ClickHouse 클러스터 하나에서 쿼리, 지표, 고객 접속 로그가 모두 끊겼고, 곧 다른 클러스터들도 같은 상태가 됐다.

   조치

   • 아직 영향받지 않은 클러스터에 유지보수 제외를 걸어 업그레이드를 모두 멈췄다. 이 조치로 문제가 GKE 에서 운영하는 모든 클러스터로 번지는 것을 막았다.
   • 로드밸런서 헬스 체크 정책을 바꿔 kube-proxy 헬스 체크 실패를 무시하게 했다. kube-proxy 에 필요한 확장이 없는 노드로도 트래픽이 흐르면서 서비스가 회복됐다.
   • 영향받은 클러스터 전부를 ubuntu_containerd 에서 nf_tables 문제가 없는 다른 커널을 쓰는 cos_containerd 이미지로 옮기기 시작했다. 노드를 새 이미지로 다시 만들어야 해서 짧은 다운타임이 생겼다.

   후속 조치

   • 회귀를 더 일찍 잡도록 이미지 사전 테스트 파이프라인을 넓힌다.
   • GKE 자동 업그레이드 예정 알림을 켜서 미리 대비한다.
   • 모든 클러스터에 GKE 유지보수 기간을 반드시 설정해 업그레이드가 배포되는 시점을 직접 정한다.
   • Google 이슈 트래커에 올린 커뮤니티 이슈를 추적하며 고쳐진 Ubuntu 이미지를 기다린다.

   교훈

   관리형 Kubernetes 의 노드 자동 업그레이드는 사용자가 검증하지 않은 커널을 운영 노드에 올린다. 클라우드 업체의 이미지 검증만 믿으면 이런 회귀를 막지 못한다. IPv6 를 쓰지 않아도 kube-proxy 는 IPv6 iptables 규칙을 적용하므로, 그 적용이 실패하면 로드밸런서 헬스 체크도 실패해 모든 인그레스가 끊길 수 있다. 영향받은 버전이 확인되면 아직 업그레이드되지 않은 클러스터의 업그레이드부터 멈춰야 피해가 번지지 않는다. Altinity 는 영향받은 사용자에게 externalTrafficPolicy: Cluster 로 바꿔 kube-proxy 헬스 체크를 끄고, 운영 노드 이미지를 cos_containerd 로 바꾸고, 고쳐진 이미지가 확인될 때까지 자동 업그레이드를 멈추라고 권한다.

   사례 보기
3. IL-0178 EKS 에서 HPA 가 파드를 줄일 때 엔드포인트 제거보다 컨테이너 종료가 먼저 끝나 502 가 났고, 블루/그린 전환 뒤에는 conntrack 에 남은 연결이 삭제된 파드로 가서 클라이언트가 타임아웃을 받았다.

   Lotte E-commerce2022

   증상

   롯데온 서비스에서 HPA 가 파드 수를 줄이는 스케일 인 때마다 일정 시간 동안 요청이 오류로 끝났다. 엔드포인트에서 파드 IP 가 빠지기 전에 컨테이너가 먼저 지워지면, 들어오는 트래픽이 여전히 지워진 컨테이너로 가서 502 에러가 났다.

   오류율 상승간헐적 타임아웃오래된 엔드포인트 라우팅

   촉발

   두 가지 작업이 각각 장애를 일으켰다. 하나는 HPA 가 파드를 줄이는 스케일 인이고, 다른 하나는 Service 레이블 셀렉터를 그린 디플로이먼트로 바꾼 뒤 블루 파드를 지우는 블루/그린 배포다.

   원인

   DNS·네트워크 장애

   구성 요소

   수평 파드 오토스케일러파드 종료 처리kube-proxyconntrack 테이블클라우드 로드 밸런서인그레스 컨트롤러

   기여 요인

   기본 설정 방치

   조치

   • 컨테이너 종료를 늦춰 Service 엔드포인트에서 파드가 빠질 때까지 기다리게 했다. 방법은 애플리케이션의 SIGTERM 처리 로직에서 기다리게 하거나 preStop 훅에 sleep 을 넣는 것이다. 무한정 기다리지 않도록 terminationGracePeriodSeconds 도 함께 설정한다.
   • 대상 그룹 한도인 1000개를 넘지 않는 일부 워크로드에서 ingress 로 만드는 ALB 를 instance 모드에서 IP 모드로 바꿨다.

   후속 조치

   • ALB IP 모드를 전체 워크로드에 점진적으로 적용한다.

   교훈

   Kubernetes 에서 엔드포인트 제거와 컨테이너 종료는 동시에 진행되므로, 종료를 늦추지 않으면 스케일 인 때 지워진 컨테이너로 트래픽이 가서 502 가 날 수 있다. preStop 훅으로 기다릴 때는 terminationGracePeriodSeconds 로 최대 대기 시간을 함께 정해야 한다. ALB 를 instance 모드로 쓰면 트래픽이 노드의 iptables 와 conntrack 을 거치므로, 블루/그린 전환 뒤에도 established 연결이 지워진 파드로 갈 수 있다. IP 모드는 이 경로를 없애고 네트워크 홉도 줄이지만, 대상 그룹에 대상을 1000개까지만 넣을 수 있다.

   사례 보기
4. IL-0049 CoreDNS 파드가 줄어든 뒤 kube-proxy 가 conntrack 항목을 지우지 못해 일부 서비스의 DNS 요청이 없어진 파드로 가면서 5xx 가 쏟아졌다

   Preply2020

   증상

   Prometheus 모니터링이 서비스 A, B, C 에서 5xx 비율이 높아진 것을 잡아 당직자를 호출했다. 당직 엔지니어들은 22시 18분부터 VictorOps 호출을 받기 시작했다. Kibana 에서도 5xx 비율이 올라간 것이 보였다.

   DNS 조회 실패오류율 상승오래된 엔드포인트 라우팅

   촉발

   클러스터 안의 부하가 낮아지자 CoreDNS-autoscaler 가 CoreDNS 파드를 3개에서 2개로 줄였다.

   원인

   DNS·네트워크 장애

   구성 요소

   CoreDNSkube-proxyconntrack 테이블

   기여 요인

   자동화 증폭초기 신호 무시캐시 부재

   감지

   Prometheus 모니터링이 서비스 A, B, C 에서 5xx 비율이 높아진 것을 잡아 VictorOps 로 당직자를 호출했다. 포스트모템이 적은 감지 시간은 4분이다.

   조치

   • 22시 39분에 당직 엔지니어들이 해당 서비스의 최신 릴리스를 되돌렸다.
   • 정기 배포로 새 노드가 생기자 CoreDNS-autoscaler 가 CoreDNS 파드를 다시 늘렸고, conntrack 테이블이 자동으로 새로 쓰였다.

   후속 조치

   • CoreDNS 의 오토스케일러를 끈다.
   • 운영 환경에 DNS 캐시 서버를 둔다.
   • conntrack 사용량을 모니터링한다.

   교훈

   모니터링은 장애를 빨리 잡았고 대응도 빠르고 체계적이었다. 노드는 어떤 한도에도 닿지 않았다. 진짜 근본 원인은 아직 모른다. conntrack 의 특정 버그로 보인다. 팀이 정한 후속 조치는 모두 장애가 낳는 결과를 막는 것이지 근본 원인을 고치는 것이 아니다. 팀은 DNS 에서 문제가 날 수 있다는 것을 알고 있었지만 이 일을 우선해서 다루지 않았다.

   사례 보기
5. IL-0013 노드 RAM 을 절반으로 줄이자 conntrack 테이블이 가득 차 집계 서비스에 연결 리셋과 오류가 늘었다

   loveholidays2020

   증상

   서비스 구조를 바꾸고 노드 풀 크기를 조정하고 하위 서비스를 샤딩한 직후, 집계 서비스에 여러 연결 문제가 생기고 오류율이 올라갔다.

   연결 리셋오류율 상승간헐적 연결 실패

   촉발

   집계 서비스가 도는 노드의 RAM 을 절반으로 줄였고, 하위 서비스를 샤딩하면서 추적해야 할 연결 수는 두 배가 됐다. conntrack_max 는 노드 RAM 에 비례하므로 노드가 추적할 수 있는 연결 수는 줄고 추적할 연결은 늘었다.

   원인

   용량 한계

   구성 요소

   conntrack 테이블kube-proxy노드 풀HAProxy

   기여 요인

   한계 미인지용량 계획 부재한계 경보 부재

   감지

   팀은 먼저 서비스의 연결 문제와 오류율 상승을 알아챘다. HAProxy 가 보고하는 연결 리셋 오류가 계속 늘었고, 팀은 node_nf_conntrack_entries 를 node_nf_conntrack_entries_limit 과 겹쳐 보고 일부 노드의 conntrack 테이블이 바닥난 것을 확인했다.

   조치

   • 집계 서비스를 RAM 이 더 큰 노드에 배치했다.
   • 노드 하나에 뜨는 집계 서비스 파드 수를 제한했다.

   후속 조치

   • conntrack 사용률이 75% 를 넘으면 경보가 가도록 Prometheus 쿼리 (node_nf_conntrack_entries / on (pod) node_nf_conntrack_entries_limit / on (pod) group_right kube_pod_info) > 0.75 로 경보 규칙을 만들었다.

   교훈

   쿠버네티스 노드의 conntrack_max 는 노드 RAM 에 비례해 정해진다. 부하가 큰 애플리케이션은 특히 작은 노드에서 conntrack_max 를 쉽게 넘겨 연결 리셋과 타임아웃을 일으킨다. 노드를 작게 바꾸면 추적할 수 있는 연결 수도 함께 줄어든다. conntrack 사용률은 지표로 보고 경보를 걸어 둬야 한다.

   사례 보기

원인별5