Налаштування Service Discovery у Kubernetes: CoreDNS і Headless Services

Service Discovery в Kubernetes: де рветься зв'язність

Поди запущені, readiness-проби зелені, але сервіс не збирається: один учасник отримує помилку розв'язання імені, інший стукає на адресу, якої вже немає. Service Discovery в Kubernetes ламається не повністю, а частково — частина викликів проходить, частина висить до таймауту.

Перший клас збоїв — відмова шару імен. CoreDNS не відповідає, коли впирається в ліміти ресурсів, втрачає зв'язок з API-сервером або залишається в єдиному екземплярі після витіснення подів.

У логах застосунку це виглядає як сплеск помилок розв'язання імен, хоча сам сервіс живий і відповідає за прямою адресою.

Другий клас — застарілі адреси подів. Клієнт тримає відповідь у кеші на час TTL, под за цей час перестворився й отримав нову адресу: трафік іде в нікуди, а з'єднання висить до таймауту.

У headless-сервісів те саме помітніше — балансування клієнт робить сам за списком точок, який встиг застаріти.

Третій клас — розбіжність у конфігурації: селектор не збігся з мітками подів, порт у сервісі та в контейнері розійшовся, перевірка готовності пропускає ще не піднятий застосунок. Endpoints у такому разі порожні не через мережу, а тому що сервіс нікого не вибрав.

Ціна в усіх трьох одна: неповні відмови, які не ловляться алертами за інфраструктурою, зате видно в частці помилок у користувача. Нижче розбираємо, як це закривається.

Що дає налаштування: швидкість випуску та усунені відмови

Поки адреси сервісів живуть у конфігураціях застосунків і змінних середовища, будь-яке перестворення подів перетворюється на ручне звіряння: адреси змінилися, клієнти тримають застарілі значення й продовжують ходити в нікуди.

Кероване виявлення прибирає сам привід для цієї роботи — застосунок звертається до сервісу за іменем, а не за конкретною адресою.

Що відбувається на рівні інфраструктури: CoreDNS віддає стабільні імена для звичайних сервісів, а headless-режим дає фіксовану точку входу з прямим переліком адрес для наборів, де кожен екземпляр адресується окремо.

Під час заміни подів змінюється лише вміст записів — імена й точки підключення залишаються тими самими, тому конфігурації застосунків і балансувальників більше не переписуються під кожен випуск.

Ключовий ефект видно у двох метриках. Час випуску релізу скорочується з годин до десятків хвилин, бо з процесу йде етап «оновити адреси й перевірити, що нічого не забули» — він виконувався вручну й був найчастішим джерелом затримок.

Частка правок конфігурацій, внесених руками, падає майже до нуля: залишаються тільки осмислені зміни, а не реакція на зміну адрес.

Окремо йде цілий клас відмов. Раніше після планового перестворення подів застосунок віддавав помилки з'єднання або відповідав частково — частина екземплярів уже піднялася, а клієнти ще тримали старі адреси.

Тепер застарілий запис спливає за часом життя, і трафік перемикається на живі екземпляри. Це прямо впливає на доступність: перестворення подів стає рутинною операцією, а не подією з ризиком деградації.

Режими виявлення: DNS-записи, headless-режим, зовнішні реєстри

Виявлення всередині кластера вирішує одне завдання — дати сервісу знайти сусіда, не вшиваючи його адресу в конфігурацію. Способів кілька, і вони не взаємозамінні: звичайний dns-запис, headless-режим із прямим списком адрес і зовнішній реєстр для сервісів за межами кластера. Вибір залежить від того, хто тримає балансування — платформа чи клієнт.

У headless-режимі CoreDNS віддає за dns-запитом повний список адрес, і балансуванням займається клієнт. Це усвідомлений обмін: платформа перестає бути посередником і точкою відмови, але клієнт має вміти повторити запит за зміни складу.

Тому на headless ми переводимо лише ті сервіси, де потрібен прямий доступ до конкретного екземпляра, а статичні адреси залишаємо для аварійних сценаріїв.

Етапи робіт: аудит, схема, налаштування, перевірка, передача

Роботи йдуть від розбору поточної топології до передачі регламентів команді замовника, без зупинки бойового контуру. Порядок вибудуваний так, що кожен етап дає перевірюваний результат і слугує входом для наступного.

1. Аудит кластера — збираємо карту сервісів і неймспейсів, дивимося, як зараз розв'язуються імена, де залишилися ручні записи й які мережеві політики ріжуть DNS-трафік. Окремо фіксуємо точки відмови: одна репліка CoreDNS, відсутність кешу, жорсткі таймаути в клієнтах.
2. Схема виявлення — вирішуємо, де достатньо звичайного сервісу, а де потрібен headless для прямого доступу до подів. Визначаємо зони, правила пересилання й те, що йде в зовнішній DNS.
3. Налаштування CoreDNS — правимо конфігурацію під цю схему: зони, пересилання, кеш, ліміти, проби готовності. Репліки розносяться по вузлах і зонах доступності, щоб відмова одного не валила розв'язання імен.
4. Перевірка відмовостійкості — гасимо репліку й вузол із нею, дивимося, чи зберігається резолв і як клієнти переживають затримку відповіді. Окремо проганяємо headless-сервіси й оновлення списку ендпоінтів.
5. Спостережуваність — виводимо метрики запитів, відмов і часу відповіді, задаємо пороги для чергового, щоб деградація була видна раніше за скарги.
6. Передача в експлуатацію — схема, регламенти й порядок типових операцій: як підключити новий сервіс, як відкотити зміну, що перевіряти першим у разі збою.

Комплект постачання: конфігурації, схеми, регламенти

Результат проєкту — не лише робочий кластер, а й набір артефактів, за якими ваша команда веде його далі сама. Усе складається у ваш репозиторій і передається з поясненнями: що за що відповідає, де змінюється й як відкочується. Нижче — що саме залишається у замовника після здачі.

• Робочі конфігурації: маніфести й ConfigMap для CoreDNS, headless-сервісів і пов'язаних об'єктів — у вашій системі контролю версій, з історією змін.
• Схема топології виявлення: як сервіси знаходять одне одного, які записи створюються під StatefulSet, як розв'язуються імена всередині кластера й зовні.
• Політики доступу: RBAC-ролі, NetworkPolicy та обмеження на правку зони — хто й з яких просторів імен може читати й змінювати записи.
• Діаграма відмовостійкості: число реплік, розподіл по вузлах, поведінка в разі втрати вузла або зони.
• Регламент експлуатації: типові операції — підключення сервісу, зміна зони, ротація сертифікатів — з точками перевірки й порядком відкату.
• Набір перевірок: метрики й скрипти контролю розв'язання імен, затримки відповідей і частки помилок, з порогами для чергового.
• Документація: опис схеми, ухвалених рішень і відомих обмежень — щоб новий інженер входив у контур без усних пояснень.

Кейс: як прибрали ручні правки адрес після релізу

Що було Платформа з кількох десятків сервісів на Kubernetes тримала зв'язність на адресах, прописаних руками.

Перед кожним релізом інженер збирав актуальний список подів і переносив адреси в конфігурації залежних сервісів — 25-40 хвилин на синхронізацію й постійний ризик, що частина списку застаріє між правкою й викаткою.

Дорожче обходилося позапланове перестворення подів: на нових вузлах адреси змінювалися, а клієнти продовжували звертатися за старими записами. Сервіс віддавав помилки 5-8 хвилин, поки черговий не знаходив застарілу адресу.

За квартал таких розборів набралося одинадцять, кожен — із частковою недоступністю для користувачів.

Що змінили Причина була не в числі сервісів, а в статичних адресах як способі зв'язку. Ввели CoreDNS штатним сервером імен кластера й headless Services для сервісів із кількома екземплярами: служба віддає список адрес усіх живих подів, а клієнт вибирає доступний.

Звернення між сервісами перевели на імена, для довготривалих з'єднань налаштували періодичне перечитування списку — інакше клієнт тримав би стару адресу до власного перезапуску.

Що стало Синхронізація адрес зникла як окремий етап: час на правки під час релізу — нуль, зміни підхоплюються разом зі станом кластера.

Зв'язність після аварійного перестворення подів відновлюється за 10-20 секунд замість 5-8 хвилин простою, а інцидентів через застарілі адреси за зіставний період не було жодного. Виміри знімали за журналами відмов і часом реакції чергового.

Що робити, якщо в Kubernetes уже розгорнуто CoreDNS?

Розгорнутий CoreDNS — не привід перебудовувати кластер: це робочий компонент, який змінюють на місці, без зупинки сервісів. Головне правило — не чіпати ім'я сервісу kube-dns і його адресу всередині кластера.

Маніфести застосунків звертаються саме до нього, тому схему виявлення можна змінювати під капотом, поки зовнішній контракт резолвінгу залишається попереднім.

Порядок змін будується від читання до запису. Спершу знімаємо поточну конфігурацію Corefile і фіксуємо, які зони, плагіни й вищі резолвери в ній задіяні, — це точка відкату.

Потім правимо копію в ConfigMap, не застосовуючи її до робочого контуру, і перевіряємо з тестового простору імен: резолв внутрішніх і зовнішніх імен, поведінку search-доменів і параметра ndots.

Окремий крок — headless-сервіси. Переведення звичайного сервісу в headless змінює лише запис у маніфесті: замість однієї адреси клієнт отримує набір адрес подів, а ім'я залишається тим самим.

Застосунки, які ходять за іменем сервісу, продовжують працювати без правок, якщо зберігаються попередні search-домени й порядок резолвінгу.

Оновлення робимо через послідовну заміну подів: мінімум дві репліки, перевірка готовності перед виведенням наступного, перезавантаження конфігурації без перезапуску. На будь-якому кроці частина подів відповідає за старою схемою, частина — за новою, і запити не губляться.

Після перемикання звіряємо частку відповідей з кешу, число відмов SERVFAIL і повноту списків адрес у headless-сервісів. Відкат — повернення попередньої конфігурації й перезавантаження, за часом він зіставний із прямою зміною.

Технічні сумніви: кеш, таймаути, обмеження режимів

Кешування записів — перше питання, яке спливає, коли сервіс після переїзду поду продовжує звертатися за старою адресою. У запису є строк життя, і клієнт тримає його до спливу таймауту — це не збій кластера, а очікувана поведінка.

Друге заперечення — таймаути при недоступності вузла: допомагають перевірки готовності, рознесення реплік по зонах і бюджет переривань. Вузол виводиться з роботи лише після того, як його перестали опитувати.

Що буде, якщо вузол із DNS-репліками випаде?

Нічого катастрофічного: репліки CoreDNS рознесені по вузлах і зонах, клієнт перепитує наступну адресу зі списку. Частина запитів губиться лише на час перемикання — інтервал закриваємо алертами й перевірками.

Headless віддає список адрес без балансування — у чому обмеження?

Віртуальної адреси й розподілу трафіку тут немає: клієнт отримує адреси подів напряму. Кластерам баз даних це й потрібно, а звичайному застосунку балансування доведеться робити на боці клієнта.

Обговоримо ваше завдання: з чого почнемо

Щоб оцінка була предметною, а не «на око», почнемо з опису вашої топології: скільки кластерів і середовищ, як розбиті простори імен, хто й за якими іменами звертається до сервісів, що вже пробували й які симптоми залишилися. Формат не важливий — текст, схема або вивід діагностичних команд.

У відповідь повернемо не загальні міркування, а розбір: де саме рветься розв'язання імен, які зміни потрібні й у якому порядку їх викочувати. Нижче — що уточнимо насамперед і що увійде в план робіт.

• Межі завдання: розв'язання імен лише всередині кластера чи ще доступ із зовнішніх мереж і сусідніх кластерів.
• Питання щодо топології: число середовищ, розбиття на простори імен, власні сервери імен і зони під вашим контролем.
• Поточний стан: служби без балансувальника, режим локального звернення до вузла, записи, які правляться вручну.
• Що вже перевіряли: час відповіді на запит імені, частка відмов, поведінка під час перезапуску вузлів і зміни налаштувань.
• Оцінка робіт: перелік правок у конфігурації, обсяг змін, трудовитрати й порядок викату за середовищами.
• План впровадження: етапи, точки відкату й перевірки того, що старі імена продовжують працювати після переходу.
• Експлуатація після запуску: правила іменування, спостереження й оповіщення, документація та передача вашій команді.

Опишіть завдання у вільній формі — повернемося з оцінкою й планом впровадження. Якщо зручніше голосом, зателефонуємо з інженером і розберемо вашу схему разом.