GitOps Vocabulary: ArgoCD, Flux, and Declarative Deployment Terms (англійською)
Принципи GitOps, ArgoCD, Flux, декларативна інфраструктура, виявлення дрейфу і словник порівняння.
Сучасні команди Kubernetes розробили багатий набір термінів навколо GitOps — спосіб управління інфраструктурою і розгортаннями, де Git є єдиним джерелом правди. Якщо ви приєдналися до команди розробників платформи, почали працювати з ArgoCD або Flux CD, або просто потрапили на вечірку, де люди обговорюють цикли примирення і виявлення дрейфу, цей підручник призначено саме для вас. Нижче ви знайдете визначення найважливіших термінів GitOps простою англійською мовою, приклади реальних розмов і швидку довідкову таблицю, яку можна додати до закладок.
Основні терміни
GitOps — набір практик, де весь бажаний стан системи (програми, інфраструктура, налаштування) зберігається у Git, і автоматизовані інструменти постійно порівнюють цей стан з тим, що насправді працює, виправляючи будь- які відмінності.
«Ми перейшли на GitOps в минулому кварталі — кожна зміна проходить через запит на витяг, тому ми маємо повний аудиторський слід»
«GitOps робить відновлення тривіальними. Ви просто повертаєте затвердження і кластер наздоганяє вас»
** Декларативне налаштування ** — описує * те, як * ви бажаєте, щоб виглядала система, а не * як * досягти цього. Ви пишете файли YAML або JSON, у яких написано « Я хочу три копії цієї служби », і інструменти розпізнають кроки.
“Прекрати писати імперативні сценарії. Давайте перенесем все в декларативну конфігурацію і дамо ArgoCD обробляти решту»
«Красота декларативної конфігурації в тому, що вона є ідемпотентною — ви можете застосувати її сто разів і результат буде таким же.»
** Бажання стану проти фактичного стану ** — * бажаний стан * це те, що, за даними вашого сховища Git, має бути запущено; * фактичний стан * це те, що зараз розгорнуто у кластері. Інструменти GitOps існують для того, щоб закрити прогалини між ними.
“Життєво важливий стан в Git показує дві репліки, але фактичний стан в кластері три. Щось масштабувало його вручну»
«Кожного разу, коли бажаний стан і фактичний стан розходяться, наша інструментація буде його фіксувати і автоматично примирювати»
Визначення і порівняння
** Визначення дрейфу ** — процес постійного моніторингу того, чи не відхилився (не відхилився) фактичний стан кластера від бажаного стану, визначеного у Git. Дрейф може статися, коли хтось робить вручну зміну безпосередньо в кластері, використовуючи kubectl.
“Виявлення дрейфу виявило, що хтось залатав карту конфігурації безпосередньо на вузлі. Це саме те, що GitOps має на меті запобігти»
“Ми отримуємо попередження від Slack в момент виявлення дрейфу. Це зберігає команду чесною — більше немає ковбоїв»
** Цикл примирення ** — це постійний цикл, у якому оператор GitOps (ArgoCD або Flux) читає бажаний стан з Git, порівнює його з фактичним станом кластера і застосовує всі необхідні зміни, щоб вирівняти ці два стани. Цей цикл виконується за налаштованим інтервалом.
“Період примирення запускається за замовчуванням кожні три хвилини. Якщо вам потрібна швидша конвергенція, ви можете зменшити інтервал або викликати вручну синхронізацію.”
«У нас був перерив у сервісі, тому що цикл примирення був призупинений для обслуговування і хтось забуває його знову ввімкнути»
Prune (сиротські ресурси) — автоматичне вилучення ресурсів Kubernetes, які існують у кластері, але більше не визначені в Git. Якщо ви вилучили розгортання зі сховища, обрізання забезпечить вилучення його з кластера, замість того, щоб залишити його у вигляді сироти.
«Ввімкніть обережно обрізання — якщо ресурс випадково вилучено з Git, він буде знищений і в виробництві»
«Ми ввімкнули prune для некритичних просторів імен, щоб спочатку збудувати довіру, перш ніж ввімкнути його в кластері»
Концепція архітектури
ArgoCD — популярний оператор GitOps для Kubernetes, який працює всередині кластера, стежить за одним або декількома сховищами Git і безперервно синхронізує ресурси Kubernetes, щоб вони відповідали стану, описаному в цих сховищах.
«Ми обрали ArgoCD над Flux, тому що веб-інтерфейс робить набагато легше показати зацікавленим сторонам, що розгортається де»
«ArgoCD має вбудований RBAC, який зробив його простим, щоб дати розробникам доступ для читання, не даючи їм викликати синхронізацію»
** Argo Application ** — основний нетиповий ресурс у ArgoCD, який зв’ язує джерело Git (URL сховища, шлях, ревізія) з призначенням Kubernetes (кластер і простір імен). Кожен об’єкт Application вказує ArgoCD точно, що розгортати і де.
«Створити Argo Application, що вказує на папку
prod/paymentsв config repo і націлюватися на простір імен payments на кластері prod.»
«Застосування вийшло з синхронізації після останнього затвердження — виглядає, що хтось відштовхнув безпосередньо до головного без проходження через процес PR»
** Шаблон програм з шаблонами ** — шаблон ArgoCD, де один кореневий Application керує збіркою дочірніх Application манифестів, збережених у Git. Це дозволяє завантажувати і керувати цілим кластером програм через одну точку входу.
«Ми використовуємо шаблон app of apps для кластерного завантаження — одне кореневе застосування, і все інше походить від нього»
Якщо ви хочете встановити нове середовище, просто додайте Application manifest до кореневої теки і ArgoCD підбере його автоматично
** Правила синхронізації (автоматична/ ручна) ** — керує тим, чи буде ArgoCD застосовувати зміни автоматично, коли буде виявлено дрейф (авто), чи чекати на натискання кнопки Синхронізувати або виконання команди argocd app sync (ручна). Ручна синхронізація є поширеною в виробництві для додаткової безпеки.
«Ми зберігаємо політику синхронізації на ручному режимі для prod — автосинхронізація в порядку для стажування, але зміни в виробництві потребують другої пари очей»
«Після інциденту, ми перейшли на вручну синхронізацію політики по всьому борту, поки ми не поліпшимо наш тестовий охоплення.»
** Перевірка стану ** — вбудована (і налаштовувана) оцінка ArgoCD, яка визначає, чи працює розгорнутий ресурс. Розгортання може бути * Синхронізовано * (відповідає Git), але * Погіршено * (поди зриваються). Проверки здоров’я підтверджують це розрізнення.
«Синхронізація зелена, але перевірка стану погіршилася — перевірте журнали піду, щось не працює при запуску»
«Ми написали нестандартну перевірку стану для нашого CRD, щоб ArgoCD міг повідомити про це правильно в панелі управління»
Флюкс-CD і інструменти
** Flux CD ** — оператор GitOps від Cloud Native Computing Foundation (CNCF), який використовує модель, засновану на затягуванні, для підтримки синхронізації кластерів з Git. Flux керується API і тісно інтегрується з Kustomize і Helm.
«Наша команда платформи стандартизувала Flux, тому що вона природно вписується в наш існуючий робочий процес Kustomize»
«Flux повідомляє нас через webhook, коли примирення успішно або невдало — він підключається прямо в наш попереджаючий конвеєр»
** Розгортання на основі витягування ** — модель розгортання, де агент, що виконується всередині кластера, витягує налаштування з Git, замість того, щоб мати зовнішній конвеєр CI, який витягує зміни в кластер. Це вважається більш безпечним, оскільки кластер не повинен показувати свій сервер API зовні.
«Пулл-базоване розгортання означає, що наш CI-сервер ніколи не потребує кластерних даних — агент Flux обробляє все зсередини»
«Безпека сподобалася моделі, заснованої на pull, тому що вона значно зменшує поверхню атаки в порівнянні з трубопроводами, заснованими на push»
** Налаштування накладання** — функція Налаштування, яка надає вам змогу визначити базовий набір манифестів Kubernetes, а потім накладати на них шар латів, специфічних для середовища (накладень), без дублювання базових файлів. Загальне зображення: одна основа, плюс накладки для dev, staging, і prod.
«Прод-накладка просто змінює кількість реплік і обмеження ресурсів — все інше успадковується від бази»
«Ми мали помилку в накладці Kustomize, яка додавала неправильну змінну середовища до prod. Розбіжність у PR впіймав би це.»
** Helm release ** — у Flux (і ArgoCD) HelmRelease є нетиповим ресурсом, який описує розгортання діаграми Helm — яку діаграму, яку версію і які значення передавати. Оператор GitOps керує повним життєвим циклом випуску Helm декларативно.
«Бумп версію карти в HelmRelease манифесті і відкрити PR — Flux буде управляти оновленням, як тільки він з’єднається.»
«Ми прикріплюємо версії чартів в HelmRelease, тому новий випуск не потрапляє в виробництво без перегляду»
Як використовувати їх у розмові
Сценарий 1 - обновление в стоячем положении
“Услуга оплати HelmRelease показується як погіршена в ArgoCD. Проверка здоров’я показує, що зонд готовності не працює. Я зараз розслідую — це може бути конфігурація в просвіті»
** Сценарій 2 — обговорення архітектури **
«Чи слід використовувати автоматичну синхронізацію на prod? Я краще залишу цю функцію ручною і вимагатиму явної синхронізації після кожного об’ єднання PR. Попередження про випадкове виявлення дрейфу в порядку, але автоматичне усунення у виробництві робить мене нервовим»
Сценарий 3 - ретроспектива инцидента
«Корінь причиною був вручну дрейф — хтось залатав репліки рахунок безпосередньо через kubectl під час інциденту без оновлення Git. Цикл примирення виправив його через двадцять хвилин, що спричинило другий несподіваний перезапуск. В подальшому, ми вмикаємо обрізку і блокуємо прямий доступ до кластера»
** Сценарій 4 — впровадження нової служби **
« Додати новий манифест Argo Application до теки
apps/у сховищі конфігурацій. Використовувати шаблон програми з програм — коренева програма автоматично його вибере. Наведіть його на шляхservices/new-billingі встановіть наразі політику синхронізації на вручну»
Краткий справочник
| Term | What it means |
|---|---|
| GitOps | Git as the single source of truth for cluster state |
| Declarative configuration | Describe what you want, not how to achieve it |
| Desired state | What Git says should be running |
| Actual state | What is currently running in the cluster |
| Drift detection | Spotting gaps between desired and actual state |
| Reconciliation loop | Automated cycle that closes the gap between states |
| ArgoCD | GitOps operator with a UI; syncs Git to cluster |
| Flux CD | CNCF GitOps operator; pull-based, Kustomize/Helm native |
| Sync policy | Auto or manual trigger for applying Git changes |
| Prune | Delete cluster resources removed from Git |