IL-0081 Cresta · 2025-03-05 (게시일)kubernetesnetworking
Cresta 는 클러스터로 들어오는 트래픽을 NGINX Ingress 컨트롤러로 받는다. NGINX 는 설정 변경을 두 가지 방식으로 반영한다. 큰 변경은 전체 리로드로 처리하는데, 마스터 프로세스가 새 설정으로 워커 프로세스를 새로 띄우고 옛 워커를 정상 종료한다. 백엔드 엔드포인트 변경 같은 것은 리로드 없이 기존 워커에 바로 반영하는 동적 설정으로 처리한다.
Cresta 는 enable-serial-reloads 옵션을 켜 두었다. 이 옵션은 설정 변경이 연달아 들어올 때 워커 프로세스가 한꺼번에 너무 많이 뜨지 않도록 전체 리로드를 한 번에 하나씩만 하게 한다. 원래 의도대로라면 엔드포인트 변경은 리로드를 기다리지 않고 바로 반영돼야 한다. 하지만 이 옵션에는 버그가 있었다. 워커가 리로드 중이면 컨트롤러가 오류를 내고 모든 처리를 멈췄다. 그래서 진행 중인 리로드가 끝날 때까지 엔드포인트 변경이 반영되지 않았다.
오래 걸리는 리로드가 도는 동안 배포 롤아웃으로 엔드포인트가 바뀌자, 라우팅이 실제 배포 상태를 따라가지 못했다. 트래픽이 이미 종료됐거나 더 이상 유효하지 않은 파드로 갈 수 있었고, 일부 API 요청이 타임아웃됐다. 엔지니어가 문제를 풀려고 Ingress 를 재시작했다. 이 일로 kubernetes/ingress-nginx 에 GitHub 이슈가 열렸다.
배포 도중 쿠버네티스로 들어오는 트래픽이 갈 곳을 잃기 시작했다. 일부 API 요청이 타임아웃됐다.
배포 중에 불필요한 지연과 서비스 끊김이 생겼다. 원인을 따라가 보니 Ingress 컨트롤러의 설정 플래그가 문제였다.
–
자원 소모를 막으려고 켠 무해해 보이는 플래그 하나가, 라우팅이 실제 배포 상태와 어긋나는 구간을 만들 수 있다. 엔드포인트 동적 갱신이 리로드에 묶이면 배포 중 트래픽이 사라진 파드로 간다.
같은 원인 · 공통 인그레스 컨트롤러
같은 원인 · 공통 인그레스 컨트롤러
같은 원인 · 공통 인그레스 컨트롤러
같은 원인 · 공통 인그레스 컨트롤러
같은 원인 · 공통 인그레스 컨트롤러