Модуль 4.1: Основи CI/CD

Складність: [СЕРЕДНЯ] — концепції доставки

Час на проходження: 55–70 хвилин

Передумови: Частина 3 (Хмарна архітектура), базова робота з Git та концепції робочих навантажень Kubernetes для версії 1.35+

Результати навчання

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

1. Порівнювати Continuous Integration, Continuous Delivery та Continuous Deployment і обирати модель контролю над релізами для сервісу.
2. Проєктувати конвеєр CI/CD для Kubernetes, який збирає, тестує, пакує, зберігає та розгортає образи контейнерів.
3. Оцінювати інструменти CI/CD, зокрема Jenkins, GitHub Actions, GitLab CI, Tekton, Argo CD, Flux та Argo Workflows, з огляду на обмеження команди.
4. Діагностувати збої GitOps, реєстру та стратегій розгортання, відстежуючи облікові дані, теги образів, сигнали розгортання та шляхи відкату.

Чому цей модуль важливий

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

Урок не в тому, що CI/CD якимось чином запобігає кожному збою. Урок у тому, що дисципліна доставки визначає, наскільки швидко команда може перетворити відоме виправлення на безпечну зміну в продакшені. Якщо шлях від коміту до кластера є ручним, неузгодженим або залежить від одного експерта, кожна термінова зміна стає особливою подією. Якщо ж шлях автоматизований, спостережуваний і зворотний, команда може зосередитися на справжньому ризику: чи поводиться нова версія коректно в умовах продакшену. KCNA включає CI/CD, тому що хмарні операції припускають, що зміни в програмному забезпеченні є частими, контейнеризованими та узгоджуються через декларативні системи, а не копіюються вручну на довговічні машини.

Цей модуль навчає CI/CD як операційної моделі для застосунків Kubernetes. Ви порівняєте Continuous Integration, Continuous Delivery та Continuous Deployment, а потім спроєктуєте етапи конвеєра, що переміщують код із Git до реєстру контейнерів і нарешті в кластер. Ви також оціните поширені інструменти, поясните, чому GitOps змінює модель безпеки, і діагностуватимете збої стратегій розгортання, спостерігаючи за тими самими сигналами, які використовують команди продакшену: теги образів, статус розгортання, метрики справності та шляхи відкату. Мета — практична розважливість, а не фанатизм щодо інструментів.

Що CI/CD насправді обіцяє

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

Читайте цей огляд згори донизу як рух від зворотного зв’язку до готовності й нарешті до автоматичної зміни в продакшені. Словник має значення для KCNA, бо сценарій може описувати команду, яка може розгорнути будь-яку успішну збірку, але все ж використовує ручне погодження, — і це Continuous Delivery, а не Continuous Deployment. Той самий сценарій може описувати автоматичне розгортання в продакшен після кожного злиття, що піднімає планку для покриття тестами, поступового впливу та моніторингу.

┌─────────────────────────────────────────────────────────────┐
│              CI/CD OVERVIEW                                 │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  CONTINUOUS INTEGRATION (CI)                               │
│  ─────────────────────────────────────────────────────────  │
│  Frequently merge code changes into a shared repository   │
│  Automatically build and test each change                 │
│                                                             │
│  Code → Build → Test → Merge                              │
│                                                             │
│  CONTINUOUS DELIVERY (CD)                                 │
│  ─────────────────────────────────────────────────────────  │
│  Automatically prepare code for release to production     │
│  Deployment is manual (button click)                      │
│                                                             │
│  CI → Package → Stage → [Manual Deploy]                  │
│                                                             │
│  CONTINUOUS DEPLOYMENT (CD)                               │
│  ─────────────────────────────────────────────────────────  │
│  Automatically deploy every change to production         │
│  No manual intervention                                   │
│                                                             │
│  The difference:                                          │
│  • Continuous Delivery: CAN deploy at any time           │
│  • Continuous Deployment: DOES deploy automatically      │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Думайте про CI як про димову сигналізацію в майстерні. Вона не випускає продукт, але швидко повідомляє вам, коли нова деталь більше не пасує до решти механізму. Continuous Delivery — це спакований та перевірений відвантажувальний док: продукт готовий, маркований і чекає на свідоме рішення про випуск. Continuous Deployment — це конвеєрна стрічка, під’єднана безпосередньо до вантажівок на виїзд. Така стрічка може бути чудовою, коли контроль якості сильний, але вона безрозсудна, коли команда все ще виявляє більшість збоїв уже після клієнтів.

Зупиніться й передбачте: Continuous Delivery означає, що код завжди готовий до розгортання за ручним тригером, тоді як Continuous Deployment означає, що кожна успішна зміна розгортається автоматично. Яку модель ви обрали б для сервісу, що обробляє повернення коштів, і яким сигналам збоїв треба було б довіряти, перш ніж ви прибрали б ручне погодження?

Чим автоматичнішим стає рішення про реліз, тим більше конвеєр має кодувати людську розважливість. Команда, що практикує Continuous Delivery, все ще може призупинити реліз, бо менеджер продукту знає, що за дві години починається подія з високим трафіком. Команді, що практикує Continuous Deployment, потрібні автоматичні правила, які виявляють той самий клас небезпеки, як-от підвищений рівень помилок, провалені синтетичні перевірки або падіння успішності платежів під час канаркового впливу. Автоматизація — це не відсутність розважливості; це розважливість, перетворена на повторювані перевірки.

Питання KCNA зазвичай лишаються концептуальними, але реальність продакшену конкретна. Зміна, що проходить модульні тести, все ж може провалитися, бо образ контейнера був зібраний для хибної архітектури, тег у реєстрі вказує на застарілий дайджест, Деплоймент Kubernetes так і не став доступним, або міграція бази даних виявилася несумісною зі зворотним напрямком. CI/CD зменшує ці ризики, роблячи кожен етап явним і придатним до аудиту. Коли стається інцидент, команда може запитати, який етап мав упіймати проблему, і покращити цей етап, а не звинувачувати людину, яка натиснула «розгорнути».

Найбільше непорозуміння — вважати, що CI/CD передусім є вправою з вибору продукту. Jenkins, GitHub Actions, GitLab CI, Tekton, Argo CD та Flux усі можуть підтримувати доставку, але жоден із них не виправляє нечітку політику релізів. Перш ніж обирати інструмент, вирішіть, де код переглядають, які тести блокують просування, де зберігаються образи, як змінюються маніфести, хто може погоджувати продакшен і як виконується відкат. Інструменти роблять ці рішення виконуваними; вони не замінюють їх.

Проєктування конвеєра від Git до кластера

Конвеєр CI/CD для Kubernetes — це ланцюг доказів. Кожен етап відповідає на питання, яке наступному етапу вже не доведеться ставити знову. Контроль версій відповідає на те, що змінилося і хто це переглянув. Збірка відповідає на те, чи можна повторювано виготовити застосунок та образ контейнера. Тестування відповідає на те, чи поводиться новий артефакт достатньо добре, щоб продовжити. Пакування відповідає на те, чи доступні незмінний артефакт і придатні до розгортання маніфести. Розгортання відповідає на те, чи зійшовся кластер до бажаного стану і чи здорові користувачі після того, як трафік досягає нової версії.

Ця діаграма конвеєра показує, що CI/CD — це більше, ніж одна команда розгортання. Зверніть увагу, що етап пакування стоїть між тестуванням і розгортанням. У контейнеризованій доставці саме на цьому етапі конвеєр відправляє образ до реєстру й часто оновлює Helm-чарт, оверлей Kustomize або сирий маніфест. Kubernetes не збирає за вас код застосунку. Він планує контейнери з образів, що вже існують, а це означає, що конвеєр доставки має створити й зберегти ці образи, перш ніж кластер зможе їх запустити.

┌─────────────────────────────────────────────────────────────┐
│              CI/CD PIPELINE                                 │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Code                                                      │
│    │                                                       │
│    ▼                                                       │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  1. SOURCE                                          │   │
│  │     Developer commits code to Git                   │   │
│  │     Triggers pipeline                               │   │
│  └─────────────────────────────────────────────────────┘   │
│    │                                                       │
│    ▼                                                       │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  2. BUILD                                           │   │
│  │     Compile code, resolve dependencies             │   │
│  │     Create container image                          │   │
│  └─────────────────────────────────────────────────────┘   │
│    │                                                       │
│    ▼                                                       │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  3. TEST                                            │   │
│  │     Unit tests, integration tests                   │   │
│  │     Security scans, linting                         │   │
│  └─────────────────────────────────────────────────────┘   │
│    │                                                       │
│    ▼                                                       │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  4. PACKAGE                                         │   │
│  │     Push container image to registry               │   │
│  │     Create Helm chart/manifests                    │   │
│  └─────────────────────────────────────────────────────┘   │
│    │                                                       │
│    ▼                                                       │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  5. DEPLOY                                          │   │
│  │     Deploy to staging/production                    │   │
│  │     Run smoke tests                                 │   │
│  └─────────────────────────────────────────────────────┘   │
│    │                                                       │
│    ▼                                                       │
│  Production                                                │
│                                                             │
└─────────────────────────────────────────────────────────────┘

На етапі джерела Git не є просто сховищем файлів. Це межа перегляду, запис для аудиту й точка запуску автоматизації. Pull request може вимагати перегляду коду, підписаних комітів, перевірок статусу та захисту гілки, перш ніж зміна досягне основної гілки. Ці засоби контролю є частиною CI/CD, бо вони вирішують, чи дозволено автоматизації витрачати обчислювальні ресурси на кандидатну зміну й чи слід довіряти отриманому артефакту. Для KCNA пов’яжіть Git із бажаним станом і придатністю до аудиту, особливо коли пізніше порівнюватимете розгортання за моделлю «push» із GitOps.

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

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

Перш ніж подумки це програти, передбачте, який етап має провалитися, якщо Деплоймент посилається на ghcr.io/example/api:latest, але реєстр тепер віддає інший образ, ніж учора. Збірка могла бути успішною, а тести могли пройти проти первісного артефакту, але шлях пакування й розгортання втратив незмінність. Сильний конвеєр записує дайджест образу, оновлює маніфести цим дайджестом або унікальним тегом версії й дає Kubernetes завантажити саме той артефакт, що пройшов перевірку. Змінні теги зручні для демонстрацій; у продакшені вони є небезпечним доказом.

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

┌─────────────────────────────────────────────────────────────┐
│              CONTAINER REGISTRIES                           │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Where container images are stored                        │
│                                                             │
│  CI builds image → Push to registry → K8s pulls image    │
│                                                             │
│  Public registries:                                       │
│  ─────────────────────────────────────────────────────────  │
│  • Docker Hub (docker.io)                                │
│  • GitHub Container Registry (ghcr.io)                   │
│  • Google Container Registry (gcr.io, legacy; now served via Artifact Registry) │
│  • Quay.io                                               │
│                                                             │
│  Private registries:                                      │
│  ─────────────────────────────────────────────────────────  │
│  • Harbor (CNCF Graduated)                               │
│  • AWS ECR                                               │
│  • Azure ACR                                             │
│  • Google Artifact Registry                              │
│                                                             │
│  Harbor features:                                         │
│  • Vulnerability scanning                                 │
│  • Image signing                                          │
│  • Role-based access                                      │
│  • Replication                                            │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Розгортання в Kubernetes має перевіряти узгодження стану, а не просто подавати YAML. Команда або контролер можуть успішно створити об’єкт Деплоймент навіть тоді, коли новий ReplicaSet так і не став доступним. Помилки завантаження образу, провалені проби готовності, нестача ресурсів і зламана конфігурація можуть з’явитися вже після того, як API-сервер прийме бажаний стан. Саме тому людина-оператор або автоматичний контролер має спостерігати за статусом розгортання, подіями, готовністю Подів і метриками застосунку. З поширеним псевдонімом alias k=kubectl той, хто вчиться, може читати приклади на кшталт k rollout status deployment/web та k get pods -l app=web як перевірки Kubernetes, а не як загальні команди оболонки.

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

┌─────────────────────────────────────────────────────────────┐
│              CI/CD BENEFITS                                 │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  WITHOUT CI/CD:                                            │
│  ─────────────────────────────────────────────────────────  │
│  • Manual builds ("works on my machine")                  │
│  • Infrequent releases (big bang)                        │
│  • Manual testing (error-prone)                          │
│  • Long feedback loops                                    │
│  • Risky deployments                                      │
│                                                             │
│  WITH CI/CD:                                              │
│  ─────────────────────────────────────────────────────────  │
│  • Automated builds (reproducible)                       │
│  • Frequent releases (small changes)                     │
│  • Automated testing (consistent)                        │
│  • Fast feedback (minutes, not days)                     │
│  • Safe deployments (rollback ready)                     │
│                                                             │
│  Key metrics:                                              │
│  ─────────────────────────────────────────────────────────  │
│  • Deployment frequency (how often)                       │
│  • Lead time (commit to production)                       │
│  • Change failure rate (% that cause issues)             │
│  • Mean time to recovery (fix production issues)         │
│                                                             │
└─────────────────────────────────────────────────────────────┘

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

Оцінювання інструментів CI/CD та доставки, нативної для Kubernetes

Інструменти CI/CD різняться менше за тим, чи можуть вони виконувати команди оболонки, і більше за тим, де живе їхня площина управління, як вони керують обліковими даними, як вони моделюють робочі процеси та наскільки добре вони вписуються в роботу команди з контролем версій і кластерами. Jenkins глибоко налаштовуваний і поширений у довговічних підприємствах, але потребує операційної турботи, бо плагіни, доступність контролера та зберігання облікових даних стають частиною платформи. GitHub Actions та GitLab CI живуть близько до робочих процесів репозиторію, що зменшує тертя на старті для команд, які вже використовують ці платформи. Tekton моделює конвеєри як ресурси Kubernetes, що робить його привабливим, коли команда платформи хоче, щоб примітиви доставки виконувалися всередині самого API кластера.

Інструмент	Опис
Jenkins	Самостійно розгорнутий, дуже налаштовуваний
GitHub Actions	Вбудований у GitHub
GitLab CI	Вбудований у GitLab
CircleCI	Хмарний CI/CD
Travis CI	Простий CI/CD

Ця таблиця інструментів навмисно коротка, тож сприймайте її як стартову карту, а не як путівник із купівлі. Порівняння рівня KCNA має ставити операційні питання: де виконується ранер, як зберігаються секрети, що запускає конвеєр, як інструмент автентифікується в реєстрі та чи має інструмент розмовляти безпосередньо з кластером. Стартап із більшістю коду в GitHub може обрати GitHub Actions для CI, бо перевірки pull request там природні. Регульоване підприємство з роками спільних бібліотек конвеєрів може лишити Jenkins, посилюючи межі облікових даних. Група платформної інженерії може обрати Tekton, бо нативні для Kubernetes завдання можна пакувати й повторно використовувати між орендарями.

CI/CD, нативний для Kubernetes, додає другу категорію інструментів. Tekton збирає й запускає завдання конвеєра як власні ресурси Kubernetes. Argo CD та Flux безперервно узгоджують декларований бажаний стан із Git у кластери. Argo Workflows запускає спрямовані робочі процеси на Kubernetes і може підтримувати навантаження CI/CD або обробки даних. Ці інструменти не однакові, і KCNA очікує, що ви відрізнятимете автоматизацію збірки від узгодження GitOps. Tekton може збирати й тестувати; Argo CD та Flux зазвичай розгортають бажаний стан; Argo Workflows оркеструє ширші графи робочих процесів.

┌─────────────────────────────────────────────────────────────┐
│              KUBERNETES-NATIVE CI/CD                        │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  TEKTON (CNCF Incubating)                                 │
│  ─────────────────────────────────────────────────────────  │
│  • CI/CD as Kubernetes resources                          │
│  • Tasks, Pipelines, PipelineRuns                        │
│  • Cloud-native, serverless                               │
│                                                             │
│  ARGO CD (CNCF Graduated)                                 │
│  ─────────────────────────────────────────────────────────  │
│  • GitOps continuous delivery                             │
│  • Declarative, Git as source of truth                   │
│  • Sync cluster state with Git                           │
│                                                             │
│  FLUX (CNCF Graduated)                                    │
│  ─────────────────────────────────────────────────────────  │
│  • GitOps continuous delivery                             │
│  • Similar to Argo CD                                     │
│  • Tight Helm integration                                │
│                                                             │
│  ARGO WORKFLOWS (CNCF Graduated)                          │
│  ─────────────────────────────────────────────────────────  │
│  • Workflow engine for Kubernetes                        │
│  • DAG-based workflows                                    │
│  • CI/CD and data pipelines                              │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Рішення щодо інструмента має слідувати за межею доставки. Якщо ваша система CI збирає образи й безпосередньо застосовує маніфести з обліковими даними адміністратора кластера, вона сидить по обидва боки межі. Це може бути прийнятним у невеликій лабораторії, але збільшує радіус ураження в продакшені, бо скомпрометований акаунт CI може миттєво змінити кластер. Якщо CI збирає образ і відкриває pull request проти репозиторію розгортання, тоді як контролер GitOps усередині кластера завантажує погоджений бажаний стан, межа вужча. Системі CI потрібні дозволи на реєстр і Git; влада записувати в кластер лишається у внутрішнього контролера.

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

Оцінка інструмента включає також поведінку під час збоїв. Збій розміщеного ранера CI не повинен лишати продакшен у стані постійних дивних мутацій. Самостійно розгорнутий контролер Jenkins слід резервувати, бо його визначення завдань, облікові дані та стан плагінів можуть бути критичними. Кластер Tekton має мати квоти ресурсів, щоб одна команда не змогла виснажити спільні воркери. Контролер Argo CD або Flux має оприлюднювати справність узгодження, щоб оператори бачили дрейф, збої автентифікації або недійсні маніфести. Зрілі команди доставки не питають, чи може інструмент розгорнути; вони питають, як він зазнає збою і наскільки швидко цей збій стає видимим.

KCNA не вимагатиме повної матриці порівняння постачальників, але може запитати, яка категорія інструментів пасує до описаної моделі. Якщо сценарій каже, що конвеєри є власними ресурсами Kubernetes із Tasks і PipelineRuns, думайте про Tekton. Якщо він каже, що кластер безперервно синхронізується з Git і трактує Git як джерело істини, думайте про Argo CD або Flux. Якщо він каже, що розміщений у репозиторії робочий процес збирає образи на pull request, думайте про GitHub Actions або GitLab CI залежно від платформи. Якщо він каже, що сильно налаштований самостійно розгорнутий сервер автоматизації виконує багато застарілих завдань, Jenkins — імовірний збіг.

GitOps та межа безпеки

Традиційний CI/CD часто використовує модель «push»: зовнішня система збирає або пакує реліз, а потім надсилає зміни безпосередньо в кластер. GitOps використовує модель «pull»: контролер, що працює в кластері або поруч із ним, спостерігає за Git і узгоджує кластер у напрямку бажаного стану, що зберігається там. Різниця здається малою, доки ви не проаналізуєте облікові дані. У моделі «push» серверу CI потрібні облікові дані, що можуть змінювати кластер. У моделі «pull» контролер усередині кластера володіє дозволами на кластер, а зовнішня автоматизація зазвичай змінює Git, а не викликає API Kubernetes безпосередньо.

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

┌─────────────────────────────────────────────────────────────┐
│              GITOPS vs TRADITIONAL CI/CD                    │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  TRADITIONAL (Push-based):                                │
│  ─────────────────────────────────────────────────────────  │
│                                                             │
│  Git → CI Server → Push to Cluster                        │
│                                                             │
│  ┌──────┐    ┌─────────┐    ┌─────────────┐              │
│  │ Git  │ →  │   CI    │ →  │  Cluster    │              │
│  │      │    │ Server  │    │             │              │
│  └──────┘    └─────────┘    └─────────────┘              │
│                                                             │
│  • CI needs cluster credentials                           │
│  • External system pushes changes                         │
│                                                             │
│  GITOPS (Pull-based):                                     │
│  ─────────────────────────────────────────────────────────  │
│                                                             │
│  Git ← Pull from Cluster                                  │
│                                                             │
│  ┌──────┐              ┌─────────────┐                    │
│  │ Git  │ ←────────── │  Cluster    │                    │
│  │      │   agent     │  (Argo CD)  │                    │
│  └──────┘   pulls     └─────────────┘                    │
│                                                             │
│  • Cluster pulls from Git                                 │
│  • No external access needed                              │
│  • Git = source of truth                                 │
│                                                             │
└─────────────────────────────────────────────────────────────┘

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

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

Модель «pull» покращує безпеку, але вона ставить нові операційні питання. Контролеру потрібен доступ на читання до Git, доступ на запис до ресурсів Kubernetes, якими він керує, і часто дозвіл читати Helm-чарти, оверлеї Kustomize або приватні реєстри. Якщо контролер має дозволи на рівні всього кластера для кожного простору імен, він усе одно може стати потужною ціллю. Добре спроєктована інсталяція GitOps обмежує область дії контролерів, сервісних акаунтів, проєктів, просторів імен і доступу до репозиторіїв, щоб команди могли розгортати те, чим володіють, не змінюючи все інше в кластері.

GitOps також змінює те, як оператори діагностують інциденти. Якщо розробник запускає k edit deployment web під час надзвичайної ситуації, живий кластер може тимчасово відновитися, але контролер пізніше може повернути ручну правку назад, бо Git досі каже щось інше. Це не помилка; це узгодження виконує свою роботу. Тривале виправлення належить Git, якщо тільки команда навмисно не призупиняє узгодження для контрольованої процедури «розбити скло». Сценарії KCNA часто перевіряють цю ментальну модель: бажаний стан живе в Git, живий стан має до нього зійтися, а ручний дрейф є тимчасовим, доки його не зафіксовано комітом.

GitOps найсильніший, коли бажаний стан є декларативним і придатним до перегляду. Kubernetes пасує до цієї моделі, бо Деплойменти, Сервіси, ConfigMap, ресурси Ingress і багато власних ресурсів є об’єктами API з бажаними специфікаціями. Деякі завдання доставки вписуються не так гладко, особливо одноразові міграції бази даних, конфігурація зовнішніх SaaS або імперативні скрипти, що мають виконатися рівно один раз. Команди часто поєднують GitOps з окремою оркестрацією завдань або інструментами міграції, а не вдають, що кожне питання релізу є лише відмінністю в YAML.

Стратегії розгортання та докази розкочування

Щойно артефакт і бажаний стан готові, системі доставки все ще треба показати користувачам нову версію. Деплойменти Kubernetes за замовчуванням використовують поетапні оновлення (rolling updates), які поступово замінюють старі Поди новими, дотримуючись обмежень доступності. Поетапні оновлення прості й ресурсоефективні, але вони можуть змішувати старі й нові версії під час розкочування. Розгортання blue-green запускає два повні середовища або набори навантажень і перемикає трафік, коли нове готове. Канаркове розгортання надсилає невелику частку трафіку до нової версії, спостерігає за реальними сигналами й просуває її лише тоді, коли канарка поводиться добре.

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

┌─────────────────────────────────────────────────────────────┐
│              DEPLOYMENT STRATEGIES                          │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ROLLING UPDATE (Kubernetes default)                      │
│  ─────────────────────────────────────────────────────────  │
│  Gradually replace old pods with new                      │
│                                                             │
│  [v1][v1][v1] → [v1][v1][v2] → [v1][v2][v2] → [v2][v2][v2]│
│                                                             │
│  + Zero downtime                                          │
│  + Simple                                                  │
│  - Slow rollback                                          │
│                                                             │
│  BLUE-GREEN                                               │
│  ─────────────────────────────────────────────────────────  │
│  Run both versions, switch traffic instantly              │
│                                                             │
│  [Blue v1] ← traffic     [Blue v1]                        │
│  [Green v2]         →    [Green v2] ← traffic             │
│                                                             │
│  + Instant rollback                                       │
│  + Full testing before switch                             │
│  - Double resources needed                                │
│                                                             │
│  CANARY                                                   │
│  ─────────────────────────────────────────────────────────  │
│  Route small % of traffic to new version                  │
│                                                             │
│  [v1][v1][v1] ← 90% traffic                              │
│  [v2]         ← 10% traffic (canary)                     │
│                                                             │
│  + Test with real traffic                                 │
│  + Gradual rollout                                        │
│  + Quick rollback (just remove canary)                   │
│  - More complex setup                                     │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Поетапні оновлення є типовими для Деплойментів у Kubernetes, тож це базова стратегія, яку слід зрозуміти найпершою. Контролер Деплойменту створює новий ReplicaSet для нового шаблону Пода й масштабує старі та нові ReplicaSet відповідно до maxUnavailable і maxSurge. Проби готовності тут важливі, бо Kubernetes не має зараховувати новий Под як доступний, доки той не зможе обслуговувати трафік. Якщо проба готовності відсутня або занадто поверхова, Деплоймент може й далі розкочувати версію, яка успішно запускається, але не здатна обробляти реальні запити.

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

Канаркове розгортання є стратегією навчання не менше, ніж стратегією релізу. Воно ставить продакшен-середовищу обмежене питання: чи поводиться ця нова версія прийнятно для невеликого зрізу реальних користувачів? Відповідь має приходити з метрик на кшталт рівня помилок, затримки, насиченості та бізнес-результатів, а не лише з того, чи Поди готові (Ready). Канарка, що обслуговує один відсоток трафіку, але подвоює відмови оформлення замовлення, має зупинитися, навіть якщо кожен об’єкт Kubernetes зелений. Саме тому канаркова автоматизація часто інтегрує service mesh, контролер ingress або інструменти прогресивної доставки з даними спостережуваності.

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

Стратегія	Простій	Відкат	Вартість ресурсів	Складність
Поетапна	Немає	Повільний	Звичайна	Низька
Blue-Green	Немає	Миттєвий	2× під час розгортання	Середня
Канаркова	Немає	Швидкий	Незначне зростання	Висока
Recreate	Так	Повільний	Звичайна	Найнижча

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

Докази розгортання мають включати сигнали як Kubernetes, так і застосунку. Kubernetes може сказати вам, чи заплановані Поди, чи завантажені образи, чи запустилися контейнери, чи пройшли проби й чи завершилося розкочування. Телеметрія застосунку каже вам, чи успішні користувачі, чи прийнятна затримка й чи витрачається бюджет помилок. Конвеєр, що зупиняється на k rollout status, може пропустити версію, яка технічно доступна, але функційно зламана. Сильний конвеєр трактує узгодження кластера як необхідне, але недостатнє.

У реальному інциденті діагностуйте зовні всередину. Якщо користувачі не можуть дістатися сервісу після розгортання, перевірте маршрутизацію трафіку та ендпоінти Сервісу, перш ніж припускати, що код зламаний. Якщо Поди не готові, огляньте проби готовності, логи та події. Якщо Поди застрягли в помилках завантаження образу, огляньте облікові дані реєстру, імена образів, теги й дайджести. Якщо контролер GitOps постійно відкочує ручне виправлення, огляньте бажаний стан у Git та логи узгодження. Цей діагностичний шлях не дає вам змінювати випадкові налаштування, поки справжній збій усе ще видимий.

Патерни та антипатерни

Сильні патерни CI/CD роблять ризик видимим рано й тримають продакшен-шлях нудним. Перший патерн — незмінність артефакту: зберіть образ один раз, ідентифікуйте його за дайджестом або унікальним тегом версії та просувайте той самий артефакт через середовища. Другий патерн — розділена відповідальність: CI доводить артефакт і оновлює бажаний стан, тоді як контролер розгортання або агент GitOps узгоджує Kubernetes. Третій патерн — поступовий вплив: випустіть на staging, потім на невеликий зріз продакшену, а потім на ширшу аудиторію після того, як метрики лишаються здоровими. Ці патерни масштабуються, бо створюють докази, які різні команди можуть перевіряти, не покладаючись на пам’ять.

Патерн	Коли застосовувати	Чому працює	Міркування щодо масштабування
Просування незмінного образу	Будь-який сервіс, де продакшен має запускати протестований артефакт	Дайджест або унікальний тег прив’язує тести до образу під час виконання	Додайте політики зберігання, щоб важливі релізні образи не збиралися як сміття занадто рано
Узгодження GitOps	Командам потрібні придатність до аудиту, виявлення дрейфу та вужчі облікові дані кластера	Git стає переглянутим бажаним станом, а контролер володіє записом у кластер	Обмежуйте область репозиторіїв, просторів імен і дозволів контролера за командою чи середовищем
Прогресивна доставка	Зміни мають вагомий ризик у продакшені, але їх можна спостерігати поступово	Канаркове або поетапне розкочування обмежує радіус ураження, збираючи реальні сигнали	Потребує формування трафіку та метрик, що чітко ідентифікують нову версію
Репетиції відкату	Сервіси мають зобов’язання щодо доходу, відповідності чи доступності	Команди знають, чи відкат — це повернення образу, перемикання трафіку чи revert у Git	Тестуйте шляхи відкату до інцидентів, особливо коли задіяні міграції схеми

Антипатерни зазвичай починаються як скорочення, що спрацювали одного разу. Найпоширеніше — давати серверу CI широкі облікові дані кластера, бо це було швидше, ніж налаштовувати межу розгортання. Інше — використовувати змінні теги на кшталт latest у продакшені, бо команда хоче прості маніфести. Третє — трактувати зелений конвеєр як доказ справності користувачів, навіть коли немає метрик після розгортання. Ці скорочення здаються ефективними, доки команді не доведеться пояснити, який артефакт було розгорнуто, хто його погодив і чому відкат не миттєвий.

Антипатерн	Що йде не так	Краща альтернатива
CI-сервер як суперкористувач кластера	Скомпрометований ранер або токен може напряму змінити продакшен	Використовуйте облікові дані з найменшими привілеями або узгодження GitOps за моделлю «pull»
Змінні теги в продакшені	Кластер може запускати інший образ, ніж той, що пройшов тести	Розгортайте незмінні дайджести або унікальні теги версій
Один гігантський релізний потяг	Багато непов’язаних змін провалюються разом, а діагностика сповільнюється	Постачайте менші зміни за прапорцями функцій або поетапним просуванням
Жодного сигналу після розгортання	Команда виявляє збій на боці користувача після надходження звернень у підтримку	Ставте просування в залежність від метрик розкочування, помилок, затримки та бізнесу
Ручний хотфікс поза Git	GitOps або наступне розгортання перезаписує екстрену зміну	Зафіксуйте тривале виправлення комітом у репозиторій бажаного стану

Важлива звичка — перетворювати кожен антипатерн на конкретний засіб контролю, а не на гасло. «Автоматизуйте все» занадто розпливчасте, щоб допомогти команді під тиском. «Кожен продакшен-образ має бути позначений за дайджестом, а репозиторій GitOps має записувати дайджест, що пройшов staging» — дієве. «Майте відкат» розпливчасте. «Для цього сервісу відкат означає повернення дайджесту образу в Git і спостереження за тим, як застосунок Argo CD повертається до стану Healthy в межах погодженої цілі відновлення» — операційне.

Рамка ухвалення рішень

Використовуйте цю рамку, коли сценарій просить вас обрати модель CI/CD, категорію інструментів або стратегію розгортання. Почніть із визначення ризику релізу, потім вирішіть, де належить рішення про реліз, потім оберіть межу інструментів, що підтримує це рішення. Якщо сервіс низькоризиковий і команді потрібен швидкий зворотний зв’язок, CI плюс Continuous Delivery може бути достатньо. Якщо сервіс високоризиковий або регульований, лишіть ручне погодження, вимагайте сильніших доказів і віддавайте перевагу моделі розгортання, що лишає тривалий слід для аудиту. Якщо організація потребує розділення облікових даних кластера, оцініть GitOps, перш ніж дозволяти зовнішньому CI змінювати продакшен.

Точка рішення	Обирайте це, коли	Уникайте цього, коли	Докази, за якими стежити
Continuous Delivery	Люди мають обирати момент виходу в продакшен після того, як автоматизація довела готовність	Команда хоче, щоб кожне злиття одразу досягало користувачів, і має сильні автоматичні запобіжники	Успішний конвеєр, запис погодження, димові тести на staging
Continuous Deployment	Кожна успішна зміна має розгортатися автоматично з автоматичним відкатом або критеріями зупинки	Тести й телеметрія продакшену слабкі, або зміни потребують ручного бізнес-таймінгу	Рівень помилок, затримка, насиченість, автоматизація відкату
CI/CD за моделлю «push»	Невелика команда, простий доступ до кластера й обмежений тиск відповідності	Компрометація CI створила б неприйнятний доступ до продакшену	Область облікових даних CI, логи аудиту, статус розкочування
Модель «pull» GitOps	Важать аудит Git, виявлення дрейфу та межі облікових даних кластера	Бажаний стан здебільшого є імперативними скриптами зі слабким декларативним контролем	Справність узгодження, історія Git, дозволи контролера
Поетапне оновлення	Бездержавний сервіс, зворотно сумісна зміна та звичайний бюджет ресурсів	Змішані старі й нові версії небезпечні	Готовність, прогрес розкочування, метрики рівня сервісу
Blue-green або канаркова	Ризикована зміна потребує швидкого відкату або виміряного впливу	Потужності чи контроль трафіку не можуть підтримати стратегію	Метрики окремих версій, розподіл трафіку, час відкату

Послідовність навмисно консервативна. По-перше, запитайте, чи може команда довести, що артефакт достатньо безпечний для розгортання. Якщо ні, покращте докази CI й тестів, перш ніж сперечатися про автоматизацію розгортання. По-друге, запитайте, чи потребує таймінг продакшену людського контексту. Якщо так, Continuous Delivery — кращий ярлик, ніж Continuous Deployment. По-третє, запитайте, чи має зовнішня система мати облікові дані, що змінюють кластер. Якщо відповідь — ні, GitOps зазвичай безпечніша архітектура. По-четверте, запитайте, який радіус ураження зміна може витерпіти. Ця відповідь обирає поетапну, blue-green, канаркову чи recreate надійніше за особисті вподобання.

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

Розгляньмо опрацьований приклад для API замовлень, що має три репліки, приватний реєстр і застосунок Argo CD, який спостерігає за репозиторієм продакшен-маніфестів. Розробник зливає зміну, CI збирає orders із коміту, виконує тести, сканує образ і відправляє дайджест до Harbor. Потім конвеєр відкриває pull request, що змінює посилання на образ у Деплойменті в репозиторії GitOps. Після перегляду Argo CD бачить новий бажаний стан, застосовує його, а оператор спостерігає за k rollout status deployment/orders плюс метриками помилок окремої версії, перш ніж оголосити реліз завершеним.

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

Якщо Поди стають готовими, але помилки оформлення замовлення зростають, рамка спрямовує увагу в інший бік. Реєстр і планувальник Kubernetes зробили свою роботу, і розкочування може навіть виглядати завершеним із погляду контролера Деплойменту. Збій тепер у поведінці застосунку, сумісності конфігурації, доступі до залежностей нижче за течією або безпеці міграції даних. Система релізу має зупинити просування, зберегти логи й метрики для поганої версії та обрати метод відкату, що відповідає стратегії розгортання, а не сліпо застосовувати інший маніфест.

Якщо Argo CD повідомляє OutOfSync одразу після ручної екстреної правки, рамка пояснює, чому кластер здається впертим. GitOps стверджує, що переглянутий бажаний стан у Git володіє навантаженням. Жива правка може бути корисною для екстреного спостереження, але вона не тривала, якщо тільки та сама зміна не досягне спостережуваного репозиторію або узгодження не буде навмисно призупинено. Ця відмінність особливо важлива для KCNA, бо вона відокремлює декларативну операцію від спонтанного адміністрування, навіть коли обидва використовують API Kubernetes.

Якщо команда хоче покращити конвеєр після інциденту, їй слід додати відсутній засіб контролю на тому етапі, що провалився. Збій завантаження образу може потребувати попередньої перевірки доступу до реєстру або кращого керування pull-секретами. Погана відповідь застосунку може потребувати сильніших інтеграційних тестів, канаркового аналізу або версійних метрик. Несподіванка з дрейфом GitOps може потребувати інструкції «розбити скло» та чіткішого володіння репозиторієм маніфестів. Зрілість CI/CD зростає, коли дії після інциденту посилюють правильну межу, а не додають розпливчасті кроки погодження всюди.

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

Чи знали ви?

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

• Термін GitOps запровадила Weaveworks — термін популяризувала у 2017 році компанія Weaveworks, описуючи узгодження у стилі Flux із Git у кластери Kubernetes.

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

• Метрики DORA змінили розмови про релізи — частота розгортань, час виконання змін, частота невдалих змін і середній час відновлення дають командам змогу обговорювати продуктивність доставки з вимірними результатами.

Типові помилки

Помилка	Чому вона виникає	Як її виправити
Трактування Continuous Delivery та Continuous Deployment як одного й того ж	Обидва скорочуються до CD, і обидва покладаються на автоматизовані конвеєри	Запитайте, чи продакшен усе ще вимагає ручного рішення про реліз; якщо так, називайте це Continuous Delivery
Розгортання змінних тегів образу на кшталт latest	Тег зручний під час демонстрацій і раннього розроблення	Просувайте незмінні дайджести або унікальні теги версій, що ідентифікують артефакт, який пройшов тести
Надання CI широких облікових даних продакшен-кластера	Це найшвидший спосіб змусити ранній конвеєр розгортати	Використовуйте найменші привілеї, облікові дані з областю за середовищем або контролер GitOps, що завантажує погоджений стан
Пропуск перевірок реєстру та завантаження образу	Тести застосунку пройшли, тож команда припускає, що Kubernetes може запустити образ	Перевіряйте імена образів, дайджести, pull-секрети, політику реєстру та події ImagePullBackOff, перш ніж налагоджувати код
Оголошення розкочування успішним після того, як API прийняв YAML	k apply завершився успішно, що відчувається як успіх розгортання	Спостерігайте за статусом розкочування, готовністю Подів, подіями та метриками застосунку, перш ніж просувати чи закривати зміну
Вибір канарки без телеметрії окремих версій	Канарка звучить безпечніше, але команда не може сказати, яка версія спричинила помилки	Додайте мітки, метрики, логи та дашборди, що відокремлюють стабільний і канарковий трафік, перш ніж покладатися на стратегію
Ручний хотфікс живих ресурсів за GitOps	Екстрена правка здається швидшою, ніж відкриття переглянутої зміни в Git	Зафіксуйте тривале виправлення в Git або навмисно призупиніть узгодження за задокументованим шляхом «розбити скло»

Тест

Ваша команда може автоматично збирати, тестувати й пакувати кожне злиття, але менеджер релізів усе ще обирає, коли розгортати в продакшен. Порівняйте Continuous Integration, Continuous Delivery та Continuous Deployment, а потім назвіть модель, яку використовує ця команда.

Команда практикує Continuous Integration, бо кожне злиття автоматично збирається й тестується, і вона практикує Continuous Delivery, бо кожна успішна зміна готується до релізу. Вона не практикує Continuous Deployment, бо людина все ще обирає момент виходу в продакшен. Ці ручні ворота можуть бути доречними для бізнес-таймінгу, відповідності чи високоризикових сервісів. Міркування залежить від того, хто або що ухвалює остаточне рішення про продакшен, а не від того, чи автоматизовані попередні етапи конвеєра.

Сервіс Kubernetes зазнає збою після релізу, бо запущені Поди завантажили інший образ, ніж той, що тестувався на staging. Спроєктуйте засіб контролю конвеєра, що має запобігти цій невідповідності артефактів.

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

Аудитор безпеки заперечує, що Jenkins зберігає облікові дані адміністратора для продакшен-кластера. Оцініть, чи зменшив би ризик GitOps з Argo CD або Flux.

GitOps може зменшити ризик, перемістивши зміну кластера із зовнішнього сервера CI до контролера всередині кластера з обмеженими дозволами Kubernetes. Jenkins може збирати образи й оновлювати Git, тоді як Argo CD або Flux завантажує погоджений бажаний стан і узгоджує кластер. Це створює чіткіший слід для аудиту, бо зміни в продакшені є комітами в Git, і це уникає надання ранеру CI широкого прямого доступу до API Kubernetes. Контролер усе ще потребує ретельного обмеження дозволів, тож GitOps зменшує ризик лише тоді, коли його налаштовано з найменшими привілеями.

Ваша команда платформи порівнює Jenkins, GitHub Actions, GitLab CI, Tekton, Argo CD, Flux та Argo Workflows. Які два питання найкраще відокремлюють інструменти CI від інструментів розгортання GitOps?

Запитайте, де виконується робочий процес і чи інструмент передусім доводить артефакти, чи узгоджує бажаний стан у кластер. Jenkins, GitHub Actions, GitLab CI та Tekton зазвичай використовують для збірки, тестування, сканування й пакування артефактів, хоча Tekton моделює цю роботу як ресурси Kubernetes. Argo CD та Flux є інструментами розгортання GitOps, бо вони спостерігають за декларованим станом і застосовують його до кластерів. Argo Workflows запускає загальні робочі процеси Kubernetes, тож може підтримувати завдання доставки, але не є тією самою категорією, що й узгоджувач GitOps.

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

Continuous Deployment може пасувати погано, якщо команді бракує автоматичних правил, що розуміють подію трафіку й бізнес-ризик. Continuous Delivery утримувала б артефакт готовим, зберігаючи ручне рішення про реліз, що дало б команді змогу зачекати, доки мине вікно ризику, або додати суворіші канаркові засоби контролю. Якщо команда вже має чудові автоматизовані тести, метрики окремих версій, канарковий аналіз та автоматизацію відкату, Continuous Deployment усе ще міг би спрацювати. Рішення залежить від упевненості в автоматизованих доказах, а не від ентузіазму щодо автоматизації.

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

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

Інженер виправляє продакшен-Деплоймент за допомогою `k edit`, але Argo CD пізніше повертає його назад. Діагностуйте, що сталося, і як слід зробити тривале виправлення.

Argo CD узгодив живий кластер назад до бажаного стану, записаного в Git. Ручна правка змінила лише живий стан, тож вона створила дрейф, а не тривале продакшен-виправлення. Тривалу корекцію слід зафіксувати комітом у репозиторій Git, за яким спостерігає Argo CD, переглянути, а потім узгодити в кластер. У справжній надзвичайній ситуації команда може тимчасово призупинити узгодження, але це має бути навмисною дією «розбити скло» з подальшим закріпленням у Git.

Практична вправа: простежте шлях доставки Kubernetes

Ця вправа — лабораторія міркувань, яку ви можете виконати з локальним кластером Kubernetes, спільним практичним кластером або паперовим дизайном, якщо у вас немає доступу до кластера. Суть у тому, щоб простежити докази вздовж шляху доставки, а не запам’ятати один інструмент. Ви спроєктуєте невеликий конвеєр, оберете, де належать облікові дані, вирішите, як ідентифікується образ, і визначите сигнали розкочування, що переконали б вас у справності релізу. Якщо ви все-таки використовуєте кластер, спершу встановіть alias k=kubectl, щоб приклади відповідали скороченню, що вживається в цьому напрямку.

Налаштування

Використайте простий репозиторій вебзастосунку у власній пісочниці або накидайте ті самі об’єкти в документі. Якщо у вас є доступний кластер Kubernetes 1.35+, створіть простір імен на кшталт delivery-lab і використайте нешкідливий публічний образ для дослідження. Не використовуйте продакшен-облікові дані, реальні дані клієнтів чи приватні токени. Дизайн має бути достатньо переносним, щоб інший учень міг його прочитати й зрозуміти, який етап володіє якою відповідальністю.

Завдання

1. Зіставте етапи джерела, збірки, тестування, пакування та розгортання для сервісу, що працює як Деплоймент Kubernetes.
2. Вирішіть, чи сервіс має використовувати Continuous Delivery чи Continuous Deployment, і запишіть причину контролю над релізами.
3. Оберіть межу інструментів: пряме надсилання з CI, GitOps з Argo CD або Flux, чи нативний для Kubernetes CI з Tekton плюс контролер GitOps.
4. Уточніть, як образ рухається через реєстр, зокрема чи посилаються маніфести на унікальний тег чи дайджест.
5. Оберіть поетапне, blue-green чи канаркове розкочування й перелічіть сигнали Kubernetes та застосунку, потрібні перед просуванням.
6. Діагностуйте один шлях збою: помилка завантаження образу, провалена готовність, дрейф GitOps чи регресія канаркової метрики.

Орієнтири для розв'язання

Сильна відповідь відокремлює доведення артефакту від узгодження кластера. Наприклад, GitHub Actions або GitLab CI можуть виконати тести, зібрати образ, просканувати його, відправити його до GHCR або Harbor і відкрити pull request, що оновлює маніфест незмінним посиланням на образ. Argo CD або Flux потім можуть узгодити погоджений бажаний стан у кластер. Менш ризикований внутрішній сервіс міг би зупинитися на Continuous Delivery з ручним просуванням, тоді як зріла команда з чудовою телеметрією могла б обрати Continuous Deployment для невеликого бездержавного сервісу.

Для стратегії розкочування зіставте радіус ураження з ризиком. Рутинна бездержавна зміна може використати поетапне оновлення з пробами готовності, k rollout status, логами та метриками сервісу. Зміна маршрутизації чи протоколу, що ламає сумісність, може виправдати blue-green, якщо є потужності. Ризикована зміна, орієнтована на клієнта, може виправдати канарку, якщо доступні маршрутизація трафіку та метрики окремих версій. Для діагностики збою спершу назвіть межу: реєстр і pull-секрет для помилок образу, події Пода та проби для збоїв готовності, бажаний стан у Git для дрейфу Argo CD та телеметрія застосунку для канаркової регресії.

Критерії успіху

• Я можу порівняти Continuous Integration, Continuous Delivery та Continuous Deployment і обґрунтувати одну модель контролю над релізами.
• Я можу спроєктувати конвеєр CI/CD для Kubernetes, що збирає, тестує, пакує, зберігає та розгортає образ контейнера.
• Я можу оцінити Jenkins, GitHub Actions, GitLab CI, Tekton, Argo CD, Flux та Argo Workflows за відповідальністю та межею облікових даних.
• Я можу пояснити, чому тег або дайджест реєстру має пов’язувати протестований артефакт із розгорнутим навантаженням.
• Я можу обрати поетапне, blue-green чи канаркове розгортання на основі радіуса ураження, швидкості відкату, вартості ресурсів і телеметрії.
• Я можу діагностувати дрейф GitOps, збій завантаження образу, збій готовності чи канаркову регресію, простежуючи правильні докази.

Джерела

• Документація Kubernetes: Deployments
• Документація Kubernetes: Updating a Deployment
• Документація Kubernetes: Images
• Документація Kubernetes: Pull an Image from a Private Registry
• Документація Kubernetes: kubectl rollout
• DORA: Software delivery performance metrics
• Документація Jenkins
• Документація GitHub Actions
• Документація GitLab CI/CD
• Документація Tekton
• Документація Argo CD
• Документація Flux
• Документація Argo Workflows
• Документація Harbor

Наступний модуль

Модуль 4.2: Пакування застосунків — Helm, Kustomize та інші інструменти для пакування застосунків Kubernetes, щоб ваш конвеєр доставки міг просувати повторюваний бажаний стан замість розрізненого YAML.