Розробка Kustomize-конфігурацій: де ламається ручне керування
Поки середовищ два, маніфести правлять руками: копіюють робочий набір, змінюють тег образу та кількість реплік, викочують.
На третьому контурі з'являється тестовий стенд з іншим Ingress і лімітами ресурсів, і виявляється, що однакових файлів більше немає: розходження накопичувалися місяцями, і вже ніхто не скаже, які з них усвідомлені, а які — слід нічного налагодження.
Дрейф конфігурацій між середовищами спливає в найнезручніший момент. Відкат на попередній реліз не відтворюється: у кластері залишилися правки, внесені напряму, повз репозиторій.
Історія змін інфраструктури живе в листуванні та чиїйсь пам'яті, а декларативні конфігурації Kubernetes існують лише на папері — джерело істини розмите між репозиторієм і живим кластером.
Ціна такої моделі вимірюється не хвилинами на правку, а класом відмов.
Оновлення пройшло на тестовому контурі, але не на продуктивному, бо набори розійшлися; видалена секція в базовому маніфесті ламає сусідній контур, який її не перевизначав; перевірка перед викочуванням показує одне, а в кластері виявляється інше.
Кожна така ситуація шукається вручну й закінчується ще однією правкою руками — тобто новим розходженням.
Розробка Kustomize-конфігурацій прибирає саму можливість такого розходження: база описує спільне для всіх контурів, overlay — лише відмінності, а збирання маніфесту передбачуване й повторюване. Розбираємо, як це закривається на практиці.
Ефект в експлуатації: швидкість викочування, відкату й відновлення
Декларативне збирання конфігурацій змінює те, як вимірюється час викочування релізу.
Overlay описує лише відмінність середовища від базового шару — розробник править дельту, а не копію маніфесту цілком, тому шлях зміни від гілки до працюючого пода стає коротким і однаковим для всіх середовищ.
Під час збирання через Kustomize і зберігання середовищ у Git викочування зводиться до застосування вже зібраного стану: немає кроку «руками поправити в кластері те, що забули в репозиторії».
Частка ручних операцій у релізі падає разом із цим. Правки доступу, лімітів, кількості реплік і адрес зовнішніх сервісів живуть в окремих шарах і успадковуються передбачувано, тому типовий реліз проходить без доступу інженера до кластера.
Те, що раніше трималося на пам'яті чергового, тепер зафіксовано в репозиторії й проходить перевірку до застосування.
Час відновлення після відмови визначається тим, чи є в системи відомий попередній стан. Він є: повернення — це відкат коміту й повторна звірка, а не аварійне редагування об'єктів під навантаженням.
Звірка повертає кластер до описаного стану цілком, включно з об'єктами, які хтось змінив вручну між релізами.
Вартість простою сервісу тут вимірюється не годинами, а часткою години: інцидент закривається перемиканням на перевірену ревізію, а не пошуком причини в живому середовищі.
Зникає цілий клас відмов — розходження конфігурацій між стендами й продом, через яке однаковий код поводиться по-різному.
Режими роботи з конфігураціями: порівняння підходів
Відмінності між контурами зазвичай вкладаються в десяток значень: кількість реплік, ліміти, адреси зовнішніх сервісів, режими логування.
Те, як ці відмінності описані, визначає ціну додавання нового середовища й передбачуваність викочування — за одного підходу достатньо нового накладення, за іншого доведеться правити всі файли одразу.
Порівняння підходів конфігурування за трьома критеріями — де зберігаються відмінності, скільки ручної роботи на новий контур і що відбувається з відтворюваністю:
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Спільна база конфігурацій + накладення для середовищ | Контурів три й більше, відмінності — одиниці параметрів | Потрібна дисципліна: правка або в базі, або в накладенні, інакше контури розходяться |
| Незалежні набори на кожен контур | Середовища розійшлися сильно: різні компоненти й власники | Кожна зміна тиражується вручну, дрейф зростає з кожним новим контуром |
| Ручні правки після генерації | Разовий стенд на день-два | Правка губиться під час наступної генерації, відтворюваність нульова |
| Шаблони з підстановкою змінних | Багато однотипних сервісів, значення надходять ззовні | Умови й розгалуження ускладнюються, зникає перевірка коректності |
На практиці стійко працює зв'язка «спільна база конфігурацій плюс накладення для середовищ»: база проходить перевірку один раз, у накладенні лежать лише відмінності, і рев'ю займає хвилини.
Шаблони з підстановкою змінних залишаємо для значень із зовнішнього джерела — адрес і облікових даних; описувати ними всю конфігурацію означає втратити перевірку коректності й розбирати результат генерації вручну.
Якщо в проєкті досі правлять файли після генерації — це перша ознака, що описом середовищ пора займатися системно.
Етапи впровадження: від аудиту до передачі регламентів
Роботи йдуть хвилями, і кожна завершується перевірюваним артефактом: спочатку фіксуємо фактичний стан, потім проєктуємо структуру й лише згодом вмикаємо автоматичну синхронізацію.
Порядок прибирає класичну помилку — GitOps підключають раніше, ніж конфігурації приведено до єдиного вигляду, і оператор починає видаляти те, що роками правили руками.
- Аудит маніфестів і кластера. Звіряємо репозиторій із реальним станом, знаходимо ручні правки, дублі й розходження за лімітами. На виході — карта середовищ і список ресурсів, які не можна віддавати автоматиці.
- Проєктування структури. Домовляємося про базовий шар і оверлеї на середовище, про іменування, про те, що йде в спільні патчі, а що — у генератори конфігів і секретів.
- Налаштування репозиторію конфігурацій. Розкладаємо каталоги, вбудовуємо збирання конфігурацій у перевірку змін, вмикаємо валідацію схем і обов'язковий перегляд різниці перед застосуванням.
- Збирання середовищ. Тестовий, передпродуктивний і продуктивний оверлеї; стежимо, щоб відмінності описувалися патчами, а не копіями файлів.
- Перевірка й приймання на тестовому контурі. Проганяємо повний цикл синхронізації з автокорекцією дрейфу, дивимося поведінку під час відкату й під час видалення ресурсу з репозиторію.
- Перенесення продакшену. Переводимо середовище покроково, залишаючи відкат поверненням коміту, і закриваємо ручні доступи лише після стабільної роботи.
- Передача регламентів. Віддаємо інструкції щодо додавання середовища й сервісу, правила рев'ю змін, порядок відкату, проводимо навчання чергової зміни.
Склад постачання: репозиторій, схеми середовищ, регламенти й доступи
Матеріальний результат — не розсип файлів, а робочий контур: репозиторій із конфігураціями Kustomize, який розгортається з нуля на чистій машині, і регламенти, за якими ваша команда далі змінює середовища сама. Нижче — що саме переходить вам за актом.
- Структура репозиторію: базові шари, накладення під кожне середовище — розробку, стенд, продуктив, спільні модулі й точки розширення. Порядок застосування шарів зафіксовано, тому збирання дає однаковий результат у будь-якого інженера.
- Схема середовищ: таблиця відмінностей — що винесено в накладення, що залишилося спільним, які налаштування додаються з появою нового стенда.
- Політики доступу й ролі: хто править базові шари, хто — лише накладення стенда, хто підтверджує викочування в продуктив. Права видаються ролями, персональних винятків немає.
- Робота з секретами: що зберігається в захищеному сховищі, як значення підставляються в конфігурації, як проходить ротація і чому ключі не потрапляють у репозиторій.
- Регламент викочування змін: перевірка конфігурації до злиття, обов'язкова перевірка другим інженером, порядок погодження прод-правок.
- Відкат: мітки версій, історія змін і покрокова процедура повернення до попереднього стану — включно з випадком, коли правка вже торкнулася даних.
- Документація інфраструктури: карта середовищ, схема залежностей, інструкція розгортання з нуля й типові операції. Новий інженер вводиться в контур за нею, без усних пояснень.
Кейс: як скоротили час викочування й прибрали ручні правки
Проєкт — платформа з 60+ сервісів на чотирьох контурах: розробка, тестовий, передпродуктивний і продуктивний.
Конфігурації лежали в трьох місцях одночасно: шаблони з перевизначеннями, скрипти в складальному конвеєрі та ручні правки чергового прямо в кластері, коли потрібно було підняти ліміти або змінити адресу зовнішньої залежності.
Чим саме продуктив відрізнявся від передпродуктивного, достовірно не знав ніхто — крім інженера, який останнім щось поправив.
Що було до
Викочування одного контуру займало 40–50 хвилин, і більша частина часу йшла не на збирання, а на очікування та ручні перевірки між кроками. У кожному релізі інженери вносили 10–14 правок руками: десь через панель керування кластером, десь правкою файлу на сервері.
Помилка в такій правці не відтворювалася на тестовому контурі — вона проявлялася лише на продуктиві, і на розбір ішло від двох годин. Інцидентів, причиною яких було розходження конфігурацій між контурами, набиралося три-чотири на місяць.
Що стало після
Ми перенесли описи в єдиний декларативний вигляд на Kustomize: спільний базовий шар, поверх нього перевизначення за контурами, відмінності винесено в окремі файли, а не сховано в скриптах.
Зміни проходять перевірку й застосовуються автоматично з репозиторію — стан кластера завжди відповідає тому, що лежить в основній гілці.
| Метрика | До | Після |
|---|---|---|
| Викочування одного контуру | 40–50 хвилин | 6–8 хвилин |
| Ручні правки на реліз | 10–14 | 0 |
| Відкат до попереднього стану | ~30 хвилин | до 5 хвилин |
| Інциденти через розходження конфігурацій | 3–4 на місяць | 1–2 на квартал |
Окремо варто сказати про довгі розбори: тепер розходження видно на етапі перевірки змін, до продуктивного контуру, тому клас відмов «на тестовому працювало, на продуктиві ні» з процесу зник.
Чим декларативне збирання відрізняється від шаблонізації?
Шаблонізація підставляє значення в текст маніфесту: рушій рендерить єдине джерело зі змінними й умовами, і валідний документ виходить лише після рендера.
Накладення — підхід Kustomize — працюють інакше: поверх спільної бази застосовується патч, який змінює окремі поля — кількість реплік, ресурси, адресу зовнішнього сервісу, набір міток. База залишається самостійним робочим маніфестом, який можна застосувати як є.
Накладення виграють там, де середовища розходяться на одиниці полів. Патч стратегічного злиття не переписує структуру, а доповнює її, тому спільний каркас живе в одному місці, а відмінності стенда читаються за хвилину.
Додали сервіс — він з'являється в усіх середовищах одразу, а вимкнути його на конкретному стенді можна окремим винятком.
Шаблони потрібні, коли структура справді розгалужується: різні набори сервісів, обчислювані значення, генерація із зовнішнього реєстру. Плата за це — втрата перевірюваності до рендера.
Шаблон не можна застосувати напряму, і помилка в умові спливає вже в кластері, а не на машині інженера.
На дистанції підтримка середовищ тримається на тому, чи відновлюється підсумковий стан за ланцюжком «база плюс патчі». Якщо для відповіді на питання «що поїде в кластер» треба відкрити п'ять шаблонів і три набори значень, супровід перетворюється на археологію.
Практичний вибір — база з накладеннями як основа, а шаблон точково, для місць із справжньою логікою.
Технічні сумніви: секрети, середовища, міграція
Сумніви в інженерів виникають не на рівні ідеї, а на рівні деталей: де живуть секрети, що робити з контуром, який роками правили руками, і як перейти на декларативне керування, не зупинивши продакшен. Нижче — відповіді на те, що найчастіше перевіряють перед стартом.
Як зберігаються секрети?
Паролі й токени не потрапляють у репозиторій відкритим текстом. У git лежить зашифроване значення, розшифрування відбувається в кластері за ключем, доступним лише цьому контуру. Ротація планова: змінюється значення в сховищі, overlay перекочує поди без правок у коді застосунку.
У нас усе налаштовано руками — переписувати з нуля?
Ні. Спочатку знімаємо фактичний стан контуру в маніфести й розкладаємо його на спільний base та overlay. Далі йде звірка: зібрана конфігурація порівнюється з поточною, різниця показується до застосування. Після перемикання контур керується лише з репозиторію, а ручна правка відкочується автоматично.
Чи можна мігрувати без зупинки продакшену?
Так, перемикання йде за контурами: новий варіант піднімається поряд зі старим, проходить перевірки на живому трафіку, і лише потім трафік переводиться. Відкат — зворотне перемикання на попередній overlay, займає хвилини й не потребує перезбирання образів.
Чому стенд і продакшен розходяться?
Бо відмінності правлять вручну в двох місцях. Ми виносимо їх в overlay явно: кількість реплік, ліміти ресурсів, адреси зовнішніх сервісів, теги образів. Спільний base при цьому один, тому розходження видно до застосування, а не спливає в момент релізу.
Що відбувається після передачі?
Віддаємо репозиторій, схеми середовищ та інструкції з типових операцій — реліз, відкат, додавання нового середовища. Навчання проводимо на ваших контурах. Далі — супровід за договором: оновлення, розбір інцидентів, доопрацювання overlay у разі зростання кількості сервісів.
Обговоримо задачу й повернемося з оцінкою та планом
Щоб оцінка була предметною, а не «плюс-мінус порядок», у заявці достатньо описати кілька речей — нижче те, що допомагає швидше порахувати обсяг.
- Цільові кластери й середовища: скільки їх, чим dev відрізняється від stage і prod.
- Поточний стан конфігурацій: єдиний набір маніфестів, чарти чи вже зібрані overlay-и, що в них дублюється.
- Склад базового шару: робочі навантаження, сервіси, маршрутизація, параметри середовища, секрети й спосіб їх підстановки.
- Модель доступів: хто змінює конфігурації, чи потрібні окремі ролі під команди й рев'ю змін.
- Вимоги до викочування й відкату: як швидко повертати попередній стан, чи потрібні поетапні розкочування.
- Контур GitOps: яка гілка вважається джерелом істини, чи є обмеження щодо зовнішніх репозиторіїв.
- Організаційні рамки: закритий контур, власні реєстри образів, вимоги безпеки й аудиту.
На дзвінку уточнюємо межі: які середовища йдуть у перший етап, що перевикористовуємо з поточних конфігурацій, де потрібні окремі шари під команду.
На виході ви отримуєте оцінку обсягу, порядок робіт за етапами й схему, за якою впровадження декларативних конфігурацій під ключ доходить до передачі інфраструктури команді — з документацією й розбором рішень.
Опишіть задачу за пунктами вище — обговоримо її предметно й повернемося з оцінкою та планом робіт.
