Підсумковий тест частини 2: Розгортання застосунків

Lab Progress 0/4 completed

Складність: [СКЛАДНИЙ]

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

Передумови: Деплойменти та ReplicaSet, історія розгортань, основи Helm, оверлеї Kustomize, Сервіси та селектори

Контекст іспиту: Підсумкова практика CKAD для робочих процесів розгортання застосунків на Kubernetes 1.35+

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

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

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

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

Ви зможете порівнювати робочі процеси Helm та Kustomize щодо пакування, налаштування під різні середовища, поведінки відкату та діагностики на іспитовій швидкості під тиском часу.

Ви зможете оцінювати, чи є селектор Сервісу, набір міток Деплоймента, зміна значення Helm або заміна образу в Kustomize найбезпечнішою точкою контролю для зміни розгортання у продакшені.

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

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

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

Розгортання застосунків — це місце, де знання CKAD перетворюються на операційне судження. Недостатньо знати, що існує k rollout undo або що в Helm є команда rollback. У реальному кластері питання полягає в тому, чи повертає відкат трафік до наперед відомої справної версії, чи змінив оверлей Kustomize ім’я об’єкта, на який є посилання, чи повторно використав апгрейд Helm потрібні значення і чи не включив селектор Сервісу випадково одночасно стабільні та експериментальні Поди. Це прикладні й аналітичні навички, а не навички запам’ятовування.

Цей підсумковий модуль перетворює частину 2 на пов’язану практику розгортання. Ви повторите механізми, які роблять так, що Деплойменти, Helm, Kustomize та стратегії релізів узгоджуються між собою, а потім застосуєте їх у сценаріях, які виглядають як іспитові завдання та продакшен-інциденти. Мета — не запам’ятати один ідеальний YAML-файл. Мета — побудувати надійний шлях прийняття рішень, який можна використати, коли робоче навантаження потрібно швидко змінити, не ускладнюючи розуміння кластера.

Площина контролю Деплоймента: що насправді змінюється

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

Найпростіша ментальна модель полягає в тому, що Деплоймент не «запускає» ваш застосунок напряму. Він записує намір, створює або масштабує ReplicaSet і чекає, доки достатньо Подів стане доступними. Шаблон Пода — це межа, яка має значення для історії розгортання. Зміна replicas масштабує поточний ReplicaSet, але зміна образу, команди, середовища, проб, міток чи інших полів усередині spec.template створює нову ревізію. Питання CKAD часто приховують цю відмінність, змішуючи операції масштабування з оновленнями образу, тож сповільніться достатньо, щоб вирішити, чи змінюєте ви ємність, чи змінюєте ідентичність застосунку.

+--------------------------- Deployment: api ----------------------------+
| desired replicas: 4                                                    |
| strategy: RollingUpdate                                                |
| pod template hash changes when spec.template changes                   |
+------------------------------+-----------------------------------------+
                               |
                               v
+-----------------------+      scale down      +-------------------------+
| ReplicaSet api-old    | <------------------- | ReplicaSet api-new      |
| image: api:1.3        |                      | image: api:1.4          |
| replicas: 2           | -------------------> | replicas: 2             |
+-----------+-----------+      scale up        +------------+------------+
            |                                             |
            v                                             v
+-----------------------+                      +-------------------------+
| Pods serving traffic  |                      | Pods must become Ready  |
| selected by Service   |                      | before rollout succeeds |
+-----------------------+                      +-------------------------+

Послідовне оновлення (rolling update) безпечне лише тоді, коли застосунок може терпіти одночасну роботу двох версій. Для застосунків без стану зазвичай це припущення за замовчуванням. Для застосунків зі строгим зчепленням схем, обмеженнями вибору лідера або обмеженнями одного запису припущення за замовчуванням може бути хибним. Kubernetes охоче запустить старі та нові Поди разом, якщо ви замовите послідовне оновлення; він не знає, чи підтримує протокол вашого застосунку таку суміш. Ваше завдання — обрати стратегію, що відповідає межі сумісності робочого навантаження.

maxSurge та maxUnavailable описують тимчасову межу ємності під час послідовного оновлення. maxSurge: 1 з чотирма репліками дозволяє короткочасно мати п’ять Подів, що може зберегти ємність, поки запускаються нові Поди. maxUnavailable: 0 означає, що Kubernetes має уникати падіння нижче бажаної кількості доступних реплік під час оновлення. Ці поля — не абстрактні ручки налаштування; вони кодують бізнес-обіцянку, яку ви даєте, замінюючи робоче навантаження. Якщо у кластері немає вільної ємності, агресивні налаштування сплеску все одно можуть залишити Поди в стані очікування, тож перевірка розгортання має включати сигнали планування та готовності.

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

Відповідь полягає в тому, що новий ReplicaSet може зростати лише настільки, наскільки дозволяють бюджет сплеску та обмеження готовності. Невдалі чи неготові нові Поди не дають Деплойменту вважати їх доступними, тож контролер має уникати масштабування вниз надто багатьох старих доступних Подів. Статус Деплоймента може казати, що розгортання не просувається, але саме події Подів та збої проб готовності пояснюють причину. На практиці ви перевіряєте розгортання за допомогою k rollout status deploy/name, оглядаєте ReplicaSet через k get rs, а потім переходите до k describe pod або k logs для несправних нових Подів.

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

k get deploy api
k rollout status deploy/api
k get rs -l app=api
k get pods -l app=api -o wide
k describe pod -l app=api
k get svc api -o yaml
k get endpointslice -l kubernetes.io/service-name=api

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

Розбір на прикладі: діагностика застряглого розгортання

Припустімо, команда оновлює api з registry.example.com/api:1.3 до registry.example.com/api:1.4. Деплоймент має чотири репліки, maxSurge: 1 та maxUnavailable: 0. Розгортання не завершується. Новачок одразу запустив би k rollout undo deploy/api, що може бути правильною дією з відновлення, але це пропускає діагностику. Сильніший оператор витрачає короткий, фіксований проміжок часу, щоб довести, що змінилося і де застрягло розгортання.

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

k rollout status deploy/api --timeout=30s
k rollout history deploy/api
k get deploy api -o wide

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

k get rs -l app=api
k describe rs -l app=api

Потім огляньте нові Поди. Найшвидший сигнал часто з’являється у READY, STATUS, RESTARTS, подіях та логах контейнера. Збій проби готовності відрізняється від збою завантаження образу, і обидва відрізняються від падіння після старту. Кожен указує на різне виправлення, тож не зводьте кожне невдале розгортання до одного й того ж рефлексу відкату.

k get pods -l app=api --sort-by=.metadata.creationTimestamp
k describe pod -l app=api
k logs -l app=api --tail=80

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

k rollout undo deploy/api
k rollout status deploy/api
k get endpointslice -l kubernetes.io/service-name=api

Розбір на прикладі демонструє ключову звичку, якої очікує цей модуль: обирайте команди, тому що вони відповідають на питання. rollout status відповідає, чи завершив контролер розгортання. get rs відповідає, як репліки розподілені між ревізіями. describe pod та logs відповідають, чому конкретні контейнери не стають здоровими. get endpointslice відповідає, чи має трафік реальні внутрішні Поди. Коли ви можете сформулювати питання, команду легше пригадати під іспитовим тиском.

Helm: стан релізу, значення та межі відкату

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

Реліз Helm корисний, тому що багато застосунків — це більше, ніж один Деплоймент. Чарт може містити Деплойменти, Сервіси, ConfigMap, ServiceAccount, об’єкти Ingress та політики, які мають змінюватися разом. Якщо ви вручну латаєте один об’єкт, яким керує Helm, наступний апгрейд Helm може перезаписати це латання, тому що Helm усе ще вважає відрендерений з чарта об’єкт джерелом істини. В іспитових завданнях це означає, що ви маєте використовувати команди Helm, коли питання описує реліз Helm. У продакшені це означає, що вам слід уникати створення дрейфу конфігурації, який майбутні апгрейди зітруть.

Найважливіша навичка роботи зі значеннями Helm — це розуміння різниці між значеннями чарта за замовчуванням, значеннями, наданими користувачем, та поточно застосованими значеннями. helm show values показує значення чарта за замовчуванням. helm get values RELEASE показує власні значення, надані встановленому релізу, а --all включає обчислені значення. helm upgrade --reuse-values починає з наявних власних значень релізу та застосовує зміни, які ви додаєте. Без цього прапорця апгрейд може випадково відкинути попередні налаштування, якщо ви не надасте їх знову.

Завдання	Сильний вибір команди	Чому він пасує ситуації
Оглянути значення чарта за замовчуванням перед встановленням	`helm show values repo/chart`	Вам потрібно знати налаштовувані ключі, перш ніж задавати значення.
Оглянути значення, використані релізом	`helm get values release --all`	Вам потрібні докази розгорнутої конфігурації, а не значення чарта за замовчуванням.
Встановити в новий простір імен	`helm install name repo/chart -n ns --create-namespace`	Реліз і простір імен створюються однією відтворюваною командою.
Апгрейд зі збереженням попередніх перевизначень	`helm upgrade name repo/chart --reuse-values --set key=value`	Наявні власні значення залишаються на місці, поки змінюється одне налаштування.
Відновитися після поганого апгрейду чарта	`helm rollback name REVISION`	Helm відновлює відрендерений стан релізу для тієї ревізії.
Чисто видалити реліз	`helm uninstall name -n ns`	Helm видаляє об’єкти, якими володіє для того релізу в просторі імен.

Helm може бути оманливо швидким під час практики CKAD, тому що одна команда створює багато об’єктів. Ця швидкість цінна лише тоді, коли ви перевіряєте, що було відрендерено і що застосовано. helm template попередньо переглядає маніфести без встановлення. helm upgrade --dry-run перевіряє відрендерений вивід для апгрейду. Після застосування helm status, k get all та специфічні для навантаження перевірки розгортання підтверджують, чи здорові об’єкти чарта. Успіх Helm означає, що Kubernetes прийняв реліз; він не гарантує, що застосунок готовий обслуговувати трафік.

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm show values bitnami/nginx | less
helm install my-nginx bitnami/nginx --set replicaCount=3 -n web --create-namespace
helm status my-nginx -n web
k rollout status deploy -n web

Підказка для активного навчання: Реліз було встановлено з власними обмеженнями ресурсів, а пізніше оновлено командою helm upgrade app chart --set service.type=LoadBalancer. Спрогнозуйте, що могло б статися з обмеженнями ресурсів, якщо --reuse-values пропущено, потім поясніть, яка команда довела б поточні значення.

Ризик полягає в тому, що апгрейд може відрендеритися зі значень чарта за замовчуванням плюс нове надане налаштування, а не з кожного попереднього власного перевизначення. Точна поведінка залежить від того, як надавалися значення, та від значень чарта за замовчуванням, тому докази мають значення. Використайте helm get values app --all, щоб оглянути поточні обчислені значення, та helm history app, щоб побачити ревізії релізу. Якщо вам потрібно зберегти попередні власні значення, змінюючи одне поле, використовуйте --reuse-values або надайте повний файл значень, що представляє бажаний стан.

Відкат Helm заслуговує на ту саму обережність, що й відкат Деплоймента. Відкат релізу може змінити кілька об’єктів Kubernetes, а не лише образ Деплоймента. Часто це саме те, чого ви хочете після поганого апгрейду чарта, тому що Сервіс, ConfigMap та Деплоймент можуть потребувати повернення разом. Це також може здивувати команди, які вручну пролатали один об’єкт поза Helm. Професійна звичка — оглянути helm history, навмисно обрати цільову ревізію, відкотитися, а потім перевірити навантаження та Сервіси, що мають значення для користувачів.

helm history my-app -n production
helm rollback my-app 2 -n production
helm status my-app -n production
k get all -n production -l app.kubernetes.io/instance=my-app

Kustomize: оверлеї без втрати ідентичності об’єктів

Kustomize будує маніфести Kubernetes, нашаровуючи перетворення поверх звичайного YAML. База описує спільні ресурси, а оверлеї коригують ці ресурси для цільового середовища, як-от розробка, стейджинг чи продакшен. Це відрізняється від моделі шаблонізації Helm. Kustomize не вимагає мови чартів чи шаблонних виразів; він змінює структуровані об’єкти Kubernetes через поля, як-от resources, namespace, namePrefix, labels, patches та images.

Професійна цінність Kustomize полягає в тому, що він робить відмінності між середовищами явними, зберігаючи придатний до рев’ю YAML. Базовий Деплоймент може визначати контейнер, порти, проби та мітки, які поділяють усі середовища. Продакшен-оверлей може задати простір імен, кількість реплік, тег образу, обмеження ресурсів та префікс імені. Небезпека в тому, що перетворення можуть впливати на посилання між об’єктами. Якщо ви додаєте namePrefix, імена об’єктів змінюються. Якщо селектор Сервісу більше не збігається з мітками шаблону Пода Деплоймента, трафік ламається, навіть якщо обидва об’єкти застосувалися успішно.

+----------------------------- kustomize build ------------------------------+
|                                                                            |
|  base/                                                                     |
|  +-- deployment.yaml        common app shape                                |
|  +-- service.yaml           common traffic entry                            |
|  +-- kustomization.yaml     resources list                                  |
|                                                                            |
|                   overlay transforms are applied                            |
|                                                                            |
|  overlays/prod/                                                            |
|  +-- kustomization.yaml     namespace: production                           |
|                             namePrefix: prod-                               |
|                             images: api -> api:1.4                          |
|                             patches: replicas/resources                     |
|                                                                            |
+-----------------------------------+----------------------------------------+
                                    |
                                    v
+--------------------------- rendered Kubernetes YAML ------------------------+
| prod-api Deployment, prod-api Service, production namespace references      |
+----------------------------------------------------------------------------+

Надійний робочий процес Kustomize має два окремі кроки: попередній перегляд та застосування. kubectl kustomize ./path рендерить кінцевий YAML, щоб ви могли оглянути імена, простори імен, мітки, селектори, теги образів та патчі, перш ніж кластер їх побачить. k apply -k ./path застосовує відрендерений результат. На іспиті попередній перегляд може здаватися повільнішим, але часто це найшвидший спосіб упіймати помилку префікса, простору імен чи заміни образу, перш ніж вона коштуватиме вам кількох діагностичних команд.

kubectl kustomize overlays/prod
k apply -k overlays/prod
k get deploy,svc -n production

Перетворювач images — одна з найрелевантніших для іспиту можливостей Kustomize. Він дозволяє замінити тег образу чи повне ім’я образу, не редагуючи базовий Деплоймент. Це тримає базу стабільною, дозволяючи кожному оверлею обрати артефакт релізу. Ім’я образу має збігатися з ім’ям образу в базі, тож name: nginx збігається з nginx:1.21, тоді як база, що використовує registry.example.com/nginx, може потребувати цього повного імені як цілі збігу. Коли заміна, схоже, нічого не робить, огляньте відрендерений вивід, перш ніж припускати, що Kubernetes проігнорував зміну.

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - deployment.yaml
namespace: production
namePrefix: prod-
images:
  - name: nginx
    newTag: "1.25"

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

kubectl kustomize overlays/prod | less
kubectl kustomize overlays/prod | grep -E "name:|namespace:|image:|app:|selector:"

Підказка для активного навчання: Оверлей додає namePrefix: prod- та namespace: production, але колега вручну запускає k get svc app-svc -n production і каже, що Сервіс відсутній. Що вам слід перевірити, перш ніж щось перестворювати?

Перша перевірка — чи змінилося відрендерене ім’я Сервісу на prod-app-svc. Друга перевірка — чи існує Сервіс у призначеному просторі імен. Третя перевірка — чи селектор Сервісу досі збігається з мітками шаблону Пода після перетворень і патчів. Перестворення відсутнього об’єкта вручну може створити дрейф і приховати той факт, що оверлей уже створив об’єкт з іншим іменем. Рендеринг оверлея відповідає на питання про іменування чисто.

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

Точка рішення	Віддавайте перевагу Helm, коли	Віддавайте перевагу Kustomize, коли
Починаєте з пакета постачальника	Застосунок поширюється як підтримуваний чарт.	У вас уже є сирі маніфести і потрібні невеликі зміни середовища.
Керування історією релізів	Вам потрібні `helm history` та `helm rollback`.	Ви покладаєтеся на історію Git та `kubectl apply -k`.
Зміна полів, специфічних для середовища	Значення чітко відкривають поля в чарті.	Бази та оверлеї роблять відмінності зрозумілішими.
Діагностика відрендереного виводу	Використовуйте `helm template` або `helm get manifest`.	Використовуйте `kubectl kustomize` перед застосуванням.
Уникнення мови шаблонів	Шаблони чарта вже прийняті командою.	Звичайний YAML Kubernetes кращий для рев’ю.
Правки об’єктів на іспитовій швидкості	Завдання явно згадує реліз Helm.	Завдання явно згадує `kustomization.yaml` чи оверлеї.

Стратегії релізів: узгодження ризику трафіку з обмеженнями навантаження

Стратегія релізу — це рішення щодо трафіку та доступності, а не просто поле Kubernetes. Послідовні оновлення, перестворювальні розгортання, переключення blue/green та канаркові релізи всі відповідають на одне питання: як користувачі мають переходити з однієї версії на іншу? Kubernetes надає примітиви, як-от Деплойменти, Сервіси, мітки та кількості реплік. Ви збираєте ці примітиви у патерн релізу, що відповідає сумісності застосунку, толерантності до ризику та операційній швидкості.

Послідовне оновлення — це стратегія Деплоймента за замовчуванням, тому що вона пасує багатьом сервісам без стану. Вона поступово замінює старі Поди новими, намагаючись підтримувати доступність відповідно до maxSurge та maxUnavailable. Вона погано пасує, коли старі та нові версії не можуть працювати одночасно. Вона також не забезпечує чистого миттєвого перемикання трафіку; трафік іде за тими готовими Подами, що збігаються із селектором Сервісу. Якщо під час розгортання і старі, і нові Поди збігаються з тим самим селектором, обидва можуть отримувати трафік.

Стратегія перестворення (recreate) завершує старі Поди перед створенням нових. Це створює простій, але зберігає гарантію однієї версії. Вона доречна для навантажень, які не можуть безпечно працювати у двох версіях одночасно, як-от прості схожі на базу даних застосунки в іспитових сценаріях чи тісно зчеплені сервіси з одним записувачем. У продакшені багато систем зі станом мають натомість використовувати StatefulSet чи зовнішні стратегії міграції, але питання CKAD часто використовують Recreate, щоб перевірити, чи розумієте ви компроміс щодо конкурентності.

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

Before cutover:

+-----------------------+        selector: app=shop,version=blue        +----------------------+
| Service shop-svc      | --------------------------------------------> | Deployment shop-blue |
| stable DNS and port   |                                               | ready Pods: blue     |
+-----------------------+                                               +----------------------+
            |
            | does not select
            v
+----------------------+
| Deployment shop-green|
| ready Pods: green    |
+----------------------+

After cutover:

+-----------------------+        selector: app=shop,version=green       +----------------------+
| Service shop-svc      | --------------------------------------------> | Deployment shop-green|
| stable DNS and port   |                                               | ready Pods: green    |
+-----------------------+                                               +----------------------+

Перемикання blue/green часто є просто латанням Сервісу. Ця простота — водночас сила і небезпека. Точне латання змінює селектор на мітку нової версії, зберігаючи спільну мітку застосунку. Необережне латання може видалити інші ключі селектора і випадково включити непов’язані Поди. Завжди перевіряйте точки доступу після перемикання, тому що об’єкт Сервісу може виглядати дійсним, тоді як виявлення точок доступу показує нуль готових внутрішніх Подів.

k patch svc shop-svc -p '{"spec":{"selector":{"app":"shop","version":"green"}}}'
k get svc shop-svc -o yaml
k get endpointslice -l kubernetes.io/service-name=shop-svc
k get pods -l app=shop,version=green

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

+------------------------ Service myapp-svc -------------------------+
| selector: app=myapp                                                |
+------------------------------+-------------------------------------+
                               |
                +--------------+--------------+
                |                             |
                v                             v
+------------------------------+   +------------------------------+
| Deployment stable-app         |   | Deployment canary-app        |
| labels: app=myapp,track=stable|   | labels: app=myapp,track=canary|
| replicas: 9                  |   | replicas: 1                  |
+------------------------------+   +------------------------------+

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

k scale deploy stable-app --replicas=9
k scale deploy canary-app --replicas=1
k get pods -l app=myapp -o wide
k logs -l app=myapp,track=canary --tail=80
k get endpointslice -l kubernetes.io/service-name=myapp-svc

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

Стратегія	Найкраще пасує	Головна точка контролю	Фокус перевірки
RollingUpdate	Застосунки без стану, що терплять змішані версії	Стратегія Деплоймента та готовність	Статус розгортання, ReplicaSet, готовність Подів
Recreate	Застосунки, які потребують лише однієї версії за раз	Тип стратегії Деплоймента	Старі Поди завершено перед запуском нових
Blue/Green	Швидке перемикання та швидке повернення	Селектор Сервісу	EndpointSlice вказують лише на обраний колір
Canary	Невелике відкриття перед ширшим розгортанням	Кількості реплік та спільний селектор	Сервіс обирає обидві доріжки, логи ідентифікують канарку
Helm rollback	Багатооб’єктне відновлення чарта	Ревізія релізу Helm	Історія релізів, відрендерені об’єкти, здоров’я навантаження
Kustomize apply	Просування оверлея середовища	Відрендерений маніфест з оверлея	Імена, простори імен, селектори, образи

Робочий процес на іспитовій швидкості: діагностуй, зміни, перевір, віднови

CKAD винагороджує швидкість, але надійна швидкість походить зі скорочення рішень, а не з їх пропуску. Для завдань розгортання використовуйте чотирикроковий цикл: діагностуйте поточний стан, змініть найменшу правильну точку контролю, перевірте ефект та знайте команду відновлення, перш ніж вона вам знадобиться. Цей цикл працює для Деплойментів, релізів Helm, оверлеїв Kustomize, перемикань blue/green та канарок, тому що кожен передбачає намір, застосування та перевірку.

Перший крок — діагностика. Визначте власника бажаного стану. Якщо об’єкт — це сирий Деплоймент, використовуйте k get deploy, k rollout history та огляд ReplicaSet. Якщо сценарій називає реліз Helm, огляньте реліз через Helm, перш ніж латати об’єкти Kubernetes вручну. Якщо він називає Kustomization, відрендеріть його перед застосуванням. Якщо він описує перемикання трафіку, огляньте селектори Сервісу та точки доступу. Власник підкаже вам, де належить тривале виправлення.

Другий крок — найменша правильна зміна. Для поганого образу Деплоймента може вистачити k set image чи застосування виправленого маніфеста. Для зміни значення Helm використовуйте helm upgrade з явними значеннями чи --reuse-values. Для тега образу Kustomize змініть поле images оверлея та застосуйте з -k. Для blue/green пролатайте селектор Сервісу. Найменша не означає недбала; це означає, що зміна націлена на рівень, який володіє проблемою.

Третій крок — перевірка. Команда, яка успішно завершилася, означає, що Kubernetes прийняв ваш запит, а не що застосунок працює. Використовуйте статус розгортання для Деплойментів, статус Helm для релізів, відрендерений вивід для Kustomize та точки доступу для Сервісів. Коли Сервіс має маршрутизувати до Подів, виявлення точок доступу — сильніший доказ, ніж сам лише YAML Сервісу. Коли розгортання має створити нову ревізію, стан ReplicaSet — сильніший доказ, ніж один рядок Деплоймента.

Останній крок — відновлення. Знайте, чи означає відновлення k rollout undo, helm rollback, повторне застосування попереднього оверлея Kustomize чи перемикання селектора Сервісу назад. Кожен механізм відкату має різну область дії. Відкат Деплоймента не відновлює ConfigMap, змінений Helm. Перемикання селектора Сервісу не змінює зламані Поди; воно лише відводить трафік. Відновлення має відповідати радіусу ураження зміни, яку ви зробили.

# Raw Deployment recovery
k rollout history deploy/api
k rollout undo deploy/api --to-revision=2
k rollout status deploy/api

# Helm release recovery
helm history api -n production
helm rollback api 2 -n production
helm status api -n production

# Kustomize recovery through a known overlay state
kubectl kustomize overlays/prod
k apply -k overlays/prod
k rollout status deploy/prod-api -n production

# Blue/green traffic recovery
k patch svc shop-svc -p '{"spec":{"selector":{"app":"shop","version":"blue"}}}'
k get endpointslice -l kubernetes.io/service-name=shop-svc

Старша звичка розгортання — записати ціль перевірки, перш ніж запускати зміну. Якщо ви латаєте Сервіс на green, ціль перевірки — це EndpointSlice, що містять green Поди та виключають blue Поди. Якщо ви апгрейдите реліз Helm, ціль — це статус релізу плюс здорові навантаження. Якщо ви застосовуєте оверлей Kustomize, ціль — це відрендерені імена, простори імен, мітки та здорове розгортання. Це запобігає типовій іспитовій помилці зупинятися на першій команді, що повертається без помилки.

Чи знали ви?

Історія ревізій Деплоймента залежить від шаблону Пода: Масштабування Деплоймента змінює кількість реплік, але редагування spec.template створює нову ревізію ReplicaSet, яка може з’явитися в історії розгортання.
Селектор Сервісу — це жива конфігурація трафіку: Латання селектора може миттєво перемістити продакшен-трафік, тож перевірка точок доступу має йти за кожною зміною селектора blue/green чи канарки.
Helm та Kubernetes ведуть різні історії: Історія релізів Helm відстежує відрендерені з чарта релізи, тоді як історія розгортання Деплоймента відстежує ревізії ReplicaSet для одного навантаження.
Попередній перегляд Kustomize — це діагностичний інструмент: kubectl kustomize може показати перетворені імена, простори імен, мітки та образи, перш ніж будь-який об’єкт буде надіслано на API-сервер.

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

Помилка	Чому це шкодить	Краща практика
Відкат до огляду ReplicaSet	Ви можете приховати проблему селектора Сервісу, проби чи планування і не дізнатися справжню причину.	Перевірте статус розгортання, ReplicaSet, Поди, події та точки доступу, перш ніж обирати відновлення.
Використання RollingUpdate для несумісних версій	Kubernetes може запустити старі та нові Поди разом, навіть коли застосунок не терпить змішаних версій.	Використовуйте Recreate, blue/green чи план, специфічний для міграції, коли може працювати лише одна версія.
Забування `--reuse-values` під час апгрейду Helm	Попередні власні значення можуть бути втрачені, якщо апгрейд рендериться зі значень за замовчуванням плюс одне нове налаштування.	Спершу огляньте значення і використайте `--reuse-values` чи повний файл значень.
Ручне латання об’єктів, якими володіє Helm	Пізніші апгрейди Helm можуть перезаписати ручні зміни і відтворити початкову проблему.	Змінюйте значення чи шаблони чарта, які володіють відрендереним об’єктом.
Застосування Kustomize без попереднього перегляду	Префікси імен, простори імен, заміни образів чи патчі можуть відрендеритися інакше, ніж очікувалося.	Запустіть `kubectl kustomize` й огляньте імена, селектори, мітки та образи перед застосуванням.
Латання лише частини селектора Сервісу	Частковий селектор може включити надто багато Подів чи виключити кожен призначений внутрішній Под.	Пролатайте повний призначений селектор і одразу перевірте EndpointSlice.
Сприйняття канаркових відсотків як точних зі звичайними Сервісами	Сервіси Kubernetes балансують між точками доступу і не забезпечують відсотків трафіку на бізнес-рівні.	Використовуйте співвідношення реплік для іспитової практики і сильніші інструменти трафіку, коли важливі точні відсотки.
Перевірка лише створення об’єктів	Створені об’єкти все ще можуть мати Поди, що падають, порожні точки доступу чи неготові контейнери.	Перевіряйте розгортання, готовність Подів, логи та маршрутизацію точок доступу після кожної зміни розгортання.

Тест

Питання 1: Застрягле послідовне оновлення під тиском ємності

Ваша команда запускає Деплоймент із чотирма репліками на ім’я webapp, що використовує nginx:1.20. Їм потрібен патерн оновлення без простою для вебрівня, і вас просять налаштувати послідовне оновлення щонайбільше з одним зайвим Подом і без запланованих недоступних Подів. Пізніше розгортання застрягає, тому що нові Поди не стають готовими. Які поля маніфеста мають кодувати стратегію і які докази вам слід оглянути перед відкатом?

Відповідь

Використайте стратегію RollingUpdate з maxSurge: 1 та maxUnavailable: 0, потім огляньте статус розгортання, ReplicaSet, готовність Подів, події та логи, перш ніж вирішувати, чи потрібен відкат.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: webapp
  template:
    metadata:
      labels:
        app: webapp
    spec:
      containers:
        - name: nginx
          image: nginx:1.20

k rollout status deploy/webapp
k get rs -l app=webapp
k get pods -l app=webapp
k describe pod -l app=webapp

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

Питання 2: Вибір правильної межі відкату

Деплоймент на ім’я api було оновлено через реліз Helm на ім’я api-prod у просторі імен production. Новий реліз змінив і образ, і значення ConfigMap, і застосунок тепер не запускається. Колега пропонує k rollout undo deploy/api -n production. Оцініть цей план і оберіть безпечнішу команду відновлення.

Відповідь

Відкат Деплоймента може відновити лише стан ReplicaSet Деплоймента, тоді як апгрейд Helm також змінив ConfigMap. Оскільки сценарій каже, що зміна була зроблена через реліз Helm і вплинула на кілька відрендерених об’єктів, відновлюйтеся через історію релізів Helm.

helm history api-prod -n production
helm rollback api-prod 2 -n production
helm status api-prod -n production
k rollout status deploy/api -n production

Точна ревізія залежить від helm history, тож не припускайте ревізію 2 без перевірки. Відкат Helm — безпечніша межа, тому що він відновлює відрендерений стан релізу, а не лише один об’єкт Деплоймента.

Питання 3: Оверлей Kustomize ламає трафік

Ви застосовуєте продакшен-оверлей Kustomize, що задає namespace: production, додає namePrefix: prod- та перевизначає тег образу. Деплоймент працює, але k get svc app-svc -n production каже, що Сервіс не існує. Ваша команда хоче перестворити Сервіс вручну. Що вам слід зробити спершу і які поля слід оглянути?

Відповідь

Спершу відрендеріть оверлей і огляньте перетворені імена об’єктів, простір імен, мітки та селектор Сервісу. Префікс міг змінити app-svc на prod-app-svc, і ручне перестворення створило б дрейф.

kubectl kustomize overlays/prod
k get svc -n production
k get deploy -n production
k get endpointslice -n production

Якщо відрендерений Сервіс має ім’я prod-app-svc, використовуйте це ім’я. Якщо Сервіс існує, але не має точок доступу, огляньте, чи селектор збігається з мітками шаблону Пода. Правильне виправлення належить в оверлеї, а не у невідстежуваному ручному Сервісі.

Питання 4: Переключення blue/green із безпекою селектора

У вас є два Деплойменти, shop-blue та shop-green. Обидва використовують app: shop, тоді як blue має version: blue, а green має version: green. Сервіс shop-svc наразі обирає blue з app: shop, version: blue. Green пройшов димові тести. Пролатайте Сервіс, щоб переключити трафік на green, і вкажіть, як ви перевірили б, що blue більше не отримує трафік через цей Сервіс.

Відповідь

Пролатайте повний призначений селектор, щоб Сервіс зберігав спільну мітку застосунку і змінював лише цільову версію.

k patch svc shop-svc -p '{"spec":{"selector":{"app":"shop","version":"green"}}}'
k get svc shop-svc -o yaml
k get endpointslice -l kubernetes.io/service-name=shop-svc
k get pods -l app=shop,version=green

Важлива перевірка — це членство в точках доступу, а не лише YAML Сервісу. EndpointSlice мають вказувати на готові green Поди і не мають включати blue Поди для цього Сервісу.

Питання 5: Канарка з операційним розділенням

Команда хоче просту канарку для myapp зі звичайними Сервісами Kubernetes. Стабільний Деплоймент має запускати дев’ять реплік, канарка — одну репліку, і один Сервіс має маршрутизувати до обох. Вони також хочуть логи лише з канарки під час тесту. Спроєктуйте мітки, команди масштабування та селектор Сервісу.

Відповідь

Використайте спільну мітку трафіку, як-от app: myapp, для обох Деплойментів та окрему діагностичну мітку, як-от track: stable чи track: canary.

k scale deploy stable-app --replicas=9
k scale deploy canary-app --replicas=1
k expose deploy stable-app --name=myapp-svc --port=80 --selector=app=myapp
k get endpointslice -l kubernetes.io/service-name=myapp-svc
k logs -l app=myapp,track=canary --tail=80

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

Питання 6: Дрейф значень Helm під час апгрейду

Реліз на ім’я frontend було встановлено з власними обмеженнями CPU та replicaCount=3. Ваш колега запускає helm upgrade frontend repo/frontend --set service.type=LoadBalancer, і після апгрейду обмеження ресурсів, схоже, повернулися до значень чарта за замовчуванням. Поясніть, що ймовірно сталося, і покажіть безпечніший патерн апгрейду.

Відповідь

Апгрейд ймовірно не зберіг попередні власні значення або відрендерився з набору значень, що пропустив обмеження ресурсів. Огляньте розгорнуті значення, а потім апгрейдіть, використовуючи --reuse-values чи повний файл значень.

helm get values frontend --all
helm history frontend
helm upgrade frontend repo/frontend --reuse-values --set service.type=LoadBalancer
helm status frontend

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

Питання 7: Вибір стратегії для навантаження з єдиною версією

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

Відповідь

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

apiVersion: apps/v1
kind: Deployment
metadata:
  name: internal-db-app
spec:
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: internal-db-app
  template:
    metadata:
      labels:
        app: internal-db-app
    spec:
      containers:
        - name: app
          image: internal-db-app:2.0

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

Питання 8: Вибір між Helm та Kustomize під іспитовим тиском

Під час практичного іспиту одне завдання каже: «Встановіть чарт bitnami/nginx як реліз my-nginx у просторі імен web з трьома репліками». Інше завдання каже: «Створіть kustomization.yaml, що включає deployment.yaml, задає простір імен production, додає префікс prod- до імен та перевизначає тег образу nginx». Порівняйте правильні вибори інструментів та надайте основні команди для кожного.

Відповідь

Перше завдання — це Helm, тому що воно називає чарт і реліз. Друге завдання — це Kustomize, тому що воно просить kustomization.yaml та перетворення маніфестів.

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm install my-nginx bitnami/nginx --set replicaCount=3 -n web --create-namespace
helm status my-nginx -n web

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - deployment.yaml
namespace: production
namePrefix: prod-
images:
  - name: nginx
    newTag: "1.25"

kubectl kustomize .
k apply -k .

Ключова відмінність — це володіння. Helm керує ревізією релізу з чарта, тоді як Kustomize рендерить перетворений YAML Kubernetes з локальних маніфестів.

Практична вправа

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

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

Крок 1: Створіть одноразовий простір імен

Створіть простір імен для вправи і тримайте кожен об’єкт усередині нього. Це тримає лабораторію ізольованою і робить прибирання передбачуваним.

k create ns ckad-part2-lab
k config set-context --current --namespace=ckad-part2-lab

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

Простір імен ckad-part2-lab існує.
Ваш поточний контекст використовує ckad-part2-lab як простір імен за замовчуванням.
k get all у просторі імен повертає жодних неочікуваних об’єктів застосунку, перш ніж ви почнете.

Крок 2: Розгорніть стабільну версію

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

cat <<'EOF' | k apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: webapp
      track: stable
  template:
    metadata:
      labels:
        app: webapp
        track: stable
    spec:
      containers:
        - name: nginx
          image: nginx:1.25
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: webapp-svc
spec:
  selector:
    app: webapp
    track: stable
  ports:
    - port: 80
      targetPort: 80
EOF

k rollout status deploy/webapp
k get deploy,rs,pods,svc
k get endpointslice -l kubernetes.io/service-name=webapp-svc

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

Деплоймент webapp досягає чотирьох готових реплік.
Сервіс webapp-svc має точки доступу, що вказують на стабільні Поди.
k get rs -l app=webapp показує ReplicaSet, створений початковим шаблоном Пода.
Ви можете пояснити, чому селектор Сервісу включає і app, і track.

Крок 3: Виконайте та огляньте оновлення образу

Оновіть образ до новішого тега nginx і перевірте, що Kubernetes створює новий ReplicaSet. Цей крок практикує різницю між зміною шаблону Пода та зміною лише кількості реплік.

k set image deploy/webapp nginx=nginx:1.26
k rollout status deploy/webapp
k rollout history deploy/webapp
k get rs -l app=webapp
k get pods -l app=webapp -o wide

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

Розгортання завершується успішно.
Історія розгортання показує більше, ніж початкову ревізію.
ReplicaSet показують, що новий шаблон Пода створив новий ReplicaSet.
Ви можете визначити, яка команда довела, що розгортання завершилося.

Крок 4: Попрактикуйте відкат Деплоймента

Відкотіть Деплоймент до попередньої ревізії і перевірте, що розподіл ReplicaSet змінюється. Це сирий відкат Деплоймента, а не відкат Helm, тому що навантаження було створено напряму маніфестами Kubernetes.

k rollout undo deploy/webapp
k rollout status deploy/webapp
k rollout history deploy/webapp
k get rs -l app=webapp

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

Деплоймент повертається до попередньої ревізії образу.
Розгортання завершується після операції undo.
Ви можете пояснити, чому k rollout undo тут доречний.
Ви можете пояснити, чому helm rollback був би недоречним для цього об’єкта, створеного таким чином.

Крок 5: Створіть green Деплоймент для практики blue/green

Створіть другий Деплоймент, що представляє green версію. Збережіть ту саму мітку app: webapp, але використайте track: green, щоб Сервіс міг точно перемикати трафік.

cat <<'EOF' | k apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp-green
spec:
  replicas: 4
  selector:
    matchLabels:
      app: webapp
      track: green
  template:
    metadata:
      labels:
        app: webapp
        track: green
    spec:
      containers:
        - name: nginx
          image: nginx:1.26
          ports:
            - containerPort: 80
EOF

k rollout status deploy/webapp-green
k get pods -l app=webapp --show-labels
k get endpointslice -l kubernetes.io/service-name=webapp-svc

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

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

Крок 6: Переключіть трафік на green і перевірте маршрутизацію точок доступу

Пролатайте селектор Сервісу на green. Потім перевірте точки доступу, а не лише об’єкт Сервісу.

k patch svc webapp-svc -p '{"spec":{"selector":{"app":"webapp","track":"green"}}}'
k get svc webapp-svc -o yaml
k get endpointslice -l kubernetes.io/service-name=webapp-svc
k get pods -l app=webapp,track=green

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

Селектор Сервісу включає app: webapp та track: green.
EndpointSlice для webapp-svc вказують на green Поди.
Стабільні Поди досі існують, але більше не обираються Сервісом.
Ви можете описати дію відкату для цього переключення blue/green.

Крок 7: Перемкніться назад на стабільну версію

Відновіть трафік, перемкнувши селектор Сервісу назад на стабільну версію. Це показує, що відкат blue/green — це зміна маршрутизації трафіку, а не відкат образу Деплоймента.

k patch svc webapp-svc -p '{"spec":{"selector":{"app":"webapp","track":"stable"}}}'
k get endpointslice -l kubernetes.io/service-name=webapp-svc

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

EndpointSlice вказують назад на стабільні Поди.
Green Поди досі існують після відведення трафіку.
Ви можете пояснити, чому цей відкат не змінив жодного Деплоймента.
Ви можете визначити, коли б ви видалили чи масштабували вниз green Деплоймент пізніше.

Крок 8: Попередньо перегляньте оверлей Kustomize

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

mkdir -p /tmp/ckad-part2-kustomize
cd /tmp/ckad-part2-kustomize
cat <<'EOF' > deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: nginx
          image: nginx:1.25
EOF
cat <<'EOF' > kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - deployment.yaml
namespace: ckad-part2-lab
namePrefix: prod-
images:
  - name: nginx
    newTag: "1.26"
EOF
kubectl kustomize .

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

Відрендерене ім’я Деплоймента має префікс prod-.
Відрендерений простір імен — ckad-part2-lab.
Відрендерений тег образу — 1.26.
Ви оглянули вивід, перш ніж застосовувати його до кластера.

Крок 9: Застосуйте оверлей і перевірте відрендерений об’єкт

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

k apply -k .
k rollout status deploy/prod-api
k get deploy prod-api -o wide

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

Деплоймент має ім’я prod-api, а не api.
Деплоймент працює в просторі імен лабораторії.
Деплоймент використовує перевизначений тег образу.
Ви можете пояснити, чому колега, який шукає deploy/api, використовував би хибне відрендерене ім’я.

Крок 10: Прибирання

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

cd -
k config set-context --current --namespace=default
k delete ns ckad-part2-lab
rm -rf /tmp/ckad-part2-kustomize

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

Простір імен ckad-part2-lab видалено чи він завершується.
Ваш поточний контекст більше не вказує за замовчуванням на видалений простір імен.
Тимчасовий каталог Kustomize видалено.
Ви можете повторно запустити k get ns ckad-part2-lab і пояснити результат.

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

Частина 3: Спостережуваність та обслуговування застосунків — Проби, логування, діагностика та застарівання API.

Джерела

training.linuxfoundation.org: certified kubernetes application developer ckad — Сторінка CKAD The Linux Foundation називає Kubernetes v1.35 і перелічує компетенції зі стратегій розгортання, Helm та Kustomize.
kubernetes.io: deployment — Сторінка концепції Деплоймента напряму документує декларативні оновлення, нові ReplicaSet при змінах шаблону Пода та той факт, що масштабування не створює нову ревізію.
kubernetes.io: index.html — Документація Сервісу напряму описує націлювання на основі селекторів та безперервні оновлення EndpointSlice для відповідних Подів.
kubernetes.io: liveness readiness startup probes — Документація проб явно вказує цю поведінку для невдалих проб готовності.
helm.sh: helm rollback — Довідник команди helm rollback напряму визначає відкат за ревізією і вказує читачам на helm history для номерів ревізій.
helm.sh: helm show values — Довідник команд Helm каже, що helm show values оглядає чарт і показує вміст values.yaml.
helm.sh: helm get values — Довідник helm get-values документує --all як вивід усіх обчислених значень для названого релізу.
helm.sh: helm upgrade — Довідник helm upgrade напряму визначає поведінку злиття --reuse-values.
helm.sh: helm template — Довідник helm template описує його як локальний рендеринг шаблонів та показ виводу.
kubernetes.io: kustomization — Сторінка завдання Kustomize перелічує ці поля налаштування і пояснює робочий процес на основі kustomization.
kubernetes.io: management — Документація з керування навантаженнями Kubernetes явно представляє канарковий патерн із міткою track, спільний селектор Сервісу та приклад реплік 3:1.
EndpointSlices — Найкращий довідник щодо того, як Сервіси відстежують готові внутрішні Поди і як умови точок доступу змінюються під час оновлень та завершення.
Helm Commands — Центральний довідник CLI для helm show values, get values, upgrade, history, rollback та template.