Как reload ingress-nginx уронил прод. История про pids.max, threads-max и виртуалку, которая подросла

Вот важная новость с фронта ИИ: zvlb 2 минуты назад Как reload ingress-nginx уронил прод. max, threads-max и виртуалку, которая подросла Средний 4 мин 1 Kubernetes * DevOps * Системное администрирование * Nginx * Open source * Кейс ПредисторияСхема входящего траффика в кластер Kubernetes простая: web → Envoy Gateway → Ingress Nginx → backend. За Ingress Nginx, помимо обычного HTTP, живут долгоживущие WebSocket-соединения.

Штатная нагрузка - около 100 RPS. Ничего экзотического. В один прекрасный день всё в кластере легло.

Технические детали

Клиенты получают 503/500. В логах Envoy - флаг UF и . То есть ingress-nginx просто перестал отвечать.

Дальше - два часа разбора и довольно красивая цепочка причин, которая началась с банального reload, а закончилась на том, как ядро считает лимит потоков при старте виртуалки. Если вы хотите узнать какого черта у меня в инфраструктуре и Envoy Gateway и Ingress Nginx работают одновременно - то это хороший вопрос. Сейчас мы в статусе переезда с Ingress Nginx на Envoy Gateway и если у какого-то домена не написан HTTPRoute - трафик автоматически полетит на Ingress (с надеждой, что если у домена нет HTTPRoute, возможно, у него есть Ingress)Симптом: все легло, а error log пустойПервое, что сбивает с толку - в error.

Контроллер не ругается, но и не работает:nginx_status на 127. 1:10246 - connection refused;следом readiness-проба контроллера: status. go: "POD is not ready";pod выпадает из ротации, Envoy видит дохлый upstream, наружу - 503/UF.

Отраслевые последствия

Когда сервис лежит, а error log молчит - значит сломалось не в конфиге, а уровнем ниже. Лечилось это, кстати, тривиально - рестартом подов ingress-контроллера, и всё поднималось за минуту. Но оставлять прод в состоянии "когда-нибудь оно снова стрельнет в колено" - так себе идея.

Поэтому быстрый фикс быстрым фиксом, а мы пошли копать, почему вообще дошло до отказа. Раскручиваем: почему nginx перестал поднимать ворекерыИдём в journalctl и сразу находим виновника:journalctl --since "14:20" --until "14:45" | grep -iE "fork|thread|resource temporarily|cannot allocate" kernel: cgroup: fork rejected by pids controller in /kubepods. scopefork rejected by pids controller.

Контейнер ingress-контроллера упёрся в pids. nginx не может сделать fork/clone - то есть не может поднять воркер ("cannot be respawned . Контроллер клинит, статус-порт ложится, readiness падает.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.