George Sims в материале, опубликованном в блоге CNCF 3 сентября 2026 года, рассказывает об опыте переноса основного сервиса аутентификации в кластере Kubernetes из пространства имён default в выделенное пространство имён без остановки сервиса. Сервис, который автор назвал auth-svc, постоянно использовался десятками сервисов и отвечал за аутентификацию пользователей в целой области кластера; поэтому его остановка не позволила бы выполнять вход в эту область.
Проблема заключалась не просто в переносе объекта Deployment в другое пространство. Потребители внутри кластера обращались к сервису по имени auth-svc.default.svc.cluster.local, тогда как пользователи за пределами кластера обращались к нему через отдельный Ingress. Кроме того, потребляющие сервисы принадлежали разным командам и работали по разным графикам выпуска, поэтому одновременное изменение всех ссылок было непрактичным.
Почему недостаточно перенести сервис и обновить ссылки?
Автор отмечает, что конвейер развёртывания поддерживал развёртывание сервиса только в одном пространстве имён и не был рассчитан на одновременную работу двух экземпляров. Изменение логики общего конвейера повлияло бы на другие команды, чего команда хотела избежать. Кроме того, существовала политика на основе OPA, запрещавшая одновременное наличие идентичных правил Ingress в двух пространствах имён, чтобы предотвратить неоднозначную маршрутизацию, возникающую из-за незавершённого переноса.
Поэтому решение строилось не на принуждении каждого потребителя узнать новый адрес, а на временном сохранении работоспособности старого адреса и перенаправлении его на перенесённый сервис.
ExternalName как адрес перенаправления
После развёртывания фактической версии сервиса в новом пространстве имён authentication старый объект Service в default был преобразован в сервис типа ExternalName. Его имя стало указывать на auth-svc.authentication.svc.cluster.local, благодаря чему сервисы, использующие старый адрес, продолжили обращаться к новой версии без немедленного изменения кода или повторного развёртывания.
Автор сравнивает этот механизм с сервисом переадресации почты: нет необходимости связываться с каждым владельцем старого адреса, поскольку запросы перенаправляются на новое место, пока потребляющие стороны постепенно обновляют свои адреса. Однако этот подход зависит от того, что потребители используют имя DNS; если некоторые системы подключаются по фиксированному IP-адресу или обходят DNS, ситуация будет иной и потребует другого способа переноса.
Перед остановкой старой версии команда отслеживала метрики, чтобы убедиться, что запросы, поступающие на старый адрес, действительно достигают нового Deployment и не завершаются ошибкой или не попадают в цикл перенаправления. После проверки количество старых экземпляров было уменьшено до нуля, а не выполнено их немедленное удаление. Это обеспечило быстрый путь отката: при возникновении проблемы старые экземпляры можно было снова запустить, отложив окончательное удаление на более поздний срок.
Обработка конфликта Ingress
Для внешнего доступа требовался Ingress в новом пространстве имён до удаления старого Ingress. Однако политика OPA запрещала одновременное создание двух идентичных правил. Поэтому команда использовала временное и ограниченное исключение вместо полного отключения политики: для пространства authentication была добавлена метка, разрешающая обойти проверку дублирования Ingress во время переноса, с использованием ключа policy.example.com/allow-duplicate-ingress: "true".
В течение короткого окна перекрытия новый Ingress работал одновременно со старым, после чего была проверена доставка трафика к новому Deployment. Затем старый Ingress удалили, а временному исключению позволили прекратить действовать, не превращая его в постоянную настройку.
Что меняется на практике?
Этот опыт показывает, что перенос чувствительного сервиса не обязательно требует одновременной координации со всеми потребителями, если существует чёткая граница, основанная на DNS. Но это не отменяет необходимости поэтапного тестирования, тщательного мониторинга и плана отката. Сначала команда выполнила операцию в среде разработки, затем в тестовой среде и выждала две недели после успешного завершения тестового этапа, прежде чем провести её в производственной среде.
Более широкий вывод заключается в том, что накопление сервисов в пространстве имён default может оставаться незаметным до тех пор, пока сервису не потребуются политики или ресурсы, ограниченные выделенным пространством имён. Тогда эксплуатационный долг становится реальной проблемой. ExternalName предоставляет практический путь для сервисов, зависящих от DNS, но не является универсальным решением для систем, использующих фиксированные адреса; кроме того, окно перекрытия и исключение безопасности должны быть намеренными и временными, а также сопровождаться понятными измерениями.