Чому kubernetes-маніфести ламаються під час масштабування
Викат, який на тестовому контурі пройшов без зауважень, падає в продуктиві вже на першому кроці.
Формально це ті самі kubernetes-маніфести з репозиторію, але кластер відповідає помилкою: ліміти не збігаються з реальним навантаженням, селектори Service не знаходять подів, а Ingress указує на клас, якого в цьому оточенні немає. Відмова під час викату виглядає як випадковість, хоча причина накопичилася заздалегідь.
Розбіжність оточень починається з дрібниць. На тестовому контурі реплік менше, ліміти м'якші, Secret зібраний з іншого набору ключів, Ingress-правила урізані до одного хоста.
Kubernetes не порівнює оточення між собою — він чесно виконує те, що описано, тому різні значення для Deployment і Service розходяться мовчки, до першого реального трафіку.
Далі з'являються ручні правки ресурсів. Хтось править ліміти прямо в кластері, щоб зняти аварію, хтось додає анотацію, хтось змінює образ на попередній. Кластер стає єдиним джерелом істини, а репозиторій — застарілою копією.
Відтворюваність оточення втрачається: новий контур з тих самих файлів уже не піднімається, а відкат до попереднього релізу неможливий, бо попереднього опису не збереглося.
Ціна такої схеми — зростання кількості відмов під час викату й час, що йде на розбір розбіжностей замість роботи над продуктом. Розбираємо, як це закривається: єдиний опис ресурсів, перевірка маніфестів до застосування та контроль розбіжностей між оточеннями.
Вимірювані ефекти керованої конфігурації
Декларативний опис ресурсів змінює не зручність роботи, а вимірювані показники експлуатації. Час викату скорочується, бо новий стан застосовується цілком, а не збирається по кроках із ручних команд.
Один і той самий набір описів проходить однаковий шлях на тестовому й робочому контурі, тому розбіжність оточень перестає бути джерелом сюрпризів.
Швидкість відкату впирається не в зібраність чергового, а в наявність попередньої робочої ревізії. Коли конфігурація версіонується разом із кодом, повернення — це одна передбачувана дія: застосовується збережений опис, і кластер сам приводить ресурси до потрібного стану. Так частка успішних відкатів зростає завдяки процедурі, а не завдяки героїзму.
Частка ручних помилок падає там, де зміну спершу перевіряють на коректність і лише потім вона потрапляє в кластер.
Друкарська помилка в імені об'єкта, забутий параметр, зайва правка «на місці» через консоль — цей клас відмов просто зникає, бо джерелом істини залишається опис, а не жива пам'ять інженера.
Стабільність оточень тримається на відтворюваності: однакові описи дають однаковий результат за повторного розгортання, а не «приблизно схожий».
Звідси й вплив на вартість простою — зникає не час відновлення як такий, а цілий клас аварій, пов'язаних із незнайденою розбіжністю конфігурацій.
Перевірити це можна за чотирма числами: час викату, час повернення до попередньої ревізії, частка змін, що пройшли перевірку до застосування, і кількість інцидентів, спричинених ручною правкою.
Саме ці метрики ми фіксуємо до переведення ресурсів у декларативний вигляд і після — щоб ефект було видно в цифрах, а не у відчуттях.
Варіанти опису ресурсів: порівняння підходів
Поки сервіс один і оточення одне, будь-який спосіб опису ресурсів працює однаково. Різниця проявляється на десятках сервісів і двох-трьох оточеннях: стає важливо, звідки береться істина й що станеться за наступної зміни. Тому підхід обирають за вартістю супроводу, а не за зручністю першого викату.
Альтернативи, між якими реально обирають:
| Варіант | Коли підходить | Обмеження підходу |
|---|---|---|
Ручні файли та kubectl apply |
один-два сервіси, одне оточення, разові завдання | копіпаста між середовищами, зміни не відтворюються, шаблони опису не фіксуються |
| Шаблони з підстановками | багато однотипних сервісів, різні середовища, потрібні версії та відкат | логіка розгалужень у шаблонах, налагодження лише через пробний рендер, читабельність падає |
| Оверлеї та патчі поверх базової конфігурації | типова база плюс відмінності за середовищами | патчі перекривають один одного, порядок накладання тримається в голові |
| Генерація з єдиного джерела опису | сервісів багато, склад ресурсів стандартний | потрібен власний генератор і його підтримка, нестандартні випадки все одно пишуться вручну |
На практиці виграє гібрид: типовий набір — Deployment, Service, Ingress — генерується з єдиного джерела опису, а особливі місця на кшталт Secret із зовнішнього сховища залишаються окремими файлами.
Правило одне: у кожного ресурсу має бути одне джерело, інакше ручний супровід повертається, і розбіжності між середовищами стають питанням часу.
Порядок впровадження: від аудиту до передачі
Роботи йдуть послідовно: кожен етап спирається на результат попереднього, тому пропущена інвентаризація випливає вже на проді — конфліктами ресурсів і ручними правками. Нижче порядок, за якого маніфести стають керованою конфігурацією, а не набором файлів «під поточний реліз».
- Аудит ресурсів. Збираємо фактичний стан кластера: які Deployment, Service, Ingress і Secret існують, що створено руками, де дублі, як задані ліміти та проби. На виході — карта ресурсів із позначкою, що переноситься в декларативний опис, а що виводиться з експлуатації.
- Схема оточень. Розмічаємо контури та їхні відмінності: які значення виносяться окремо, що перевизначається накладанням, де зберігаються секрети. Це прибирає копіювання маніфестів між середовищами й розбіжності, що накопичуються під час ручної правки.
- Налаштування політик. Задаємо правила іменування та міток, запити й ліміти за ресурсами, розмежування доступу та перевірку маніфестів до застосування — у репозиторії й на вході в кластер за індивідуальним розрахункомСкладання та рев'ю маніфестів. Описуємо Deployment, Service, Ingress і Secret як версіоновані файли, проганяємо статичні перевірки та рев'ю змін: правка конфігурації проходить той самий шлях, що й код.
- Перевірка на тестовому контурі. Розкочуємо повний набір на тестовому середовищі, перевіряємо оновлення без простою, відкат на попередню ревізію та поведінку за недоступного вузла. Помилки конфігурації ловимо тут, а не на бойовому контурі.
- Передача супроводу. Віддаємо репозиторій, опис схеми оточень і регламент змін, навчаємо команду: як додати сервіс, як випустити й відкотити реліз, куди дивитися в разі збою.
Після передачі у вас залишається відтворювана конфігурація й команда, яка може її змінювати без нас.
Комплект постачання: конфігурації, схеми, політики доступу
Маніфести без супровідного комплекту швидко перетворюються на археологію: за півроку ніхто не пам'ятає, чому в Deployment виставлені саме такі ліміти, звідки взявся namespace і хто має право правити Secret.
Тому комплект постачання — це не лише YAML-файли, а пакет, за яким ваша команда розгортає оточення з нуля й супроводжує його без нас.
- Описи ресурсів — Deployment, Service, Ingress, ConfigMap, Secret, HorizontalPodAutoscaler: розкладені по каталогах без дублів, із коментарями до неочевидних параметрів — стратегія оновлення, проби готовності, запити й ліміти.
- Схема оточень — які namespace існують, чим dev відрізняється від stage і prod, де живуть спільні ресурси й як розділяються конфігурації між контурами.
- Політики доступу — ролі та прив'язки RBAC, правила мережевої ізоляції між сервісами, квоти на namespace: описано, хто і що може змінювати в кластері.
- Керування секретами — звідки беруться значення, як потрапляють у кластер, як ротуються і хто має право на читання.
- Регламент оновлення — порядок викату, версіонування образів, умови відкату на попередню ревізію та поведінка системи за невдалого оновлення.
- Документація — стислий опис архітектури, інструкції з розгортання та типових операцій: діагностика пода, масштабування, підключення нового сервісу.
Кейс: час викату та клас усунених відмов
Замовник — продуктова команда з десятком сервісів: маніфести Kubernetes правилися під кожне середовище вручну, викат ішов по кроках із локальної консолі. Реліз займав 40–50 хвилин, розбіжності між середовищами накопичувалися непомітно й випливали вже на проді.
Повернення до попереднього стану було окремою операцією на 15–20 хвилин, і робити її доводилося в поспіху, коли щось уже не працювало.
Що показав розбір
Половина збоїв — дрейф конфігурації: правки, зроблені прямо в кластері, жили паралельно з файлами й розходилися з ними. Чверть — відсутність перевірок готовності, через що трафік потрапляв на сервіс, який ще не піднявся. Решта — секрети з різними значеннями в середовищі розробки та на проді.
Що змінили
Описи переїхали в репозиторій, спільні значення відокремилися від середовищних, секрети — у кероване сховище за посиланнями замість копій.
Додали перевірки готовності та живучості, викат став поетапним із автоматичною зупинкою за відхилення метрик, а відкат — поверненням попереднього набору описів. Час релізу скоротився з 40–50 хвилин до 6, повернення до попереднього стану — до хвилини й однієї операції.
Дрейф конфігурації пішов як клас: будь-яка зміна тепер проходить через репозиторій і перевірку. Частка релізів, що потребували ручного втручання, знизилася до поодиноких випадків за квартал, а неповний викат перестав бути збоєм — він штатно завершується відкатом сам.
Чим декларативний опис ресурсів відрізняється від ручної правки в кластері?
Маніфести Kubernetes — це декларативний опис бажаного стану ресурсу: скільки реплік тримати, який образ використовувати, які порти відкрити й який Secret підключити.
Кластер порівнює опис із фактичним станом і сам приводить його до потрібного вигляду — втручатися вручну не потрібно й навіть шкідливо.
Ручна правка влаштована протилежним чином. Інженер змінює живий об'єкт через командний рядок, і стан кластера починає збиратися з набору змін, яких немає в жодному файлі.
Далі або контролер повертає ресурс до маніфесту й правка «блимає», або розбіжність залишається — і випливає під час перестворення оточення, коли потрібні анотації та параметри зникають.
Різниця підходів зводиться до того, де міститься джерело істини. За декларативного опису це файл у системі контролю версій: зміна проходить через правку, перевірку та застосування, а кластер залишається похідним від опису.
За ручного джерелом істини стає сам кластер, і ніхто точно не знає, які налаштування там накопичилися й навіщо.
В експлуатації це змінює дві речі. Дрейф перестає бути загадкою: розбіжність видно під час порівняння опису з фактом, а відновлення після збою зводиться до застосування тих самих файлів.
Історія змін відповідає, хто і коли поміняв конфігурацію, і відкат іде на попередню версію опису, а не на пам'ять чергового.
Часті технічні сумніви про kubernetes-маніфести
Технічні сумніви перед наведенням ладу в маніфестах Kubernetes майже ніколи не стосуються синтаксису. Замовника турбує ціна помилки: що станеться з уже працюючими навантаженнями, хто побачить секрети, чи доведеться переписувати політики доступу. Нижче — чотири питання, які випливають на кожному розборі, і те, як ми їх закриваємо.
Секрети лежать прямо в описах — що буде під час перенесення?
Значення виносяться в окремі об'єкти й підключаються посиланнями — у репозиторії та історії змін залишаються лише імена. Доступ до них видаємо за ролями, вмикаємо шифрування у сховищі кластера й ротацію, а кожне читання потрапляє в журнал аудиту.
Чи можна перевести продакшен без простою?
Оновлення йде поступово: нові копії застосунку починають приймати трафік лише після успішної перевірки готовності, старі гасяться слідом. Відкат — це повернення попереднього набору описів із репозиторію, вікно обслуговування не потрібне.
Оточення розійшлися — тест не повторює продакшен?
Розбіжності знімаємо спільною базою описів: стенди відрізняються лише параметрами — кількістю копій, лімітами, адресами, — а не структурою об'єктів. Автоматична звірка в складанні ловить дрейф одразу, а не за місяць.
Що буде з наявними ролями та політиками доступу?
Ролі та прив'язки переносяться декларативно, без розширення прав; уже працюючі об'єкти описуємо й приводимо до спільного вигляду поступово, не зупиняючи їх. Перед здачею звіряємо набір дозволів за кожним оточенням із поточним станом і окремо фіксуємо зайве.
Обговоримо завдання: порядок старту робіт
Перша розмова — це не презентація, а звірка ввідних: без них будь-яка оцінка перетворюється на вгадування. Щоб порахувати обсяг робіт із маніфестами Kubernetes, нам потрібно побачити контур цілком — від оточень до того, як реліз зараз потрапляє в кластер.
- Перелік оточень і кластерів: dev, stage, prod, відмінності за неймспейсами, лімітами ресурсів і політиками доступу.
- Як деплой влаштований сьогодні: ручне застосування, складальний конвеєр, Helm чи декларативне керування з репозиторію — від цього напряму залежить обсяг роботи.
- Вимоги до секретів і конфігурації: звідки беруться значення, чи потрібна інтеграція із зовнішнім сховищем, хто і як отримує доступ.
- Мережевий контур: домени, сертифікати, правила маршрутизації, хто їх видає і як вони оновлюються.
- Вимоги до оновлень і відкату: стратегія розкочування, перевірки готовності, допустиме вікно недоступності сервісу.
- Хто з боку замовника підтверджує рішення і наскільки швидко доступні стенди для перевірки.
За цими ввідними ми повертаємося не з приблизною вилкою, а з планом: склад команди, етапи, строки за кожним і те, що потрібно від вас на кожному кроці. Опишіть завдання — повернемося з оцінкою та планом.
