Incident Library
  • 원인
  • 구성 요소
  • 증상
  • 기여 요인
  • 사례

사례26건

26건 중 6~10번째

  1. 증상

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

    원인
    구성 요소
    기여 요인
    감지

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

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

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

  2. 증상

    Mercari 의 GKE 클러스터에서 여러 서비스가 한꺼번에 DNS 이름 해석에 실패하기 시작했다. 요청은 타임아웃으로 끝났고, 마이크로서비스가 서로 엮여 있어서 실패가 연쇄로 번지며 운영 장애가 됐다. 회사는 이 장애를 Sev1 로 분류했다.

    촉발

    피크 시간대에 클러스터가 처리하는 초당 요청 수가 크게 늘면서 DNS 질의가 소수의 kube-dns 파드로 몰렸다.

    원인
    구성 요소
    기여 요인
    감지

    피크 시간대에 NXDOMAIN, 잘린 응답, "failed to refresh DNS cache" 오류가 반복되는 것을 보고 kube-dns 가 한계에 이르렀다는 것을 알았다.

    조치
    • Platform 팀만 내부 시험용으로 쓰는 Laboratory GKE 클러스터에 nodeAffinity 를 걸어 NodeLocal DNSCache 를 배포하고, 전체 워크로드에 영향을 주지 않은 채 효과를 측정했다.
    • 노드 풀에 레이블을 붙여 NodeLocal DNSCache 파드가 뜰 수 있게 하는 방식으로 Dev 와 Prod 환경 전체에 점진적으로 배포했다.
    교훈

    트래픽이 많은 쿠버네티스 클러스터에서는 DNS 를 최적화하는 일이 중요하다. 모든 파드가 몇 개의 kube-dns 파드에 기대는 구조는 피크 시간대에 장애 지점이 됐고, 노드 단위 캐시를 두자 DNS 트래픽과 오류가 크게 줄었다.

  3. 증상

    2025년 3월 17일 18:05 UTC 부터 GitHub.com 의 웹 요청과 API 요청이 간헐적으로 실패했다. 실패는 주로 풀 리퀘스트와 이슈 관련 요청에서 났고, 영향을 받은 사용자는 일부였다. 18:39 UTC 에 상태 페이지에 Issues 의 성능 저하 신고를 조사 중이라는 첫 공지가 올라왔다.

    촉발

    GitHub 이 쿠버네티스 인프라에 프레임워크 업그레이드를 적용했고, 이 업그레이드가 커널 패닉을 일으켰다.

    원인
    구성 요소
    기여 요인
    –
    감지

    상태 페이지 첫 공지는 장애 시작 34분 뒤인 18:39 UTC 에 올라왔고, Issues 의 성능 저하 신고를 조사 중이라는 내용이었다.

    조치
    • 업그레이드한 프레임워크를 이전 버전으로 다운그레이드해 영향을 줄였다.
    • 문제를 일으킨 기능을 끌 수 있게 된 뒤 그 기능을 껐다.
    후속 조치
    • 업그레이드가 왜 예상하지 못한 문제를 일으켰는지 조사했다.
    • 같은 문제가 다시 나지 않도록 임시 조치를 했다.
    • 장기적인 패치 계획을 세운다.
    • 비슷한 종류의 문제에 빨리 대응할 수 있도록 관측성을 높인다.
  4. 증상

    배포 도중 쿠버네티스로 들어오는 트래픽이 갈 곳을 잃기 시작했다. 일부 API 요청이 타임아웃됐다.

    촉발

    오래 걸리는 NGINX 전체 리로드가 진행되는 동안 배포 롤아웃으로 백엔드 엔드포인트가 바뀌었다. ingress-nginx 컨트롤러에는 enable-serial-reloads 옵션이 켜져 있었다.

    원인
    구성 요소
    기여 요인
    –
    조치
    • 문제를 풀어 보려고 NGINX Ingress 컨트롤러를 재시작했다.
    후속 조치
    • enable-serial-reloads 가 엔드포인트 동적 갱신을 막는 문제를 kubernetes/ingress-nginx 에 이슈로 올린다.
    교훈

    자원 소모를 막으려고 켠 무해해 보이는 플래그 하나가, 라우팅이 실제 배포 상태와 어긋나는 구간을 만들 수 있다. 엔드포인트 동적 갱신이 리로드에 묶이면 배포 중 트래픽이 사라진 파드로 간다.

  5. 증상

    파드 안의 애플리케이션이 초당 수백 건씩 클러스터 내부 서비스의 이름을 조회하자 no such host 와 i/o timeout 오류가 자주 났다. 쿠버네티스 플랫폼을 쓰는 팀은 클러스터의 DNS 서버에 성능 문제가 있다고 보고 Cloud Platform 팀에 문의했다.

    촉발

    MySQL 클러스터 감시 애플리케이션이 감시하는 클러스터 수가 늘어났고, 그 뒤부터 이름 조회 오류가 잦아졌다.

    원인
    구성 요소
    기여 요인
    감지

    Cloud Platform 팀은 쿠버네티스 플랫폼을 쓰는 팀에게서 클러스터 DNS 서버에 성능 문제가 있다는 문의를 받고 알게 됐다.

    조치
    • 커널 파라미터 net.core.netdev_max_backlog 값을 늘렸다.
    • softnet 지표에 알림을 설정했다.
    • softnet 알림에 대응하는 런북을 마련했다.
    후속 조치
    • veth 인터페이스를 netkit 인터페이스로 바꿔 파드의 송신 패킷이 backlog 큐를 거치지 않고 물리 장치로 바로 가게 하는 방안을 검증한다. netkit 은 리눅스 커널 6.7 에 들어온 가상 네트워크 장치이고, Cilium 1.16 부터 쓸 수 있다.
    교훈

    netdev_max_backlog 를 늘리고 softnet 알림과 런북을 두면 같은 장애가 덜 나고, 나더라도 일찍 알아챌 수 있다. 다만 값을 늘리는 것은 근본 대책이 아니어서, 더 많은 패킷을 보내는 파드가 배포되면 backlog 큐가 다시 차고 패킷이 버려질 수 있다.

내 클러스터에도 있는지 확인하기

이 26건에서 가장 많이 나오는 구성 요소: 리눅스 커널, 클라이언트 쪽 DNS 리졸버와 캐시. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.

원인별7

설정 변경3건

  1. IL-0179 DEBUG 로그가 쏟아지자 동기 로깅을 하던 요청 스레드들이 가득 찬 stdout 파이프에서 멈춘 채 DB 커넥션을 쥐고 있어, HikariCP 커넥션 풀이 고갈되고 요청이 30초 주기로 한꺼번에 실패했다.
  2. IL-0208 GitLab Helm 차트 업그레이드가 Service 와 Deployment 의 포트 이름을 바꿔 GCP 로드 밸런서가 다시 구성되는 동안 GitLab.com 요청이 느려지고 50x 오류가 났다
    GitLab2022
  3. IL-0035 ElastAlert 에 새로 넣은 알림 규칙 때문에 ElastAlert 파드가 메모리를 끝없이 써서 노드가 잇달아 NotReady 가 되었고, 같은 클러스터의 도구와 Grafana, Prometheus 가 함께 흔들렸다.
    NU.nl2019

DNS·네트워크 장애4건

  1. IL-0448 Job 파드가 15분 넘게 걸리는 LLM 에이전트 요청의 응답을 일정 확률로 받지 못하고 계속 기다렸다
  2. IL-0178 EKS 에서 HPA 가 파드를 줄일 때 엔드포인트 제거보다 컨테이너 종료가 먼저 끝나 502 가 났고, 블루/그린 전환 뒤에는 conntrack 에 남은 연결이 삭제된 파드로 가서 클라이언트가 타임아웃을 받았다.
  3. IL-0057 EKS 노드의 SNAT 과정에서 conntrack 경합으로 바깥으로 나가는 TCP 연결이 1초나 3초씩 늦어져, 서비스 간 호출이 많은 서비스의 p99 지연이 늘었다.
    Prezi2019
  4. IL-0047 conntrack 경합으로 DNS 조회가 5초씩 늦어져 파드 사이 요청이 간헐적으로 5초, 10초, 15초씩 지연되었다.

용량 한계9건

  1. IL-0155 NYC1 의 일부 DOKS 클러스터에서 공유 CPU 노드 위의 CoreDNS 때문에 DNS 가 간헐적으로 실패하고 NodeNotReady 가 났다
  2. IL-0413 Microsoft 클라우드 LLM 추론 서비스의 추론 엔진이 몰린 트래픽에 포화돼 HTTP 429·5xx 와 타임아웃을 냈다
  3. IL-0048 대형 EKS 클러스터에서 CoreDNS 가 VPC DNS 리졸버로 보내는 질의가 링크 로컬 트래픽의 초당 1024 패킷 한도에 걸려 DNS 조회가 간헐적으로 타임아웃됐다.
  4. IL-0080 트래픽이 몰린 GKE 클러스터에서 kube-dns 가 DNS 질의를 감당하지 못해 여러 서비스의 이름 해석이 실패하고 운영 장애로 번졌다.
  5. IL-0440 파드가 보낸 DNS 쿼리 패킷이 노드에서 버려져 클러스터 내부 서비스의 이름 조회가 no such host 와 i/o timeout 으로 자주 실패했다
    Cybozu2024
  6. IL-0169 FR-PAR 의 Scaleway Kubernetes API 가 메모리 부족으로 쓰러져 노드 인증이 막히고 Kapsule 노드가 NotReady 가 됐다.
  7. IL-0386 Google Cloud 로 옮긴 뒤 GKE 노드에서 Postgres 연결 타임아웃과 memcached i/o timeout 이 간헐적으로 튀었다
  8. IL-0445 EKS 로 옮기던 레거시 시스템에서 conntrack 테이블이 넘쳐 연결이 끊겼고, 이어 CoreDNS 파드가 축출될 때와 node-local-dns 를 넣은 뒤에 DNS 오류가 났다
  9. IL-0033 kube-dns 파드 사이의 트래픽 불균형과 DNS 초당 패킷 한도 때문에 외부 DNS 조회가 많은 여러 서비스의 지연 시간이 20초까지 늘었다
    Airbnb2019

소프트웨어 결함7건

  1. IL-0247 쿠버네티스로 옮긴 검색 시스템 Manas 에서 요청 백만 건에 한 건이 평소보다 100배 느려졌다
  2. IL-0081 ingress-nginx 의 enable-serial-reloads 옵션이 NGINX 리로드 중에 엔드포인트 동적 갱신을 막아, 배포 중 트래픽이 이미 없는 파드로 가면서 API 요청이 타임아웃됐다.
    Cresta2025
  3. IL-0161 앞선 API 업데이트가 의도대로 동작하지 않아 토론토 데이터센터에서 새 LKE 클러스터 프로비저닝이 타임아웃으로 사흘 넘게 실패했다.
    Linode2024
  4. IL-0112 나중에 회수된 EKS 노드 AMI 로 노드를 교체한 뒤 노드가 PLEG is not healthy 를 보고하며 NotReady 를 오갔고 파드 네트워크 타임아웃이 났다
    DFDS2022
  5. IL-0146 Central India 에서 새로 만든 Azure CNI 클러스터의 VM 이 높은 값의 MAC 주소를 받으면서 bridge 모드 Azure CNI 의 오래된 버그가 드러나 터널 연결이 끊기고 kubectl exec 와 파드 간 통신이 타임아웃됐다.
  6. IL-0190 쿠버네티스 업그레이드로 etcd 리더가 있던 노드가 갑자기 종료된 뒤, Cortex distributor 두 개가 옛 리더와 맺은 TCP 연결이 멈춘 채 그 연결을 계속 써서 런던 리전 Hosted Prometheus 쓰기가 12분 동안 일부 실패했다.
  7. IL-0012 CPU limit 과 커널 CFS 쿼터 버그로 파드가 과하게 스로틀링돼 헬스 체크가 실패하고 애플리케이션이 멈췄다
    Omio2020

업그레이드로 깨진 호환성1건

구성 요소
기여 요인
–
조직
  1. IL-0201 프레임워크 업그레이드가 쿠버네티스 인프라에서 커널 패닉을 일으켜 GitHub.com 의 웹과 API 요청이 15시간 넘게 간헐적으로 실패했다
    GitHub2025

클라우드 제공자 장애1건

기여 요인
–
  1. IL-0364 'default' 인그레스 컨트롤러로 들어오는 트래픽의 25% 가 느려졌다

운영 실수1건

조직
  1. IL-0115 OpenAI 의 운영 AKS 클러스터 세 개 중 하나가 사람의 실수로 통째로 내려가 Codex, Embeddings, 구형 GPT 모델과 파인튜닝 모델이 최대 12시간 동안 제대로 응답하지 못했다
    OpenAI2022