IL-0081 Cresta · 2025-03-05 (게시일)kubernetesnetworking
Cresta 는 클러스터로 들어오는 트래픽을 NGINX Ingress 컨트롤러로 받는다. NGINX 는 설정 변경을 두 가지 방식으로 반영한다. 큰 변경은 전체 리로드로 처리하는데, 마스터 프로세스가 새 설정으로 워커 프로세스를 새로 띄우고 옛 워커를 정상 종료한다. 백엔드 엔드포인트 변경 같은 것은 리로드 없이 기존 워커에 바로 반영하는 동적 설정으로 처리한다.
Cresta 는 enable-serial-reloads 옵션을 켜 두었다. 이 옵션은 설정 변경이 연달아 들어올 때 워커 프로세스가 한꺼번에 너무 많이 뜨지 않도록 전체 리로드를 한 번에 하나씩만 하게 한다. 원래 의도대로라면 엔드포인트 변경은 리로드를 기다리지 않고 바로 반영돼야 한다. 하지만 이 옵션에는 버그가 있었다. 워커가 리로드 중이면 컨트롤러가 오류를 내고 모든 처리를 멈췄다. 그래서 진행 중인 리로드가 끝날 때까지 엔드포인트 변경이 반영되지 않았다.
오래 걸리는 리로드가 도는 동안 배포 롤아웃으로 엔드포인트가 바뀌자, 라우팅이 실제 배포 상태를 따라가지 못했다. 트래픽이 이미 종료됐거나 더 이상 유효하지 않은 파드로 갈 수 있었고, 일부 API 요청이 타임아웃됐다. 엔지니어가 문제를 풀려고 Ingress 를 재시작했다. 이 일로 kubernetes/ingress-nginx 에 GitHub 이슈가 열렸다.
배포 도중 쿠버네티스로 들어오는 트래픽이 갈 곳을 잃기 시작했다. 일부 API 요청이 타임아웃됐다.
배포 중에 불필요한 지연과 서비스 끊김이 생겼다. 원인을 따라가 보니 Ingress 컨트롤러의 설정 플래그가 문제였다.
–
자원 소모를 막으려고 켠 무해해 보이는 플래그 하나가, 라우팅이 실제 배포 상태와 어긋나는 구간을 만들 수 있다. 엔드포인트 동적 갱신이 리로드에 묶이면 배포 중 트래픽이 사라진 파드로 간다.
IL-0053 Ingress NGINX Controller의 어드미션 웹훅이 인증 없이 열려 있어, 조작한 Ingress 객체로 NGINX 설정을 주입해 원격 코드를 실행하고 클러스터의 모든 Secret을 읽을 수 있었다Wiz · 2025같은 원인 · 공통 인그레스 컨트롤러
IL-0106 잘못된 IngressRoute 매니페스트가 Traefik v2 버그를 건드려 Traefik 파드가 모두 재시작된 뒤 Kubernetes 의 모든 서비스가 404 를 냈다DFDS · 2021같은 원인 · 공통 인그레스 컨트롤러
같은 원인 · 공통 인그레스 컨트롤러
IL-0011 HAProxy 인그레스 템플릿이 백엔드 파드를 IP 순으로 정렬해 일부 파드에 요청이 몰리고 인그레스 컨테이너가 OOMKilled 됐다Skyscanner · 2019같은 원인 · 공통 인그레스 컨트롤러
IL-0072 etcd 쓰기 지연으로 API 서버가 오래된 데이터를 읽어 클러스터 상태가 두 가지로 번갈아 보였고, 주 운영 클러스터 전체가 약 4시간 멈췄다Nordstrom · 2017같은 원인 · 공통 인그레스 컨트롤러
https://incidentlib-mcp.benchlet.com/mcpAPI 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.