Налаштування ArgoCD і GitOps у Kubernetes: практичний посібник

ArgoCD без GitOps: чому стан кластера розходиться з репозиторієм

Часто ArgoCD потрапляє в кластер як зручна панель стану: видно, що розгорнуто, видно розходження, але зміни, як і раніше, вносять руками. Під час розбору інциденту хтось піднімає кількість реплік, розширює ліміти або підміняє образ прямо в кластері — «тимчасово, щоб швидше». Патч залишається в живому стані, а в репозиторії про нього ніхто не пам'ятає.

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

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

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

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

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

Що дає керована доставка: швидкість, відкат і передбачуваність

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

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

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

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

Історія змін перестає бути усною. У кожної правки є автор, причина та зв'язок із задачею, а відкат залишає такий самий явний слід.

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

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

ArgoCD у такій схемі лише виконує зафіксоване в репозиторії — тому стан середовища відтворюваний, а не відновлюється з пам'яті. Саме ці показники ми знімаємо на прийманні: час відкату, частку успішних викаток і кількість ручних операцій на реліз.

Режими доставки змін: синхронізація з репозиторію та альтернативи

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

У ArgoCD це дві незалежні налаштування — автосинхронізація та самовідновлення, і їхні комбінації дають різні моделі доставки.

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

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

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

Як відбувається впровадження: від розбору кластера до передачі регламентів

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

1. Інвентаризація кластера. Збираємо робочі навантаження, простори імен, прив'язки ролей і ручні правки через kubectl. Фіксуємо розходження між маніфестами та живим станом — це і є реальний обсяг робіт.
2. Схема репозиторіїв. Розділяємо конфігурацію застосунків і середовищ, задаємо структуру каталогів і межі відповідальності команд. Від неї залежить, скільки ручних погоджень залишиться під час кожної викатки.
3. Налаштування синхронізації. Підключаємо ArgoCD, описуємо Application і AppProject, вмикаємо автосинхронізацію та відновлення стану після ручних правок. Секрети йдуть у Git лише в зашифрованому вигляді.
4. Перевірка політик. Обмежуємо проєктами доступні простори імен і типи ресурсів, вмикаємо валідацію маніфестів на рев'ю. Помилка конфігурації виявляється до потрапляння в кластер.
5. Тестова викатка. Проганяємо реліз на стенді, потім на некритичному сервісі в проді: дивимося час синхронізації та поведінку під час відкату. Відкат перевіряємо поверненням коміту, а не ручними командами.
6. Передача в супровід. Віддаємо регламенти, описуємо ролі та доступи, показуємо черговому, як читати статус синхронізації та що робити при завислому релізі.

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

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

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

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

• Маніфести та конфігурації — описи застосунків і наборів застосунків із політикою синхронізації: автосинхронізація, відновлення після ручних правок у кластері, видалення ресурсів, яких більше немає в Git. Єдине джерело правди — репозиторій, а не живий кластер.
• Рольова модель і політики доступу — проєкти з обмеженням за репозиторіями, просторами імен і типами ресурсів; зв'язка з єдиним входом і групами, окреме право на синхронізацію в продакшн.
• Схема середовищ — карта розробки, передпродакшну й продакшну: які гілки та оверлеї їм відповідають, у якому порядку йде викладка і де конфігурації розходяться усвідомлено.
• Регламент релізу — покроковий порядок: рев'ю зміни, злиття, синхронізація, перевірка здоров'я сервісів, рішення про відкат і фіксація результату.
• Робота із секретами — де зберігаються облікові дані, чим розшифровуються всередині кластера, у кого є доступ і як проходить ротація ключів.
• Інструкції для чергових — що дивитися при розходженні стану, як відрізнити збій викладки від збою застосунку, типові дії та порядок ескалації.
• Схеми й документація — діаграма потоку змін від коміту до кластера, карта репозиторіїв і чек-ліст підключення нового сервісу.

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

Кейс: ArgoCD зняв ручні деплої в кластері з 40 сервісів

До впровадження GitOps кластер на 40 сервісів жив на ручних викатках: інженер збирав образ, правил маніфести прямо в кластері та застосовував їх через командний рядок.

Стан середовища ніхто не міг відтворити — описи розходилися з тим, що реально працювало, а правки «на хвилину» осідали в кластері назавжди.

Перенесли всі описи в Git і віддали синхронізацію Argo CD: репозиторій став єдиним джерелом правди, а розходження між ним і кластером — видимим і усувним.

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

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

Відкат тепер — не окрема операція під тиском, а повернення попереднього коміту: контролер сам приводить кластер до потрібного стану.

Розбір інциденту змістився з питання «що там накрутили руками» на роботу зі зрозумілою різницею версій, а історія змін по кожному сервісу залишилася в репозиторії.

Чим відрізняється ArgoCD від самописного конвеєра доставки?

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

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

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

Супровід конвеєра при цьому зміщується з коду в правила, ролі та історію змін репозиторію. Далі показуємо, як це виглядає в роботі.

Питання щодо доступів, середовищ і вже працюючих кластерів

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

Як ізолювати контури розробки, тестування та продуктивний?

Розділяємо екземплярами або проєктами з обмеженням за просторами імен. Продуктивний контур відрізняється обов'язковим ручним підтвердженням синхронізації та забороною на автозастосування із загальної гілки.

Чи підключиться вже працюючий кластер?

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

Що з планом відкату?

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

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

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

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

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

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

Натомість надсилаємо не загальні міркування, а робочий комплект:

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

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