Розробка Helm charts для деплою в Kubernetes: де ламається
Поки Helm charts немає, деплой у Kubernetes тримається на ручних маніфестах і пам'яті одного інженера. Хтось пам'ятає, що в тестовому контурі образ тегується інакше, а в продуктивному потрібен окремий набір змінних середовища.
Правки при цьому вносяться через kubectl apply прямо в кластер, минаючи репозиторій, — і у репозиторії залишається не те, що реально працює.
Далі розходяться контури. Різниця між тестовим і продуктивним середовищем накопичується в дрібницях: ліміти ресурсів, кількість реплік, адреси зовнішніх сервісів, увімкнені перевірки готовності, порядок застосування ConfigMap і Secret.
Через кілька тижнів ніхто не може виразно сказати, чим живий кластер відрізняється від описаного у файлах, а перенесення будь-якої зміни перетворюється на окрему задачу з ревізією вручну.
Найбільше ускладнює відкат релізу. Команда відкату повертає лише те, що Helm пам'ятає у своєму стані, — ручні правки після встановлення залишаються в кластері й далі ламають поведінку.
Інцидент розбирають вручну: звіряють історію застосованих маніфестів, події кластера й логи подів, щоб зрозуміти, яка саме зміна призвела до збою.
Підсумок передбачуваний: викатка займає години, результат залежить від того, хто чергує, а відновлення попередньої версії — це не одна команда, а розслідування.
Розбираємо, як це закривається: що описують у чартах, як розділяють значення за контурами і завдяки чому відкат релізу стає відтворюваним.
Що змінюється після переходу на декларативний деплой
Після переходу на декларативний деплой стан застосунку описується файлами значень, а не послідовністю ручних дій.
Кластер приводиться до описаного вигляду однією командою — і змінюються вимірювані показники: час викатки, вікно простою, частка інцидентів через розбіжності між стендами.
Час викатки скорочується: шаблони налагоджені, змінюються лише параметри.
Відкат перестає бути окремою операцією відновлення — попередня ревізія релізу зберігається поруч, і повернення до неї займає стільки ж, скільки звичайне розгортання, замість ручного складання маніфестів заново.
Зникає цілий клас відмов — розбіжність середовищ. Один набір шаблонів і окремі файли значень для тестового та промислового контурів означають, що відмінності описані явно в репозиторії, а не тримаються в голові інженера, який правив кластер вручну.
Простій сервісу стає передбачуваним. Перевірки готовності не пускають трафік у непрогрітий контейнер, політика оновлення задає, скільки екземплярів виводиться з ладу одночасно, а передустановчі завдання відпрацьовують до початку розгортання.
Для сервісів без стану вікно простою зводиться до нуля, для сховищ даних воно розраховане заздалегідь і перевірене на тестовому контурі.
Відтворюваність середовищ перестає залежати від того, хто і коли піднімав стенд: той самий чарт розгортає новий контур в ідентичному вигляді.
Звідси й короткий чек-ліст ефектів — швидкий час викатки та відкату, відсутність розбіжностей між середовищами, відоме вікно простою, повторювана конфігурація під час кожного розгортання.
Варіанти організації релізів: порівняння підходів
Підхід до викатки майже завжди виростає з першого робочого рішення — і це видно за обмеженнями, які потім накопичуються. Нижче чотири варіанти, між якими реально обирають команди, коли застосунків стає більше, ніж один кластер, а середовищ — більше одного.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Ручні маніфести й ручний apply | Один сервіс, один кластер, один інженер | Бажаний стан ніде не зафіксовано: середовища розходяться, відкат — ручна правка |
| Саморобні скрипти викатки | Потрібно підставити змінні середовища в готові файли | Скрипт описує процес, а не результат, і обростає винятками під кожен сервіс |
| Один чарт на застосунок, окремі values за середовищами | Кілька середовищ, часті релізи одного продукту | Потребує дисципліни у values: складні умови в шаблонах маніфестів читаються важко |
| Чарт із залежностями та спільними бібліотечними чартами | Кілька команд, спільні ресурси, єдині правила | Залежності потрібно версіонувати й стежити за їхньою сумісністю |
На практиці ми рідко починаємо з чартів «з нуля»: спочатку шаблони маніфестів описують те, що вже викочується вручну, щоб бажаний стан збігся з фактичним.
Далі спільні частини — мережеві політики, секрети, черги — виносяться в залежності чартів, і застосунок перестає дублювати чужі файли.
Саморобні скрипти викатки зазвичай відмирають останніми: їх замінює чарт із перевірками helm lint і dry-run перед застосуванням. Це дає передбачуваний відкат на попередню ревізію й однаковий результат на всіх середовищах.
Етапи роботи: від аудиту маніфестів до передавання
Роботу ведемо ітераціями: кожен крок закінчується перевірюваним артефактом, і наступний починається лише після того, як попередній прийнято. Так помилка в схемі релізу не спливає вже на проді, коли її наслідок — простій сервісу.
- Інвентаризація сервісів і аудит маніфестів. Збираємо все, що розгорнуто в кластері, включно з тим, що ставили вручну. Розділяємо об'єкти на спільні для всіх сервісів і унікальні, фіксуємо дублі й «попливли» значення в окремих середовищах — це карта майбутньої шаблонізації.
- Проєктування схеми релізу. Вирішуємо, де буде один парасольковий чарт, а де самостійні, що живе як залежність, як успадковуються значення за середовищами. Узгоджуємо імена ресурсів, щоб реліз одного сервісу не затирав сусідній.
- Налаштування шаблонів. Виносимо повторюване в спільні фрагменти, описуємо схему значень із перевіркою їхньої коректності до застосування. Анотації з контрольними сумами конфігурацій закривають ситуацію, коли застосунок залишається працювати на старих налаштуваннях після оновлення.
- Перевірка відкату. Вчимося відкатуватися усвідомлено: дивимося історію ревізій, стан міграцій і хуків, розуміємо, що саме відкотиться разом із застосунком, а що залишиться. Якщо крок не повертається — змінюємо схему, а не пишемо інструкцію.
- Обкатка в тестовому контурі. Прогоняємо повний цикл «встановлення — оновлення — відкат» на тестовому контурі, близькому до проду за складом ресурсів. Реліз вважається атомарним: у разі падіння перевірки готовності схема повертається до попередньої ревізії сама.
- Передавання документації. Передаємо опис чартів, схему значень із поясненнями, порядок релізу та відкату, правила версіонування. Документація живе в репозиторії поруч із шаблонами, а не окремим файлом.
- Навчання команди й супровід перших релізів. Проходимо з вашими інженерами перший випуск, розбираємо аналіз невдалих прогонів і правки значень. Далі команда веде релізи самостійно — нам залишаються консультації щодо схеми.
Комплект постачання: чарти, схеми й регламенти
Комплект постачання — це не архів із шаблонами, а робоча система, у якій замовник може випускати релізи без нашої участі. Передаємо все, що потрібно для складання, перевірки та викатки: від структури репозиторію до інструкцій для чергової зміни.
- Репозиторій чартів з історією змін: одне джерело правди для всіх середовищ, галуження під релізи й рев'ю правок через merge-запити.
- Параметризація середовищ: тестовий і промисловий контури відрізняються лише файлом значень, а не копією шаблонів — розбіжність між середовищами перестає накопичуватися.
- Схеми залежностей: які чарти пов'язані між собою, що підтягується зі спільного репозиторію, де зовнішні сервіси та порядок їхньої появи.
- Політики доступу: хто править значення промислового контуру, хто має лише читання, як розмежовано ролі в кластері й хто затверджує зміни.
- Регламент релізу: послідовність викатки, обов'язкові перевірки перед публікацією, критерії, за яких випуск зупиняють.
- Регламент відкату: повернення на попередню ревізію однією командою, що відбувається з даними й міграціями, за який час середовище повертається в робочий стан.
- Документація деплою та інструкція чергової зміни: типові збої, діагностика, кому ескалювати, що можна й не можна робити вручну.
Кожен пункт узгоджений з командою замовника на прийманні, а не зданий «в папці». Інженери замовника проходять розбір конфігурацій і пробний випуск самостійно — після цього комплект вважається прийнятим.
Кейс: релізний цикл на Helm скоротився з двох днів до години
Точка старту
Сервіс із дванадцяти компонентів — API, воркери, планові завдання, міграції схеми — розгортався набором ручних маніфестів, розмножених по чотирьох середовищах.
Правки в одному каталозі не доходили до інших: розбіжності накопичувалися, а реліз перетворювався на дводенний ритуал зі звірянням файлів вручну.
Відкат займав не менше сорока хвилин і виконувався зворотним застосуванням тих самих маніфестів — тобто кожна аварійна ситуація несла в собі ризик нової помилки.
Що змінили і що отримали
Ми зібрали параметризовані чарти Helm: бібліотечний чарт із шаблонами для деплойменту, сервісу, ingress, проб готовності та автомасштабування, а поверх — тонкі чарти сервісів, де у файлі значень залишаються лише образ, ліміти й змінні середовища.
Відмінності між стендами описуються окремими наборами значень, секрети надходять із зовнішнього сховища й у репозиторій не потрапляють.
Перед застосуванням шаблони рендеряться й порівнюються з поточним станом релізу, тому помилка конфігурації ловиться до продакшену.
Реліз — одна команда застосування й до години від злиття правки до робочого середовища разом із прогоном перевірок; ручних кроків стало два замість трьох десятків. Відкат — хвилини: повернення до попередньої ревізії релізу цілком, а не складання набору файлів заново.
Зник цілий клас відмов, пов'язаний із розбіжністю середовищ: конфігурація описується одним джерелом, а відмінності стендів видно очима до застосування.
Що робити, якщо в кластері вже розгорнуто ручні маніфести
Єдиного правильного шляху немає: вибір залежить від кількості сервісів на ручних маніфестах і частоти їхніх правок. Загальний принцип — не перезбирати робочий контур, а приводити його до чартів так, щоб сервіси не перестворювалися й не втрачали стан.
Тому першим кроком іде інвентаризація: які об'єкти створені вручну, хто їх змінював і чим фактичні параметри відрізняються від початкових файлів.
| Стратегія переходу | Коли підходить | Обмеження |
|---|---|---|
| Обв'язка без перенесення | стабільні сервіси без частих правок | залишається дрейф конфігурацій, немає єдиного шаблону |
| Поступове перенесення за сервісами | живий продукт із регулярними релізами | на перехідний період два джерела правди |
| Повне перенесення | невеликий контур або стенд, простій допустимий | вікно простою, ризик втратити нюанси маніфестів |
Поступове перенесення — найпоширеніший варіант для бойового контуру. Чарт описують так, щоб імена об'єктів, мітки селекторів і namespace збігалися з поточними: тоді система приймає наявні ресурси під управління, а не видаляє й створює їх заново.
Перший реліз збирають зі значень, що повторюють фактичні параметри, і лише потім спільні налаштування переїжджають у шаблони та підчарти.
Зворотна сумісність перевіряється до застосування: порівняння відрендерених маніфестів із поточним станом кластера й пробний прогін показують, що саме зміниться.
Окремо фіксується, які поля не можна оновити на живому об'єкті, — їх правлять у вікно обслуговування, а не наосліп під час релізу.
Стратегія переходу закріплюється в самому чарті та в порядку релізів: поки перенесені не всі сервіси, ручні маніфести позначаються замороженими, і правки йдуть лише через репозиторій. Це прибирає дрейф конфігурацій і дає відкат будь-якого сервісу до попередньої ревізії.
Технічні сумніви: питання про чарти й середовища
Інженери рідко сумніваються в самому Helm — питання зазвичай стосуються конкретики: як секрети потрапляють у контури, що відбувається з подами під час оновлення і що залишиться в репозиторії після передавання. Нижче — короткі відповіді щодо кожного з цих місць.
Як секрети й параметри середовищ розносяться за контурами?
Значення секретів у чарті не зберігаються — він посилається на зовнішнє джерело, а самі дані надходять із системи керування секретами.
Відмінності контурів описуються окремими наборами параметрів: тестовий перевизначає залежності та ресурси, робочий — кількість реплік, ліміти й адреси зовнішніх сервісів.
Один чарт обслуговує всі середовища, при цьому доступу до робочого кластера з локальних машин ні в кого немає.
Оновлення пройде без простою і як відкотитися?
Викатка йде стратегією поступового оновлення: нові репліки проходять перевірку готовності перш ніж знімаються старі, а вікно недоступності обмежується бюджетом переривань. Міграції схеми винесені в хуки й виконуються до або після релізу, тому база не ламається на середині.
Кожен реліз зберігається окремою ревізією — відкат — це повернення попередньої версії, а не ручна правка маніфестів.
Як перевіряються шаблони і що з підтримкою після передавання?
Рендер шаблонів і перевірка схеми значень проганяються локально та на збірці, а результат порівнюється з поточним станом кластера — видно, що саме зміниться до застосування. Помилки спливають у гілці, а не в робочому контурі.
Після передавання залишається репозиторій із чартами, наборами значень за контурами, перевірками й описом процесу релізу; обумовлений період ми супроводжуємо, далі зміни випускає ваша команда.
Обговоримо задачу: зберемо схему деплою під ваш кластер
Підготовка до старту починається з інвентаризації сервісів, а не з написання чартів: поки не видно складу застосунків та їхніх залежностей, будь-яка оцінка обсягу буде приблизною.
Щоб обговорити задачу предметно, попросимо мінімум вхідних даних — зазвичай достатньо однієї розмови й доступу до репозиторіїв.
- список сервісів, їхні залежності та те, що зараз розгортається в кластері вручну;
- цільові середовища: скільки їх, чим відрізняються, як перевизначаються значення між ними;
- вимоги до відкату й порядку оновлення — що допустимо перезапускати, а що ні;
- секрети й конфігурації: звідки беруться, хто власник, як потрапляють у кластер;
- стратегія тегування образів, щоб будь-яку версію можна було відтворити й відкотити;
- обмеження кластера: квоти, мережеві політики, сховища, ролі й права доступу;
- точки контролю — хто приймає реліз і за якими ознаками вважає його успішним.
У відповідь повернемо оцінку обсягу, план робіт за етапами й схему деплою: структуру Helm-чартів, розподіл значень за середовищами, порядок міграцій і відкату. Далі йдемо за планом і показуємо результат на першому ж стенді, не чекаючи кінця робіт.
Опишіть вашу задачу — повернемося з оцінкою та планом.
