Налаштування Kubernetes-кластера з нуля (kubeadm): production HA

kubeadm налаштування кластера: де ламається відмовостійкість

kubeadm налаштування за швидкою інструкцією виглядає майже однаково: kubeadm init на одній машині, робочі вузли підключаються через kubeadm join, kubectl get nodes показує рівний зелений список. Поди розгортаються, сервіси відповідають, кластер виглядає відмовостійким.

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

Єдиний вузол управління тримає одразу kube-apiserver, kube-scheduler, kube-controller-manager і etcd — усе в одному екземплярі.

Зникла машина або мережа, і API-сервер недоступний: kubectl та інструменти розгортання втрачають доступ, нові поди не плануються, ті, що впали, не перезапускаються, endpoints сервісів і видача сертифікатів завмирають. Кластер ще живий, але перестає реагувати на зміни.

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

Окрема пастка — кворум etcd: з одним членом втрата сховища робить кластер недоступним для змін, а відновлення зі знімка відкочує частину недавніх операцій.

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

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

Що дає відмовостійкий кластер: простій і час відновлення

Відмовостійкість починається з кворуму вузлів управління. Kubernetes тримає стан кластера в розподіленому сховищі, і записи проходять, поки живі більше половини вузлів управління.

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

На єдиному вузлі та сама аварія означає недоступний API і ручне відновлення з резервної копії — від десятків хвилин до годин і з ризиком втратити частину останніх змін.

Для робочих навантажень механіка інша, і тут працює перемикання під час відмови, а не відновлення.

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

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

Який клас відмов зникає

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

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

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

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

Топології вузлів управління: порівняння варіантів розгортання

Топологія кластера визначає, що станеться з робочими навантаженнями, коли один із вузлів управління вийде з ладу. За одного вузла управління відмова означає недоступність API: нові поди не плануються, зміни не застосовуються, а відновлення потребує ручного втручання.

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

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

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

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

Налаштування kubeadm: етапи робіт від аудиту до передачі

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

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

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

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

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

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

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

Документація, схеми й регламенти на виході проєкту

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

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

• Файли конфігурації: kubeadm-config, маніфести шару управління, параметри kubelet і контейнерного рантайму, чарти для Ingress, DNS і моніторингу — стенд розгортається в чистому середовищі відтворювано.
• Схема мережі й адресації: діапазони pod-мережі та сервісів, балансування запитів до API, з'єднання із зовнішніми мережами й маршрутизація між зонами.
• Схема відмовостійкості: кількість вузлів шару управління, кворум etcd, розміщення резервних копій стану, поведінка кластера при втраті зони.
• Політики доступу: ролі й прив'язки RBAC, сервісні облікові записи, ізоляція просторів імен, мережеві політики й правила допуску робочих навантажень.
• Регламент оновлення: черговість оновлення вузлів, перевірки перед виведенням з ладу, критерії відкату й глибина зберігання попередніх версій образів.
• Регламент відновлення й документація по кластеру: сценарії втрати вузла й сховища стану, цільовий час відновлення, карта кластера, налаштування оповіщень і журнал відомих обмежень.

Кейс: три вузли управління, відмова одного без простою

До перескладання кластер Kubernetes тримався на одному вузлі управління й двох робочих машинах, зібраних вручну: конфігурація жила в голові інженера, резервна копія etcd знімалася нерегулярно.

Збій цього вузла зупиняв API — викотити реліз або подивитися стан подів було неможливо, а відновлення зі знімка займало 40–50 хвилин: підняти вузол, повернути сертифікати, звірити адреси, дочекатися, поки kubelet знову побачить робочі машини.

Ми перезібрали контур через kubeadm: три вузли управління за балансувальником із спільною віртуальною адресою, etcd на всіх трьох — кворум тримається, поки живі два.

Встановлення описано декларативно, тому новий вузол піднімається за одним і тим самим сценарієм, без «налаштувань, які пам'ятає тільки одна людина».

Планові оновлення йдуть по одному вузлу: поди витісняються на вільні потужності, вузол виводиться з роботи, оновлюється й повертається.

Метрики до і після

• Відмова вузла управління: було — до 50 хвилин ручного відновлення й повна недоступність API; стало — перемикання на резервний вузол менше хвилини, сервіси продовжують відповідати.
• Ручні операції при збої: було 12–15 кроків за чек-лістом; стало нуль — кворум і віртуальна адреса відновлюються самі.
• Планові оновлення без зупинки сервісів: було близько половини, решта — у вікно простою; стало 100%, витіснення подів укладається у звичайний режим навантаження.
• Введення нового вузла в контур: з кількох годин до десятків хвилин за одним відтворюваним сценарієм.

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

Що робити, якщо кластер уже зібрано вручну?

Спочатку інвентаризація: скільки вузлів управління, де живе etcd, як оформлені сертифікати й kubeconfig, чи є балансувальник перед API-сервером.

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

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

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

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

Простою немає: перемикання йде на живому сервісі, а відкат — повернути трафік на старий контур, поки той ще на місці.

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

Часті технічні питання: мережа, оновлення, відмова вузлів

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

У якому порядку оновлювати кластер?

Йдемо по одному вузлу: спочатку вузли управління, потім робочі, з витісненням навантаження перед перезапуском. Мінорні версії підвищуємо послідовно, без перестрибування — інакше сумісність компонентів і відкат стають непередбачуваними.

Перед кожним кроком — знімок etcd, після — перевірка, що всі вузли повернулися в Ready і навантаження роз'їхалося.

Що станеться при відмові вузла або розділенні мережі?

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

Як влаштовано резервне копіювання стану?

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

Обговоримо вашу задачу: складемо план і оцінку робіт

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

• Склад кластера. Скільки вузлів управління й робочих вузлів планується, один майданчик чи кілька зон, чи потрібен балансувальник перед контуром управління.
• Вимоги до доступності. Допустимий час недоступності, поведінка при відмові вузла або зони, чи потрібна планова заміна вузлів без зупинки сервісів.
• Оточення. Власні сервери чи хмара, які мережі й сховища вже є, які політики безпеки й доступи доведеться дотримати.
• Профіль навантаження. Скільки сервісів переїжджає, чи є стан, які вимоги до дискових томів і резервного копіювання.
• Строки й етапність. До якої дати потрібен робочий контур, чи є вікна на роботи, збираємо з нуля чи переносимо чинний кластер.
• Експлуатація після здачі. Хто відповідає за кластер далі й чи потрібна передача знань команді замовника.

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