Чому 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 з правами лише на потрібну зону, а не на весь акаунт.
- Перелік сервісів і точок входу, яким потрібні записи: лише зовнішні чи ще внутрішні.
- Режим синхронізації: запис на кожен об'єкт або лише на позначені, і що робити з уже наявними записами.
- Кількість середовищ і те, як розділені зони між ними.
- Вікно змін і правило відкату: що відбувається із записом під час видалення сервісу.
Далі порядок простий: коротка розмова за ввідними, інвентаризація зон і доступів, пілот на тестовому домені, розкатка за середовищами й передача регламенту експлуатації.
Пілот займає кілька днів — на ньому перевіряємо створення, оновлення й видалення записів і окремо поведінку під час відкату. Повна розкатка за середовищами — зазвичай один-два тижні з урахуванням вікна змін.
За підсумком у вас залишається відтворювана схема й зрозумілий порядок дій, якщо знадобиться повернути ручне керування.
