🛠 Ingress-NGINX уходит
В ноябре 2025 года Kubernetes официально объявил об отставке Ingress-NGINX. Март 2026 года — финальная дата. Если вы до сих пор не думали о миграции, самое время начать. И дело не только в том, чтобы переписать манифесты.
Ingress-NGINX — один из самых распространённых ingress-контроллеров в экосистеме Kubernetes. За годы использования в нём накопилось немало неочевидных особенностей поведения. Именно они создают реальную угрозу при переходе на Gateway API.
Важно понять одну вещь: Ingress-NGINX и NGINX Ingress — это два разных проекта. Ingress-NGINX поддерживает сообщество Kubernetes, и он уходит. NGINX Ingress от F5 продолжает существовать. Оба используют NGINX как dataplane, но в остальном они не связаны между собой.
Основной риск миграции — не синтаксис, а семантика. Казалось бы корректный перевод Ingress-манифестов в HTTPRoute может изменить фактическое поведение маршрутизации.
Готовим для вас цикл постов по подводным камням при миграции.
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#арсенал_инженера
В ноябре 2025 года Kubernetes официально объявил об отставке Ingress-NGINX. Март 2026 года — финальная дата. Если вы до сих пор не думали о миграции, самое время начать. И дело не только в том, чтобы переписать манифесты.
Ingress-NGINX — один из самых распространённых ingress-контроллеров в экосистеме Kubernetes. За годы использования в нём накопилось немало неочевидных особенностей поведения. Именно они создают реальную угрозу при переходе на Gateway API.
Важно понять одну вещь: Ingress-NGINX и NGINX Ingress — это два разных проекта. Ingress-NGINX поддерживает сообщество Kubernetes, и он уходит. NGINX Ingress от F5 продолжает существовать. Оба используют NGINX как dataplane, но в остальном они не связаны между собой.
Основной риск миграции — не синтаксис, а семантика. Казалось бы корректный перевод Ingress-манифестов в HTTPRoute может изменить фактическое поведение маршрутизации.
Готовим для вас цикл постов по подводным камням при миграции.
📍 Навигация: Вакансии • Задачи • Собесы
#арсенал_инженера
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7
This media is not supported in your browser
VIEW IN TELEGRAM
📅 Старт курса — 20 апреля.
Если хотите разобраться, как строить управляемые агентные системы:
P.S.
Please open Telegram to view this post
VIEW IN TELEGRAM
🧑💻 Безопасный способ вывести ноду из строя
Надо обновить ноду, поменять железо или просто перезагрузить сервер. Проблема в том, что на ноде уже крутятся поды с реальной работой. Просто выключить её нельзя. Вот тут на помощь приходит kubectl drain.
Команда:
Kubernetes корректно выведет все поды с ноды, перенесёт их на другие ноды в кластере и отметит саму ноду как недоступную для новых подов. Workloads при этом не упадут, они просто переедут.
Drain работает только с управляемыми подами. Если у вас валяются standalone поды без контроллера, они просто удалятся. Поэтому перед drain проверьте, что важные поды находятся в Deployments, StatefulSets или других контроллерах.
После drain нода остаётся в состоянии unschedulable. Когда закончите работу, верните её обратно:
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#root_prompt
Надо обновить ноду, поменять железо или просто перезагрузить сервер. Проблема в том, что на ноде уже крутятся поды с реальной работой. Просто выключить её нельзя. Вот тут на помощь приходит kubectl drain.
Команда:
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data
Kubernetes корректно выведет все поды с ноды, перенесёт их на другие ноды в кластере и отметит саму ноду как недоступную для новых подов. Workloads при этом не упадут, они просто переедут.
--ignore-daemonsets говорит системе не трогать DaemonSets, потому что они крутятся на каждой ноде и переносить их бесполезно. --delete-emptydir-data удаляет поды с пустыми томами, которые нельзя перенести нормально.Drain работает только с управляемыми подами. Если у вас валяются standalone поды без контроллера, они просто удалятся. Поэтому перед drain проверьте, что важные поды находятся в Deployments, StatefulSets или других контроллерах.
После drain нода остаётся в состоянии unschedulable. Когда закончите работу, верните её обратно:
kubectl uncordon <node-name>
📍 Навигация: Вакансии • Задачи • Собесы
#root_prompt
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1👍1
Разбираем особенности Ingress-NGINX перед его отставкой. Одна из самых частых причин тихих сбоев при миграции — это поведение регулярных выражений в путях маршрутизации.
Предположим, нужно направлять на бэкенд только запросы, путь которых состоит ровно из трёх заглавных букв. Пишете паттерн
/[A-Z]{3}, включаете аннотацию nginx.ingress.kubernetes.io/use-regex: "true" и считаете задачу решённой.На деле Ingress-NGINX обрабатывает такой паттерн как _префикс без учёта регистра_. Запрос
/uuid пройдёт — потому что три буквы в начале пути есть. /some-long-path тоже пройдёт. Именно это поведение было в продакшене, даже если вы об этом не знали.При переходе на Gateway API с типом матчинга
RegularExpression всё меняется. Реализации на базе Envoy — Istio, Envoy Gateway, Kgateway — делают полное совпадение с учётом регистра. Паттерн /[A-Z]{3} уже не пропустит /uuid. Запросы, которые раньше работали, начнут возвращать 404.Чтобы сохранить прежнее поведение, паттерн нужно переписать явно:
/[a-zA-Z]{3}.*. Либо использовать флаг (?i), если конкретная реализация его поддерживает.Перед миграцией пройдитесь по каждому регулярному выражению и проверьте, какие запросы оно реально пропускало. Не то, что написано в паттерне, а то, что фактически проходило в продакшене.
📍 Навигация: Вакансии • Задачи • Собесы
#арсенал_инженера
Please open Telegram to view this post
VIEW IN TELEGRAM