사례32건

32건 중 6~10번째

1. IL-0095 엔지니어가 kubectl 이 다른 클러스터를 가리키는 줄 모르고 prod 네임스페이스를 지워 LEAP JupyterHub 가 약 1시간 동안 멈췄다.

   2i2c2025

   증상

   새 temple 클러스터에 허브를 배포하던 엔지니어가 NFS 문제를 만나 prod 네임스페이스를 지웠는데 삭제가 멈춘 채 끝나지 않았다. 파드 목록을 보니 다른 클러스터의 사용자 파드가 잔뜩 있었다.

   리소스 삭제서비스 중단

   촉발

   2i2c 엔지니어가 새 허브의 NFS 배포 버그를 우회하던 중, kubectl 이 LEAP 클러스터를 가리키고 있는 줄 모르고 prod 네임스페이스를 지웠다.

   원인

   운영 실수

   구성 요소

   영구 볼륨과 스테이트풀셋잡과 크론잡인그레스 컨트롤러Terraform

   기여 요인

   파괴적 변경 보호 장치 부재런북 부재

   감지

   네임스페이스를 지운 엔지니어가 삭제가 멈춘 것을 보고 파드 목록을 확인하다 다른 클러스터의 사용자 파드를 발견했고, 17:00 BST 에 장애를 선언했다. 모니터링 알림보다 먼저였다. 업타임 검사 실패 알림은 17:32 에 왔고 사용자의 404 제보는 17:37 에 들어왔다.

   조치

   • prod 네임스페이스에 남아 있던 사용자 파드 하나를 지워 멈춰 있던 네임스페이스 삭제를 끝냈다.
   • 재배포를 막고 있던 nfs-share-creator 잡을 종료했다.
   • 바뀐 NFS 서버 IP 주소로 prod 허브를 다시 배포했다.
   • 배포 도중 사용자가 서버를 띄우지 못하게 prod 인그레스를 지웠다.

   후속 조치

   • 장애 보고서를 쓴다.
   • "I deleted prod, what next?" 같은 상황에서 바로 볼 수 있는 짧은 장애 대응 문서를 쓴다.
   • jupyterhub-home-nfs 를 업그레이드하고 nfs-share-creator 잡을 없앤다.
   • deployer 시스템에 kubeconfig 컨텍스트가 중첩되는 것을 막는 보호 장치를 넣었다. 기본으로는 꺼져 있고 쓰는 사람이 켜야 동작한다.
   • 해당 엔지니어의 셸 설정을 바꿔 kubeconfig 컨텍스트를 더 쉽게 구분하게 했다.

   교훈

   쿠버네티스 리소스를 잃는 경우에 대비해 영구 스토리지를 Terraform 으로 따로 프로비저닝해 둔 설계 덕분에 사용자 데이터가 살아남았다. 반면 엔지니어에게 지금 어느 클러스터를 다루고 있는지 알려 주는 단서가 없었던 것이 실수로 이어졌다. 복구 방법을 알고 있어도 데이터 손실 위험을 확인해 줄 사람이 다른 시간대에 있어 재배포가 늦어졌다. NFS 배포의 순환 의존과 nfs-share-creator 잡도 복구를 늦췄다.

   사례 보기
2. IL-0170 설날 이벤트 트래픽이 평소의 3배를 넘자 Istio ingressGateway 가 있는 EKS 노드의 nf_conntrack 테이블이 가득 차 패킷이 버려졌고, 웹과 앱 서비스 전체가 멈췄다.

   Backpackr2025

   증상

   2024년 1월 설날 이벤트 중에 개발자 한 명이 Slack 에 장애가 의심된다고 알렸다. 여러 사람이 상황을 확인하는 사이에 웹과 앱 서비스 전체가 멈췄고, 백패커는 이벤트를 중단하기로 했다.

   서비스 중단

   촉발

   2024년 1월 설날 이벤트로 트래픽이 평소보다 3배 넘게 몰렸다.

   원인

   용량 한계

   구성 요소

   conntrack 테이블인그레스 컨트롤러Istio

   기여 요인

   단일 장애점기본 설정 방치모니터링 사각지대

   감지

   개발자 한 명이 Slack 에 장애가 의심된다고 제보했다. 여러 사람이 확인하는 동안 장애가 웹과 앱 서비스 전체로 번졌다.

   조치

   • 서비스 전체가 멈추자 설날 이벤트를 중단했다.

   후속 조치

   • 모든 노드의 nf_conntrack_max 를 올렸다. 일반 노드는 인스턴스 전체 메모리 바이트를 16384 로 나누고 다시 2로 나눈 값, istio 노드는 그 값의 3배를 쓴다. 메모리 16GB 인스턴스라면 net.netfilter.nf_conntrack_max 가 약 50만이 된다. 이 설정은 nodeOptimizer 데몬셋에 넣어 모든 노드에 자동으로 적용했다.
   • VirtualService 의 gateways 에 mesh 를 넣어 사이드카끼리 ingressGateway 를 거치지 않고 직접 통신하게 했다. HTTPS 로 도메인을 호출하면 TLS 오프로딩 때문에 여전히 ingressGateway 나 NLB 를 거쳐야 하므로, 메시 통신은 HTTP 호출에서 쓴다.
   • istio 노드를 12.5Gbps 의 c6.xlarge 에서 최대 25Gbps 대역폭을 내는 n 타입 인스턴스로 바꿨다.
   • 모니터링을 늘렸다. ENA 의 네트워크 대역폭과 패킷 드롭, ingressGateway 와 사이드카 프로세스 상태, CPU 와 메모리 사용률과 포화 상태를 지켜본다.

   교훈

   모든 트래픽이 노드 하나의 ingressGateway 를 거치면 그 노드가 단일 장애점이 된다. nf_conntrack 테이블은 기본 크기로 두면 트래픽이 갑자기 몇 배로 늘 때 가득 차고, 그 순간부터 패킷이 버려진다. 게이트웨이 노드는 일반 노드보다 conntrack 한도와 네트워크 대역폭을 넉넉하게 잡고, 네트워크 대역폭과 패킷 드롭 지표를 따로 지켜봐야 한다.

   사례 보기
3. IL-0053 Ingress NGINX Controller의 어드미션 웹훅이 인증 없이 열려 있어, 조작한 Ingress 객체로 NGINX 설정을 주입해 원격 코드를 실행하고 클러스터의 모든 Secret을 읽을 수 있었다

   Wiz2025

   증상

   운영 중 장애로 드러난 증상은 없다. 이 사례는 Wiz Research가 Ingress NGINX Controller의 어드미션 컨트롤러 코드를 검토하다 찾은 취약점들이고, 이 취약점들을 묶어 IngressNightmare라고 부른다. CVSS v3.1 기본 점수는 9.8이다.

   무단 접근과 낯선 워크로드

   촉발

   인증 없는 어드미션 웹훅에 악성 Ingress 객체를 담은 AdmissionReview 요청을 보내면 공격이 시작된다. 어드미션 컨트롤러는 받은 Ingress 객체로 임시 NGINX 설정 파일을 만들고 nginx -t로 검사한다. 이때 어노테이션 값과 객체 UID가 제대로 걸러지지 않은 채 설정 파일에 들어갔다.

   원인

   소프트웨어 결함

   구성 요소

   인그레스 컨트롤러어드미션 웹훅

   기여 요인

   기본 설정 방치과도한 영향 범위

   감지

   Wiz Research가 어드미션 컨트롤러 코드를 검토하다 찾았다. 2024년 12월 31일 CVE-2025-1974와 CVE-2025-24514를 쿠버네티스에 보고했고, 2025년 1월 2일 CVE-2025-1097을, 1월 21일 CVE-2025-1098을 보고했다. 일반 공개는 2025년 3월 24일이었다.

   조치

   • 쿠버네티스가 2025년 2월 7일 CVE-2025-1098, CVE-2025-1097, CVE-2025-24514 주입 취약점을 고친 내부 패치를 만들었다.
   • 쿠버네티스가 어드미션 컨트롤러에서 NGINX 설정 검사를 빼 CVE-2025-1974를 막았고, 2025년 2월 20일 이를 Wiz에 알렸다.
   • 수정이 들어간 Ingress NGINX Controller 1.12.1과 1.11.5가 나왔다.

   교훈

   Ingress NGINX Controller를 최신 버전으로 올리고, 어드미션 웹훅 엔드포인트를 외부에 노출하지 않는다. 바로 올릴 수 없다면 네트워크 정책으로 쿠버네티스 API 서버만 어드미션 컨트롤러에 닿게 하거나 어드미션 컨트롤러를 잠시 끈다. Helm으로 설치했다면 controller.admissionWebhooks.enabled=false 로 다시 설치하고, 직접 설치했다면 ingress-nginx-admission ValidatingWebhookConfiguration을 지우고 컨트롤러의 --validating-webhook 인자를 뺀다. 업그레이드한 뒤에는 어드미션 컨트롤러를 다시 켠다. 어드미션 컨트롤러는 흔히 놓치는 공격 지점이다. 인증 없이 도는 웹 서버이면서 권한이 높고, 클러스터 안 어느 파드에서나 닿는다. 공격자가 컨테이너 탈출이나 SSRF로 파드 네트워크에 들어오는 일은 생각보다 쉽다. Wiz는 최소 권한 설계가 없어 공격이 클러스터 장악까지 이어졌다고 지적했다. 걸러지지 않은 사용자 입력을 nginx -t로 검사하는 것 자체도 위험하다고 봤다. 2025년 11월 갱신된 글에 따르면 ingress-nginx는 2026년 3월에 유지보수를 끝내고 지원을 종료한다. 그러니 Gateway API나 다른 인그레스 컨트롤러로 옮겨야 한다.

   사례 보기
4. IL-0081 ingress-nginx 의 enable-serial-reloads 옵션이 NGINX 리로드 중에 엔드포인트 동적 갱신을 막아, 배포 중 트래픽이 이미 없는 파드로 가면서 API 요청이 타임아웃됐다.

   Cresta2025

   증상

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

   간헐적 타임아웃오래된 엔드포인트 라우팅지연 시간 증가

   촉발

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

   원인

   소프트웨어 결함

   구성 요소

   인그레스 컨트롤러

   기여 요인

   –

   조치

   • 문제를 풀어 보려고 NGINX Ingress 컨트롤러를 재시작했다.

   후속 조치

   • enable-serial-reloads 가 엔드포인트 동적 갱신을 막는 문제를 kubernetes/ingress-nginx 에 이슈로 올린다.

   교훈

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

   사례 보기
5. IL-0495 쿠버네티스에서 도는 내부 로드 밸런서 일부가 헬스 체크 실패로 한꺼번에 내려가고 남은 인스턴스가 연결 폭증으로 무너졌다

   HubSpot2024

   증상

   2024년 8월 27일 14:20 UTC부터 15:16 UTC까지 일부 HubSpot 고객이 계정에 로그인하지 못했고 콘텐츠에 접근하거나 도구를 쓰지 못했다. 모니터링은 플랫폼 전반에서 성능이 크게 떨어진 것을 잡았다.

   프로브 실패지연 시간 증가오류율 상승

   촉발

   트래픽 관리 시스템의 핵심 구성 요소를 평소대로 운영하던 중 로드 밸런서 스택이 경로 처리 설정을 갱신했다. 외부 문서에는 알려져 있었지만 HubSpot 은 몰랐던 문제 때문에 이 갱신이 헬스 체크 응답을 잠시 막았다.

   원인

   소프트웨어 결함

   구성 요소

   인그레스 컨트롤러라이브니스·레디니스 프로브

   기여 요인

   자동화 증폭여유 용량 부재

   감지

   HubSpot 은 14:20 UTC에 내부에서 문제를 확인했다. 14:23 UTC에는 모니터링 시스템이 플랫폼 전반의 성능 저하를 잡았고 장애 대응 팀이 소집됐다.

   조치

   • 14:59 UTC에 팀이 남은 로드 밸런서 인스턴스의 용량을 늘리는 작업에 들어갔다.
   • 15:04 UTC에 새 로드 밸런서 인스턴스가 올라와 시스템의 부하를 덜었고 트래픽이 안정되기 시작했다. 15:16 UTC에 시스템이 완전히 복구됐다.

   후속 조치

   • 헬스 체크가 잘못 타임아웃되지 않도록 설정을 고쳤다.
   • 설정 갱신 같은 작업 중에도 헬스 체크가 끊기지 않고 먼저 처리되도록 헬스 체크 시스템을 다시 설계한다.
   • 갑작스러운 트래픽 급증 때 더 많은 트래픽을 받을 수 있도록 로드 밸런서 용량을 늘렸다.
   • 트래픽 급증을 더 일찍 감지하고 실시간으로 부하를 나눠 특정 인스턴스 묶음에 부하가 몰리지 않도록 로드 밸런싱 구조를 고친다.
   • 대규모 장애 때 상태 페이지가 자동으로 갱신되도록 했다.
   • 상태 갱신이 더 빠르고 정확해지도록 모니터링 시스템을 소통 도구와 더 긴밀하게 연결한다.
   • 트래픽이 많은 상황을 재현하는 부하 테스트를 넓혀 약한 곳을 미리 찾는다.
   • 장애 상황을 일부러 만들어 플랫폼의 복원력을 정기적으로 시험하는 카오스 엔지니어링을 도입한다.
   • 최대 허용 연결 수 대비 현재 연결 수의 비율을 포함해 트래픽 흐름을 자세히 보는 새 지표를 넣었다.
   • 트래픽 흐름에 맞춰 자원 용량을 자동으로 조절하는 오토스케일링을 구현한다.

   교훈

   핵심 문제는 설정 갱신 중에 헬스 체크가 잠시 막혀 로드 밸런서 여러 대가 비정상으로 잘못 판정된 것이었다. 여러 인스턴스가 동시에 내려가자 남은 인스턴스에 부하가 몰려 연쇄 장애가 됐다. 넘치는 연결을 거부하는 보호 장치가 있었지만 트래픽 급증이 너무 빠르고 커서 감당하지 못했다. 모니터링은 장애를 빨리 잡았지만, HubSpot 은 비정상적인 트래픽 급증을 더 일찍 알아챘다면 연쇄 장애를 막을 수 있었다고 봤다. 상태 페이지 갱신이 늦어 고객에게 오래되거나 불완전한 정보가 갔다.

   사례 보기

원인별8