🧑💻 Безопасный способ вывести ноду из строя
Надо обновить ноду, поменять железо или просто перезагрузить сервер. Проблема в том, что на ноде уже крутятся поды с реальной работой. Просто выключить её нельзя. Вот тут на помощь приходит 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
👍2❤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
Terraform-собеседование — и вот вам вопрос:
Команда хранит state в S3 и периодически ловит его порчу при одновременных apply. Как исключить race condition?
Подсказка: одного только версионирования S3 недостаточно. Нужен механизм, который не дает двум apply работать одновременно.
📍 Навигация: Вакансии • Задачи • Собесы
#задача_со_звёздочкой
Please open Telegram to view this post
VIEW IN TELEGRAM