CRD для Kubernetes: розробка та впровадження під ключ

Розробка CRD для Kubernetes: де ламається автоматизація

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

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

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

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

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

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

Ми розбираємо, як розробка CRD у Kubernetes перетворюється з джерела ручної роботи на передбачуваний механізм: які точки відмови закриваються схемою та політикою доступу, які — ідемпотентністю керівного компонента, а які — порядком застосування об’єктів.

Що змінюється після впровадження кастомних ресурсів

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

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

• Час виведення змін. Правка опису ресурсу застосовується за один прохід — хвилини замість узгодженого вікна та ручної послідовності з кількох служб.
• Частка ручних операцій. Типові дії — видача доступів, ротація секретів, масштабування, оновлення конфігурації — переходять до оператора; в інженера залишається лише те, що потребує рішення.
• Усунений клас відмов. Розсинхронізація між «що описано» та «що реально працює»: після збою вузла або ручного втручання оператор повертає об’єкт до заданого стану без ручного розбору.
• Час відновлення після збою. Відкат — це повернення попереднього опису ресурсу, а не відтворення ланцюжка команд із пам’яті; результат не залежить від того, хто зараз на чергуванні.
• Узгодженість стану. Пов’язані об’єкти читають одну точку правди: зміни проходять перевірку й застосовуються цілком, а не половиною набору.

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

Способи розширення кластера: порівняння підходів

Розширювати кластер можна трьома способами, і вибирають між ними не за смаком, а за наявністю власної логіки життєвого циклу в об’єкта.

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

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

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

Етапи впровадження кастомного ресурсу в кластер

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

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

1. Аудит кластера. Інвентаризація наявних кастомних ресурсів, контролерів і прив’язок прав: що вже оголошено, з чим новий ресурс може конфліктувати за групою API та іменами.
2. Схема ресурсу. Узгоджуємо поля специфікації та статусу, правила валідації, версії API і стратегію їх зміни. Результат фіксуємо маніфестами в репозиторії.
3. Реалізація контролера. Логіка узгодження стану, повторні спроби, вибір провідної репліки за кількох копій, окремий статусний підресурс — щоб оновлення статусу не конфліктувало зі специфікацією.
4. Права та ізоляція. Ролі, прив’язки й облікові записи з мінімально необхідним набором прав; перевіряємо, що контролер не може вийти за їхні межі.
5. Перевірка на навантаженні. Прогін на стенді, близькому до продакшну: масове створення об’єктів, відмова вузла, перезапуск контролера, недоступність зовнішньої системи. Дивимося час узгодження та відсутність дублів.
6. Викат і передача в експлуатацію. Спочатку частина просторів імен під наглядом метрик, потім весь кластер. Далі — документація зі схеми та прав, розбір типових збоїв, навчання команди: додавати поля й версії вона зможе сама.

Що передаємо на руки: конфігурації, схеми, регламенти

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

• Описи схем ресурсів. Визначення CRD з валідацією полів, значеннями за замовчуванням і версіонуванням: некоректний об’єкт відхиляється на вході, а не спливає через годину в роботі кластера.
• Конфігурація розгортання. Маніфести контролера, набори правил, ресурси й ліміти, розподіл за контурами — тестовим, передпродуктивним, продуктивним. Джерело одне, значення відрізняються.
• Політики доступу. Ролі та прив’язки: що може читати й змінювати кожен сервіс, які права в чергового інженера, хто взагалі має право правити самі визначення ресурсів.
• Регламент відкату. Як повернути попередню ревізію визначення і що при цьому відбувається з уже створеними об’єктами — окремо для сумісних і несумісних змін.
• Порядок оновлення схем. Правило, за яким нова версія додається поруч зі старою, та умова, за якої стара знімається без втрати об’єктів.
• Інструкції для чергової зміни. Типові сигнали, до чого вони ведуть, що безпечно зробити на місці й у який момент підключати розробника.
• Документація на рішення. Схема взаємодії компонентів, точки відмови, відомі обмеження та приклади об’єктів під часті задачі вашої команди.

Кожен пункт перевіряється на демонстраційному контурі: ви проганяєте оновлення й відкат своїми руками до того, як рішення йде в продакшн.

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

До: стан жив у руках чергового

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

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

Що перенесли в ресурс і контролер

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

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

Що змінилося

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

Чим відрізняється CRD від оператора і де межа

CRD розширює API-сервер новою схемою: поля ресурсу, типи, обов’язковість, значення за замовчуванням, правила валідації. Це контракт і запис у сховищі, але не логіка.

Сам по собі CRD нічого не робить — створений об’єкт просто лежить, і ніхто не звіряє реальність із тим, що в ньому написано.

Керування станом з’являється, коли поряд зі схемою працює контролер. Він підписується на події та крутить цикл узгодження: читає бажаний стан із spec, зіставляє зі спостережуваним у status і робить кроки, щоб їх звести.

Ключова вимога — ідемпотентність: повторний прохід дає той самий результат, а не створює другу сутність замість першої.

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

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

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

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

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

Часті технічні сумніви перед стартом робіт

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

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

Що буде з уже створеними об’єктами?

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

Як розмежовується доступ?

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

Що робити, якщо після оновлення щось зламалося?

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

Обговоримо задачу: що потрібно для точної оцінки

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

• Склад кластерів: скільки середовищ (розробка, тест, продакшн), яка гілка Kubernetes використовується, чи є окремий контур під навантаження.
• Що вже є: власні контролери, готові CRD, самописні скрипти — що перевикористовуємо, а що акуратно виводимо з роботи.
• Вимоги до поведінки: які об’єкти створюємо, які поля валідуємо, як обробляємо конфлікти і що має відбуватися під час відкату.
• Доступи та межі: хто видає права в кластерах, чи є закритий контур без виходу назовні, як узгоджуються зміни політик.
• Перевірки: які сценарії обов’язкові до викату, чи потрібні автотести маніфестів і прогін на стенді, близькому до продакшну.
• Строки та порядок старту: до якої дати потрібен робочий контур, які зовнішні залежності та коли зміни допустимі.

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