Почему External DNS Kubernetes отстаёт от изменений в кластере
Пересоздали сервис — поды поднялись, проверки проходят, а трафик не идёт. Запись в зоне всё ещё указывает на прежний адрес балансировщика, которого уже нет: клиент получает таймаут, хотя со стороны кластера всё зелёное. И пока не истечёт время жизни записи, кеширующие серверы продолжают отдавать старый адрес — сбой держится дольше, чем длится сам релиз.
Причина в разрыве между жизненным циклом объектов кластера и содержимым зоны. Сервис живёт минуты, запись — до первой ручной правки, поэтому расхождение записей и сервисов копится с каждой выкаткой. Устаревшие записи после пересоздания сами не удаляются: остаётся мусор, который резолвится и уводит часть запросов в никуда, а часть — на прошлый контур. Диагностика при этом усложняется: снаружи домен отвечает, внутри кластера всё работает, а между ними — несовпадение.
Дальше начинаются ручные правки зон. Дежурный сверяет список сервисов с содержимым зоны, вычищает лишнее, дописывает новое — ночью и под давлением, по инструкции, которую никто не проверял на полноту. Обратной сверки нет: никто не подтверждает, что в зоне не осталось указателей на несуществующие адреса. Автоматическое управление DNS снимает именно эту работу — External DNS связывает объекты кластера с зоной напрямую; разбираем, как это устроено и что даёт.
Что меняется в эксплуатации: измеримые эффекты автоматизации
External DNS-контроллер подключается к кластеру и работает как цикл сверки: он читает сервисы и точки входа с пометкой о внешнем имени и приводит записи в зоне к этому состоянию. Источник правды остаётся один — манифест, а не панель регистратора, поэтому изменения не нужно дублировать руками. Дальше эффект раскладывается на четыре измеримых направления.
Скорость появления записей перестаёт зависеть от человека: имя публикуется в течение десятков секунд после применения манифеста, а не в следующем окне ручных правок, и сокращённое время жизни записи позволяет быстро снять устаревший ответ из кэша резолверов. Доля ручных операций в зоне падает до единичных случаев — обычно это делегирование домена и записи для ресурсов вне кластера, которые сознательно выводят из-под автоматики.
Основной выигрыш — устранённый класс отказов из-за человеческой ошибки: опечатка в имени, забытая запись после удаления окружения, конфликт двух владельцев за одно имя, расхождение между тем, что реально работает в кластере, и тем, что опубликовано в зоне. Такие расхождения почти не видны в мониторинге приложения — они всплывают как «сервис жив, но недоступен снаружи», и поиск уходит в сторону от реальной причины.
Время восстановления сервиса сокращается: при пересоздании или переезде нагрузка получает новую точку входа, и запись обновляется без дежурного с доступом к панели регистратора. Обратная операция тоже автоматизирована — удаление окружения освобождает имена, и в зоне не накапливаются мёртвые указатели, которые потом приходится вычищать вручную.
Варианты синхронизации DNS: от ручных правок до полного автомата
Синхронизировать зону с кластером можно четырьмя способами, и выбор между ними — это выбор между скоростью реакции на изменения и предсказуемостью содержимого зоны. External DNS читает описания объектов кластера и создаёт или обновляет записи, но режимы его работы и политики определяют, что он имеет право менять и удалять.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Ведение зон вручную | Стабильный набор сервисов, редкие релизы | Правки отстают от выката, ошибки в записях ловятся уже в проде, всё держится на одном человеке |
| Задания по расписанию | Много сервисов, смена адресов раз в сутки | Запись появляется с задержкой, параллельные запуски конфликтуют, нет сверки с фактическим состоянием |
| Автоматика по описанию сервисов | Динамические окружения, частое масштабирование | Нужны права на запись в зону, требуется явная политика удаления и метки на объектах |
| Гибридная схема управления | Критические записи должны остаться у инженера | Сложнее правила разграничения, нужен список зон и записей, которых автоматика не касается |
На практике чаще приходят к гибридной схеме: сервисы разработки управляются автоматически, а корневые и почтовые записи остаются за инженером, потому что ошибка в них роняет сразу всё. Границы фиксируются явным перечнем зон, которые автоматика не трогает, — тогда выкат нового сервиса не требует участия человека, а зона остаётся в предсказуемом состоянии.
Этапы внедрения в кластер Kubernetes: от аудита до передачи
Порядок работ выстраиваем так, чтобы автоматизация DNS получила ровно те права, что нужны для публикации записей, и не могла задеть зоны, живущие вне кластера. Каждый этап заканчивается артефактом, который проверяется до перехода к следующему.
- Аудит зон и прав. Собираем зоны, которые обслуживает кластер, смотрим, какие записи там созданы вручную и кто за них отвечает. Для облачного провайдера заводим отдельную учётную запись с ограниченной ролью: запись разрешена только в выделенные зоны, остальное — чтение.
- Схема соответствия сервисов и записей. Фиксируем, какое имя получает каждый сервис — по аннотации, по метке или по шаблону владельца команды. Здесь же разводим конфликты с уже существующими записями и договариваемся, кто владеет удалением.
- Настройка. Определяем источники имён, фильтр по домену, режим синхронизации и интервал сверки. Добавляем служебную запись-маркер: по ней контроллер понимает, что запись создана им, и не перезаписывает чужую.
- Проверка на стенде. На копии зоны прогоняем сценарии: публикация нового сервиса, переименование, удаление, конфликт имён, недоступность провайдера. Отдельно смотрим, что происходит с записями при откате релиза.
- Передача в эксплуатацию. Отдаём регламент, доступы, метрики и порядок действий при расхождении — что чинится автоматически, а где нужен человек.
Конфигурации, схемы и регламенты в комплекте передачи
Комплект передачи — не архив с манифестами, а набор артефактов, по которым ваша команда сама добавляет зоны, отзывает доступы и разбирает сбои без обращения к нам. Всё складываем в ваш репозиторий с историей изменений и прогоняем сценарии на стенде вместе с дежурной сменой.
- Рабочие конфигурации — манифесты контроллера External DNS с фактическими значениями: источники записей, фильтры по зонам и доменам, интервал синхронизации, режим правки записей.
- Карта зон — что делегировано, где размещён авторитетный DNS, какие записи управляются автоматически, какие заведены руками и трогать их нельзя, где проходят границы ответственности.
- Политики владения записями — контроллер правит только своими записями: метка владельца, отдельный реестр, разделение зон между командами.
- Политики доступа — сервисная учётная запись под контроллер, права только на нужные зоны, чтение и запись разделены, ключи в секретах с регламентом ротации.
- Регламент реагирования — что проверять при рассинхроне, пропаже обновлений и отказе доступа к провайдеру; как вернуться к предыдущему состоянию и к кому эскалировать.
- Инструкции для дежурных — как посмотреть план изменений без применения, убедиться, что запись управляется автоматически, и что смотреть в журналах при конфликте.
- Подключение новой зоны — порядок шагов: делегирование, доступы, фильтры, тестовый прогон, включение правок в рабочем контуре.
- Наблюдаемость — метрики контроллера, оповещения об ошибках авторизации и задержке синхронизации, панель для дежурной смены.
Документацию пишем под ваш контур, а не под типовой стенд: имена зон, учётных записей и пороги оповещений в ней уже ваши, поэтому передача не превращается в повторное проектирование.
Кейс: от ручных правок записей к автоматической синхронизации
Продуктовая команда держала 40+ сервисов в кластере, а зоны в панели регистратора вела вручную: записи A, CNAME и TXT заводились тикетами и правились дежурным инженером. Вывод сервиса, смена балансировщика или переезд узла превращались в цепочку согласований — правка доезжала до боевой зоны за 30-40 минут. За квартал набралось 11 инцидентов с записями: забытая запись при выводе сервиса, указатель на снятый узел, дубли после ручного слияния зон. Суммарный простой из-за неверной маршрутизации — около 9 часов.
Внедрили External DNS: источником истины стали аннотации сервисов и объектов Ingress, а доступ к API регистратора выдали отдельному сервисному аккаунту с правами только на нужные зоны. На тестовом контуре сначала включили режим предпросмотра — сервис показывал план изменений и не применял его; сверка с фактическими записями вскрыла 14 расхождений, оставшихся от ручного периода, и их вычистили до включения на боевых зонах. Зоны разработки, предпродакшена и боевого контура развели по отдельным именам, TTL держим коротким.
Теперь маршрут меняется вместе с выкатом: инженер правит манифест, запись обновляется в том же цикле, окно — минуты. Откат — возврат предыдущего манифеста, а не ручной поиск старого адреса. За следующий квартал число инцидентов с записями упало с 11 до 1, и тот пришёл со стороны регистратора, а не из наших зон. Простои из-за неверной маршрутизации сократились с 9 часов до получаса, а указатели на выведенные узлы исчезают вместе с объектами — реестр зон перестал расти.
Что делать, если кластер уже развёрнут и записи ведутся вручную?
Кластер уже работает, а записи в зонах создавались вручную — переход на автоматику при этом не требует окна обслуживания. Начинаем с инвентаризации: выгружаем записи, сопоставляем их с объектами кластера, отмечаем, что создано руками, что балансировщиком, какие TTL и кто владелец домена. Без этой карты первый же прогон синхронизации снесёт то, что годами настраивали вручную.
Дальше External DNS включается в режиме наблюдения: права на зону выдаём только на чтение, решения сверяем с фактическим состоянием без изменений. Ключевое — метка владения: управляемая запись получает служебную TXT-запись с идентификатором владельца, и сервис считает своими только те, где метка совпала. Чужие записи остаются нетронутыми: политика upsert-only (обновление и добавление без удаления) запрещает стирание, а фильтр по доменам ограничивает ответственность уже проверенными поддоменами.
Переход идёт поэтапно — сначала непродуктивный контур, затем по одной зоне продуктив с паузой на сверку. Перед переключением TTL ключевых записей снижается заранее, поэтому откат возвращает трафик за минуты. Откат вообще дешёвый: синхронизация выключается, записи в зоне остаются рабочими, потому что ни одну из них мы не удаляли.
В итоге сервисы не простаивают, существующие записи сохраняются, а ручное редактирование зоны становится исключением — только для того, что кластером не управляется.
Технические сомнения: ограничения, отказоустойчивость, права
ExternalDNS нередко воспринимают как способ раздать командам доступ к управлению DNS-зоной. На деле контроллер видит только разрешённые ему объекты кластера и правит зону в границах выданного доменного фильтра — всё остальное вне его ответственности.
Ниже — сомнения, которые чаще всего звучат на приёмке: поведение при сбоях у провайдера, защита от удаления чужих записей, разделение прав между командами и границы самого подхода.
Что будет, если DNS-провайдер недоступен или отвечает ошибками?
Контроллер повторяет запросы с нарастающей паузой и не трогает записи, которые не смог подтвердить: в зоне остаётся последнее успешно применённое состояние, и сервисы продолжают резолвиться по нему. Алерты ставим на длительность серии ошибок и на расхождение между кластером и зоной — сбой видно до следующего релиза, а не после жалоб пользователей.
Как контроллер понимает, какие записи его, и не удалит ли лишнее?
Каждую созданную запись сопровождает служебная TXT-запись с идентификатором владельца. Меняется и удаляется только помеченное этим идентификатором, поэтому записи, заведённые вручную, остаются нетронутыми. Режим upsert-only запрещает удаление вовсе, а доменный фильтр ограничивает работу конкретными зонами.
Как разграничить права между командами?
Разделяем источники: одна команда публикует сервисы только в своём пространстве имён, другая — в своей подзоне. Права на объекты кластера выдаются ролями, права на зону — отдельной учётной записью провайдера с доступом к одной зоне. Ошибка в манифесте не выводит команду за периметр.
Какие ограничения у подхода?
Автоматизация покрывает записи, выводимые из объектов кластера. Статические записи, почтовые маршруты и географическая балансировка остаются за администратором DNS: если таких записей много, автоматизируем только сервисную часть зоны.
Что подготовить к обсуждению и как начнём работу
Оценка автоматического управления DNS-записями укладывается в один разговор, если на входе есть инвентарь зон и понятные границы доступов. Ниже — вводные, которые снимают большую часть неопределённости: часть закрывается прямо в переписке, остальное — доступом к тестовой среде.
- Список доменов и поддоменов, которые должны управляться из кластера, и где заканчивается ручное управление.
- Владелец зоны и токен доступа к DNS с правами только на нужную зону, а не на весь аккаунт.
- Перечень сервисов и точек входа, которым нужны записи: только внешние или ещё внутренние.
- Режим синхронизации: запись на каждый объект или только на помеченные, и что делать с уже существующими записями.
- Количество сред и то, как разделены зоны между ними.
- Окно изменений и правило отката: что происходит с записью при удалении сервиса.
Дальше порядок простой: короткий разговор по вводным, инвентаризация зон и доступов, пилот на тестовом домене, раскатка по средам и передача регламента эксплуатации. Пилот занимает несколько дней — на нём проверяем создание, обновление и удаление записей и отдельно поведение при откате. Полная раскатка по средам — обычно одна-две недели с учётом окна изменений. По итогу у вас остаётся воспроизводимая схема и понятный порядок действий, если понадобится вернуть ручное управление.
