사례3건

3건 중 1~3번째

1. 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 에 이슈로 올린다.

   교훈

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

   사례 보기
2. IL-0062 GKE Ingress 뒤의 파드가 SIGTERM 을 받자마자 새 연결을 받지 않고 정상 종료해서 API 에 가끔 502 오류가 났다

   Ravelin2019

   증상

   Ravelin 이 API 계층을 기존 VM 에서 GKE 의 쿠버네티스 클러스터로 옮기고 Ingress 를 설정한 뒤, 통합 테스트가 가끔 502 오류를 받기 시작했다.

   간헐적 연결 실패오래된 엔드포인트 라우팅

   촉발

   파드가 종료될 때 SIGTERM 을 받자 새 연결을 받지 않는 정상 종료를 시작했지만, GKE Ingress 는 엔드포인트 변경을 늦게 반영해 그 파드로 계속 새 트래픽을 보냈다.

   원인

   소프트웨어 결함

   구성 요소

   인그레스 컨트롤러파드 종료 처리

   기여 요인

   미검증 가정

   감지

   Ingress 를 설정한 뒤 통합 테스트가 가끔 502 오류를 받는 것을 보고 알았다.

   교훈

   쿠버네티스에서 엔드포인트 제거와 SIGTERM 은 동시에 일어나므로, SIGTERM 을 받았다고 바로 새 연결을 거부하면 안 된다. Ingress 는 특히 엔드포인트 변경을 늦게 반영한다. 파드는 종료 유예 시간이 끝날 때까지 계속 요청을 처리해야 하고, 유예 시간은 로드 밸런서에 변경이 반영되는 시간보다 길어야 한다.

   사례 보기
3. IL-0072 etcd 쓰기 지연으로 API 서버가 오래된 데이터를 읽어 클러스터 상태가 두 가지로 번갈아 보였고, 주 운영 클러스터 전체가 약 4시간 멈췄다

   Nordstrom2017

   증상

   사용자가 파드가 떴다가 사라진다고 클러스터 운영 팀에 알렸다.

   API 조회 결과 불일치오래된 엔드포인트 라우팅서비스 중단

   촉발

   etcd 의 쓰기 지연이 크게 늘었다. 발표자는 정상인 etcd 의 쓰기 지연이 한 자릿수 밀리초이고, 데이터베이스 동기화 지연이 두 자릿수나 수백 밀리초를 넘으면 문제가 시작된다고 설명했다.

   원인

   소프트웨어 결함

   구성 요소

   etcd쿠버네티스 API 서버인그레스 컨트롤러영구 볼륨과 스테이트풀셋

   기여 요인

   기본 설정 방치

   감지

   팀은 사용자가 파드가 떴다가 사라진다고 알려 와서 장애를 알게 됐다. 팀이 kubectl 로 확인하자 같은 명령이 실행할 때마다 다른 결과를 냈다.

   조치

   • 새 클러스터를 만들어 애플리케이션을 다시 배포하고 서비스를 복구했다.
   • 볼륨을 옛 클러스터에서 하나씩 손으로 풀어 새 클러스터에서 바인딩했다.
   • 로드 밸런서를 쓰던 팀들이 DNS 레코드를 새 클러스터의 로드 밸런서 이름으로 손으로 바꿨다.

   후속 조치

   • API 서버가 etcd 에서 읽을 때 항상 쿼럼 읽기를 하도록 설정한다.

   교훈

   etcd 는 쿼럼 읽기를 요청하지 않으면 오래된 데이터로 응답할 수 있고, 이 동작은 문서에 적혀 있다. 쿠버네티스 1.9 부터는 쿼럼 읽기가 기본이므로, 그 전 버전을 쓰면서 API 서버 설정을 직접 관리한다면 설정을 확인해야 한다. 쿼럼 읽기는 성능 걱정 때문에 처음에는 권장되지 않았지만, etcd 3.1 에서는 읽기가 디스크를 거치지 않아 부담이 크게 줄었다. etcd 는 쓰기 지연에 매우 민감하므로 데이터베이스 동기화 지연을 지켜봐야 한다. 고가용성 문서처럼 계속 바뀌는 문서는 꾸준히 다시 읽어야 한다. 로드 밸런서 이름을 직접 가리키는 DNS 레코드와 한 노드에 묶이는 볼륨은 클러스터 교체를 느리게 만든다.

   사례 보기

원인별1