Deployment — декларативне управління Pod

Проблема: чому Pod не підходить для production

У попередніх статтях ми детально вивчили Pod — атомарну одиницю Kubernetes. Ми навчилися створювати Pod, налаштовувати контейнери, використовувати volumes, init-контейнери та sidecar-патерни. Але наприкінці статті про Pod ми зробили важливий висновок: Pod не слід створювати напряму у production.

Чому? Давайте розглянемо типовий сценарій розгортання веб-застосунку.

Сценарій: розгортання ASP.NET Core Web API

Уявіть, що ви розгортаєте ASP.NET Core Web API у Kubernetes. Ваші вимоги:

1. Три репліки для балансування навантаження та відмовостійкості
2. Автоматичне відновлення — якщо одна репліка падає, система має створити нову автоматично
3. Оновлення без downtime — нова версія застосунку має розгортатись поступово, без зупинки сервісу
4. Можливість rollback — якщо нова версія має критичний баг, потрібно швидко повернутись до попередньої версії
5. Масштабування — можливість швидко збільшити або зменшити кількість реплік залежно від навантаження

Якби ви використовували Pod напряму, вам довелося б:

Проблеми цього підходу:

Це неприйнятно для production. Саме тому існує Deployment.

Що потрібно замість ручного управління

Нам потрібен механізм, який:

1. Автоматично підтримує задану кількість реплік — якщо Pod падає, система сама створює новий
2. Дозволяє декларативно описати бажаний стан — "хочу 3 репліки версії 1.0.0", а система сама досягає цього стану
3. Виконує оновлення без downtime — поступово замінює старі Pod новими, завжди залишаючи працюючі репліки
4. Зберігає історію версій — можна швидко повернутись до попередньої версії однією командою
5. Легко масштабується — змінити кількість реплік можна однією командою або автоматично

Саме це і робить Deployment.

Що таке Deployment: формальне визначення

Deployment — це ресурс Kubernetes, який забезпечує декларативне управління набором ідентичних Pod. Ви описуєте бажаний стан (скільки реплік, яка версія образу, які ресурси), а Kubernetes автоматично підтримує цей стан.

Основні можливості Deployment

Архітектура: Deployment → ReplicaSet → Pod

Deployment не створює Pod напряму. Він використовує проміжний ресурс — ReplicaSet:

@startuml
skinparam style plain
skinparam backgroundColor #ffffff

package "Kubernetes Control Plane" #f8f9fa {
    component "Deployment Controller" as dc #e3f2fd
    component "ReplicaSet Controller" as rsc #fff3e0
}

package "Cluster" #f8f9fa {
    component "Deployment\n(myapp)" as dep #e3f2fd {
        [replicas: 3]
        [image: aspnetapp]
    }

    component "ReplicaSet\n(myapp-abc123)" as rs #fff3e0 {
        [replicas: 3]
        [template: aspnetapp]
    }

    package "Pods" #e8f5e9 {
        component "Pod 1" as p1
        component "Pod 2" as p2
        component "Pod 3" as p3
    }
}

dc --> dep : manages
dep --> rs : creates
rsc --> rs : manages
rs --> p1 : creates
rs --> p2 : creates
rs --> p3 : creates

note right of dep
    Deployment описує
    бажаний стан:
    - Скільки реплік
    - Який образ
    - Стратегія оновлення
end note

note right of rs
    ReplicaSet підтримує
    задану кількість Pod
    з певним шаблоном
end note

note right of p1
    Pod — це те,
    що насправді
    виконується
end note

@enduml

Чому потрібен ReplicaSet?

ReplicaSet відповідає за підтримку заданої кількості реплік. Його єдине завдання — гарантувати, що завжди працює рівно N Pod з певним шаблоном.

Deployment використовує ReplicaSet для реалізації rolling updates: при оновленні створюється новий ReplicaSet з новим шаблоном Pod, а старий поступово зменшується до нуля. Це дозволяє виконувати оновлення без downtime.

Анатомія Deployment: структура YAML

Тепер розглянемо, як описати Deployment у YAML. Почнемо з мінімального прикладу та поступово додаватимемо поля.

Мінімальний Deployment

Найпростіший Deployment містить лише обов'язкові поля:

apiVersion: apps/v1
kind: Deployment
metadata:
    name: nginx-deployment
spec:
    replicas: 3
    selector:
        matchLabels:
            app: nginx
    template:
        metadata:
            labels:
                app: nginx
        spec:
            containers:
                - name: nginx
                  image: nginx:1.27

Розберемо кожне поле детально.

Важливість selector та labels

Зв'язок між selector та template.metadata.labels — це найважливіша частина Deployment. Давайте розберемо детально:

spec:
    selector:
        matchLabels:
            app: nginx # ← Deployment шукає Pod з цією міткою
    template:
        metadata:
            labels:
                app: nginx # ← Pod створюються з цією міткою

Що відбувається:

1. Deployment створює Pod з міткою app: nginx (з template.metadata.labels)
2. Deployment Controller постійно шукає Pod з міткою app: nginx (через selector.matchLabels)
3. Якщо знайдено менше Pod, ніж replicas — створює нові
4. Якщо знайдено більше Pod, ніж replicas — видаляє зайві

Типова помилка новачків:

spec:
    selector:
        matchLabels:
            app: nginx # ← Шукає Pod з app=nginx
    template:
        metadata:
            labels:
                app: web # ← Створює Pod з app=web (ПОМИЛКА!)

У цьому випадку Deployment створить Pod з міткою app: web, але шукатиме Pod з міткою app: nginx. Він не знайде жодного Pod і буде нескінченно створювати нові, бо вважатиме, що реплік недостатньо.

Повна специфікація Deployment

Тепер розглянемо всі доступні поля Deployment. Почнемо з базових, потім перейдемо до розширених.

Базові поля (обов'язкові та найчастіше використовувані)

apiVersion: apps/v1
kind: Deployment
metadata:
    name: myapp-deployment
    namespace: default
    labels:
        app: myapp
        version: '1.0'
    annotations:
        description: 'My application deployment'
spec:
    replicas: 3
    selector:
        matchLabels:
            app: myapp
    template:
        metadata:
            labels:
                app: myapp
                version: '1.0'
        spec:
            containers:
                - name: app
                  image: mcr.microsoft.com/dotnet/samples:aspnetapp
                  ports:
                      - containerPort: 8080
                  env:
                      - name: ENV
                        value: 'production'
                  resources:
                      requests:
                          memory: '128Mi'
                          cpu: '100m'
                      limits:
                          memory: '256Mi'
                          cpu: '500m'

Розширені поля: стратегія оновлення

spec:
    strategy:
        type: RollingUpdate
        rollingUpdate:
            maxUnavailable: 1
            maxSurge: 1

::

spec:
    revisionHistoryLimit: 10
    progressDeadlineSeconds: 600
    minReadySeconds: 0
    paused: false

::

Повний приклад з усіма полями

Тепер об'єднаємо все, що ми вивчили, в один Deployment з усіма важливими полями:

apiVersion: apps/v1
kind: Deployment
metadata:
    name: myapp-deployment
    namespace: default
    labels:
        app: myapp
        tier: backend
        version: '1.0'
    annotations:
        description: 'Production deployment for MyApp API'
        contact: 'backend-team@example.com'
spec:
    # Кількість реплік
    replicas: 3

    # Селектор для вибору Pod
    selector:
        matchLabels:
            app: myapp

    # Стратегія оновлення
    strategy:
        type: RollingUpdate
        rollingUpdate:
            maxUnavailable: 1
            maxSurge: 1

    # Контроль життєвого циклу
    revisionHistoryLimit: 10
    progressDeadlineSeconds: 600
    minReadySeconds: 5

    # Шаблон Pod
    template:
        metadata:
            labels:
                app: myapp
                version: '1.0'
        spec:
            containers:
                - name: app
                  image: mcr.microsoft.com/dotnet/samples:aspnetapp
                  ports:
                      - containerPort: 8080
                        name: http
                  env:
                      - name: ASPNETCORE_ENVIRONMENT
                        value: 'Production'
                  resources:
                      requests:
                          memory: '128Mi'
                          cpu: '100m'
                      limits:
                          memory: '256Mi'
                          cpu: '500m'

Цей Deployment:

• Створює 3 репліки Pod з образом mcr.microsoft.com/dotnet/samples:aspnetapp
• Використовує rolling update з обережними налаштуваннями (максимум 1 недоступний Pod)
• Зберігає історію 10 останніх версій для rollback
• Чекає 5 секунд після готовності Pod перед продовженням оновлення
• Має таймаут 600 секунд для оновлення

Створення першого Deployment

Тепер створимо реальний Deployment та подивимося, як він працює.

Крок 1: Створення YAML маніфесту

Створіть файл nginx-deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
    name: nginx-deployment
    labels:
        app: nginx
spec:
    replicas: 3
    selector:
        matchLabels:
            app: nginx
    template:
        metadata:
            labels:
                app: nginx
        spec:
            containers:
                - name: nginx
                  image: nginx:1.27
                  ports:
                      - containerPort: 80

Крок 2: Застосування маніфесту

Застосуйте маніфест до кластера:

Крок 3: Перевірка створеного Deployment

Переглянемо список Deployment:

Що означають колонки:

• NAME: Ім'я Deployment (з metadata.name)
• READY: 3/3 — 3 з 3 реплік готові до роботи (стан Ready)
• UP-TO-DATE: 3 — 3 репліки відповідають поточній версії шаблону (актуальний образ, змінні оточення тощо)
• AVAILABLE: 3 — 3 репліки доступні для обслуговування трафіку (пройшли readiness probe, якщо він налаштований)
• AGE: Час з моменту створення Deployment

Крок 4: Перевірка створених Pod

Deployment автоматично створив Pod. Подивимося на них:

Структура імені Pod:

Ім'я Pod складається з трьох частин: nginx-deployment-7d6b8c9f4d-8xk2p

1. nginx-deployment — ім'я Deployment
2. 7d6b8c9f4d — хеш ReplicaSet (унікальний ідентифікатор версії шаблону Pod)
3. 8xk2p — унікальний суфікс Pod (генерується випадково)

Це дозволяє легко ідентифікувати, до якого Deployment належить Pod, та яку версію шаблону він використовує.

Крок 5: Детальна інформація про Deployment

Переглянемо детальну інформацію:

Тут ви бачите:

• Конфігурацію Deployment (replicas, selector, strategy)
• Шаблон Pod (образ, порти)
• Умови (Conditions) — стан Deployment
• Події (Events) — що відбувалося з Deployment (створення ReplicaSet, масштабування)

ReplicaSet: проміжний шар між Deployment та Pod

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

Що таке ReplicaSet

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

Коли ви створюєте Deployment, він автоматично створює ReplicaSet:

@startuml
skinparam style plain
skinparam backgroundColor #ffffff

actor "Користувач" as user
participant "kubectl" as kubectl
participant "API Server" as api
participant "Deployment Controller" as dc
participant "ReplicaSet Controller" as rsc
participant "Scheduler" as sched
participant "Kubelet" as kubelet

user -> kubectl: kubectl apply -f deployment.yaml
kubectl -> api: Створити Deployment
api -> dc: Подія: новий Deployment
activate dc
dc -> api: Створити ReplicaSet
deactivate dc

api -> rsc: Подія: новий ReplicaSet
activate rsc
rsc -> api: Створити Pod 1
rsc -> api: Створити Pod 2
rsc -> api: Створити Pod 3
deactivate rsc

api -> sched: Подія: нові Pod
activate sched
sched -> api: Призначити Pod вузлам
deactivate sched

api -> kubelet: Подія: Pod призначено вузлу
activate kubelet
kubelet -> kubelet: Завантажити образ
kubelet -> kubelet: Запустити контейнер
kubelet -> api: Pod Running
deactivate kubelet

note right of dc
  Deployment Controller
  створює та керує
  ReplicaSet
end note

note right of rsc
  ReplicaSet Controller
  створює та керує
  Pod
end note

@enduml

Навіщо потрібен ReplicaSet

ReplicaSet виконує дві ключові функції:

1. Підтримка кількості реплік — якщо Pod падає, ReplicaSet створює новий
2. Версіонування для rolling updates — при оновленні Deployment створює новий ReplicaSet, а старий залишається для rollback

Переглянемо ReplicaSet, створений нашим Deployment:

Що означають колонки:

• NAME: Ім'я ReplicaSet (ім'я Deployment + хеш шаблону Pod)
• DESIRED: Бажана кількість Pod (з spec.replicas Deployment)
• CURRENT: Поточна кількість Pod (скільки насправді існує)
• READY: Кількість готових Pod (стан Ready)
• AGE: Час з моменту створення ReplicaSet

Self-healing у дії

Тепер продемонструємо головну перевагу Deployment — автоматичне відновлення (self-healing).

Експеримент: видалення Pod

Видалимо один Pod вручну та подивимося, що станеться:

Одразу перевіримо список Pod:

Бачимо новий Pod з іменем p4k8t у стані ContainerCreating. Що сталося?

1. Ми видалили Pod 8xk2p
2. ReplicaSet Controller виявив, що реплік менше, ніж задано (2 < 3)
3. ReplicaSet автоматично створив новий Pod p4k8t
4. Scheduler призначив Pod вузлу
5. Kubelet завантажує образ та запускає контейнер

Через кілька секунд:

Знову три репліки! Це і є self-healing — система сама усуває розбіжності між бажаним станом (replicas: 3) та поточним станом (2 працюючі Pod).

Візуалізація reconciliation loop

Давайте детально розглянемо, як працює цикл узгодження при видаленні Pod:

@startuml
skinparam style plain
skinparam backgroundColor #ffffff

participant "ReplicaSet\nController" as rsc
participant "API Server" as api
participant "etcd" as etcd
participant "Scheduler" as sched
participant "Kubelet" as kubelet

== Початковий стан: 3 Pod працюють ==

rsc -> api: GET /pods?labelSelector=app=nginx
api -> etcd: Читати Pod
etcd --> api: 3 Pod (Running)
api --> rsc: 3 Pod знайдено
rsc -> rsc: Порівняти: desired=3, current=3\n✓ Стан узгоджено

== Користувач видаляє Pod ==

note over api: kubectl delete pod nginx-xxx
api -> etcd: Видалити Pod nginx-xxx
etcd --> api: OK

== Наступна ітерація reconciliation loop ==

rsc -> api: GET /pods?labelSelector=app=nginx
api -> etcd: Читати Pod
etcd --> api: 2 Pod (Running)
api --> rsc: 2 Pod знайдено
rsc -> rsc: Порівняти: desired=3, current=2\n✗ Розбіжність виявлено!

rsc -> api: POST /pods (створити новий Pod)
api -> etcd: Зберегти новий Pod
etcd --> api: OK
api --> rsc: Pod створено

== Scheduler призначає Pod вузлу ==

api -> sched: Подія: новий Pod без вузла
sched -> api: PATCH /pods/nginx-new (nodeName=node-1)
api -> etcd: Оновити Pod
etcd --> api: OK

== Kubelet запускає Pod ==

api -> kubelet: Подія: Pod призначено node-1
kubelet -> kubelet: Завантажити образ nginx:1.27
kubelet -> kubelet: Запустити контейнер
kubelet -> api: PATCH /pods/nginx-new (status=Running)
api -> etcd: Оновити статус Pod
etcd --> api: OK

== Наступна ітерація reconciliation loop ==

rsc -> api: GET /pods?labelSelector=app=nginx
api -> etcd: Читати Pod
etcd --> api: 3 Pod (Running)
api --> rsc: 3 Pod знайдено
rsc -> rsc: Порівняти: desired=3, current=3\n✓ Стан узгоджено

note right of rsc
  Reconciliation loop
  виконується кожні
  5-10 секунд
end note

@enduml

Ключові моменти:

1. Постійний моніторинг — ReplicaSet Controller не чекає на події. Він постійно (кожні 5-10 секунд) перевіряє стан Pod.
2. Декларативність — контролер не знає, чому Pod зникли (видалення, збій вузла, OOMKilled). Він просто бачить розбіжність між бажаним та поточним станом і усуває її.
3. Ідемпотентність — якщо стан уже узгоджено, контролер нічого не робить. Це безпечно викликати reconciliation багато разів.
4. Розподілена робота — ReplicaSet Controller створює Pod, Scheduler призначає вузол, Kubelet запускає контейнер. Кожен компонент відповідає за свою частину.

Масштабування Deployment

Одна з найважливіших можливостей Deployment — масштабування (scaling). Це зміна кількості реплік Pod для адаптації до навантаження.

Навіщо потрібне масштабування

Уявіть, що ваш веб-застосунок отримує різне навантаження протягом дня:

• Ніч (02:00-06:00): 100 запитів/хвилину — достатньо 2 реплік
• День (09:00-18:00): 1000 запитів/хвилину — потрібно 5 реплік
• Пікове навантаження (12:00-13:00): 5000 запитів/хвилину — потрібно 10 реплік

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

Три способи масштабування

Kubernetes надає три способи змінити кількість реплік Deployment:

Розглянемо кожен спосіб детально.

Спосіб 1: kubectl scale

Найпростіший спосіб — команда kubectl scale:

Перевіримо результат:

Kubernetes створив 2 нові Pod (x2n9k та q7m4p) для досягнення бажаної кількості 5 реплік.

Через кілька секунд:

Тепер усі 5 реплік працюють.

Зменшення кількості реплік:

Так само легко зменшити кількість реплік:

Kubernetes видаляє 3 зайві Pod. Статус Terminating означає, що Pod отримав сигнал завершення (SIGTERM) і має 30 секунд (за замовчуванням) для graceful shutdown.

Переваги kubectl scale:

• Швидкість — одна команда, миттєвий результат
• Простота — не потрібно редагувати файли
• Ідеально для експериментів — швидко збільшити/зменшити репліки для тестування

Недоліки kubectl scale:

• Не зберігається у Git — зміна не відображена у YAML файлах
• Можна забути — якщо пізніше застосуєте старий YAML з replicas: 3, масштабування скасується
• Не підходить для production — краще використовувати декларативний підхід (YAML)

Спосіб 2: Редагування YAML та kubectl apply

Декларативний підхід — змінюєте YAML файл та застосовуєте його:

Крок 1: Відкрийте nginx-deployment.yaml та змініть replicas:

apiVersion: apps/v1
kind: Deployment
metadata:
    name: nginx-deployment
spec:
    replicas: 7 # ← Було 3, стало 7
    selector:
        matchLabels:
            app: nginx
    template:
        metadata:
            labels:
                app: nginx
        spec:
            containers:
                - name: nginx
                  image: nginx:1.27
                  ports:
                      - containerPort: 80

Крок 2: Застосуйте зміни:

Зверніть увагу на слово configured (а не created). Це означає, що Deployment уже існував, і Kubernetes застосував зміни.

Крок 3: Перевірте результат:

Тепер працює 7 реплік.

Переваги kubectl apply:

• Декларативність — YAML файл — це єдине джерело правди (single source of truth)
• Версійний контроль — зміни зберігаються у Git, можна відстежити історію
• Відтворюваність — можна застосувати той самий YAML на іншому кластері
• Production-ready — рекомендований підхід для production

Недоліки kubectl apply:

• Повільніше — потрібно редагувати файл, зберегти, застосувати
• Потрібен локальний файл — якщо ви на іншій машині без файлів, доведеться спочатку отримати YAML

spec:
    replicas: 4 # ← Змініть на потрібне значення

::

Візуалізація процесу масштабування

Давайте подивимося, що відбувається всередині Kubernetes при масштабуванні з 3 до 5 реплік:

@startuml
skinparam style plain
skinparam backgroundColor #ffffff

participant "kubectl" as kubectl
participant "API Server" as api
participant "etcd" as etcd
participant "Deployment\nController" as dc
participant "ReplicaSet\nController" as rsc
participant "Scheduler" as sched
participant "Kubelet\n(node-1)" as kubelet1
participant "Kubelet\n(node-2)" as kubelet2

== Користувач виконує масштабування ==

kubectl -> api: PATCH /deployments/nginx-deployment\n{spec: {replicas: 5}}
api -> etcd: Оновити Deployment (replicas: 3 → 5)
etcd --> api: OK
api --> kubectl: deployment.apps/nginx-deployment scaled

== Deployment Controller виявляє зміну ==

api -> dc: Подія: Deployment змінено
activate dc
dc -> api: GET /replicasets?owner=nginx-deployment
api -> etcd: Читати ReplicaSet
etcd --> api: ReplicaSet nginx-xxx (replicas: 3)
api --> dc: ReplicaSet знайдено

dc -> api: PATCH /replicasets/nginx-xxx\n{spec: {replicas: 5}}
api -> etcd: Оновити ReplicaSet (replicas: 3 → 5)
etcd --> api: OK
deactivate dc

== ReplicaSet Controller виявляє зміну ==

api -> rsc: Подія: ReplicaSet змінено
activate rsc
rsc -> api: GET /pods?labelSelector=app=nginx
api -> etcd: Читати Pod
etcd --> api: 3 Pod (Running)
api --> rsc: 3 Pod знайдено

rsc -> rsc: Порівняти: desired=5, current=3\nПотрібно створити 2 Pod

rsc -> api: POST /pods (Pod 4)
api -> etcd: Зберегти Pod 4
etcd --> api: OK

rsc -> api: POST /pods (Pod 5)
api -> etcd: Зберегти Pod 5
etcd --> api: OK
deactivate rsc

== Scheduler призначає Pod вузлам ==

api -> sched: Подія: 2 нові Pod без вузла
activate sched
sched -> api: GET /nodes
api -> etcd: Читати вузли
etcd --> api: node-1 (CPU: 50%), node-2 (CPU: 30%)
api --> sched: 2 вузли доступні

sched -> sched: Вибрати вузли:\nPod 4 → node-2 (менше навантаження)\nPod 5 → node-1

sched -> api: PATCH /pods/nginx-xxx-4 (nodeName=node-2)
api -> etcd: Оновити Pod 4
etcd --> api: OK

sched -> api: PATCH /pods/nginx-xxx-5 (nodeName=node-1)
api -> etcd: Оновити Pod 5
etcd --> api: OK
deactivate sched

== Kubelet запускають Pod ==

api -> kubelet2: Подія: Pod 4 призначено node-2
activate kubelet2
kubelet2 -> kubelet2: Завантажити образ nginx:1.27
kubelet2 -> kubelet2: Запустити контейнер
kubelet2 -> api: PATCH /pods/nginx-xxx-4\n(status=Running)
api -> etcd: Оновити статус Pod 4
etcd --> api: OK
deactivate kubelet2

api -> kubelet1: Подія: Pod 5 призначено node-1
activate kubelet1
kubelet1 -> kubelet1: Образ вже є (кешовано)
kubelet1 -> kubelet1: Запустити контейнер
kubelet1 -> api: PATCH /pods/nginx-xxx-5\n(status=Running)
api -> etcd: Оновити статус Pod 5
etcd --> api: OK
deactivate kubelet1

note right of dc
  Весь процес займає
  5-15 секунд залежно від:
  - Швидкості завантаження образу
  - Доступності ресурсів
  - Швидкості старту застосунку
end note

@enduml

Ключові етапи масштабування:

1. Оновлення Deployment — користувач змінює replicas через kubectl
2. Deployment Controller — виявляє зміну та оновлює ReplicaSet
3. ReplicaSet Controller — виявляє розбіжність (3 < 5) та створює 2 нові Pod
4. Scheduler — призначає нові Pod вузлам з найменшим навантаженням
5. Kubelet — завантажує образи та запускає контейнери
6. Готовність — Pod переходять у стан Running та стають доступними

Весь процес повністю автоматичний — ви лише змінюєте одне число (replicas), а Kubernetes виконує всю роботу.

Практичний приклад: ASP.NET Core TodoApi з Deployment

Тепер створимо реальний застосунок ASP.NET Core та розгорнемо його у Kubernetes через Deployment. Це буде простий TodoApi з трьома репліками.

Архітектура застосунку

Наш TodoApi матиме наступну структуру:

@startuml
skinparam style plain
skinparam backgroundColor #ffffff

package "Kubernetes Cluster" #f8f9fa {
    component "Deployment\n(todoapi)" as dep #e3f2fd {
        [replicas: 3]
        [image: todoapi:1.0.0]
    }

    component "ReplicaSet\n(todoapi-abc123)" as rs #fff3e0 {
        [replicas: 3]
    }

    package "Pods" #e8f5e9 {
        component "Pod 1\n10.244.1.10" as p1 {
            [todoapi:1.0.0]
            [Port: 8080]
        }
        component "Pod 2\n10.244.1.11" as p2 {
            [todoapi:1.0.0]
            [Port: 8080]
        }
        component "Pod 3\n10.244.1.12" as p3 {
            [todoapi:1.0.0]
            [Port: 8080]
        }
    }
}

actor "Користувач" as user

dep --> rs : manages
rs --> p1 : creates
rs --> p2 : creates
rs --> p3 : creates

user --> p1 : HTTP GET /todos
user --> p2 : HTTP POST /todos
user --> p3 : HTTP GET /todos/1

note right of dep
    Deployment гарантує:
    - 3 репліки завжди працюють
    - Автоматичне відновлення
    - Можливість масштабування
end note

note bottom of p1
    Кожен Pod — незалежна
    копія застосунку з власною
    пам'яттю та IP-адресою
end note

@enduml

Крок 1: Створення ASP.NET Core Minimal API

Створимо простий TodoApi з використанням ASP.NET Core Minimal API (без Entity Framework для простоти):

Структура проєкту:

TodoApi/
├── Program.cs
├── TodoApi.csproj
├── Dockerfile
└── k8s/
    └── deployment.yaml

Program.cs:

using System.Collections.Concurrent;
using Scalar.AspNetCore;

var builder = WebApplication.CreateBuilder(args);

// Додаємо підтримку OpenAPI та Scalar
builder.Services.AddOpenApi();

// In-memory сховище (для демонстрації)
var todos = new ConcurrentDictionary<int, Todo>();
var nextId = 1;

var app = builder.Build();

// Scalar UI (доступний лише у Development)
if (app.Environment.IsDevelopment())
{
    app.MapOpenApi();
    app.MapScalarApiReference();
}

// Health check endpoint (для Kubernetes)
app.MapGet("/health", () => Results.Ok(new { status = "healthy", timestamp = DateTime.UtcNow }))
   .WithName("HealthCheck")
   .WithOpenApi();

// GET /todos - отримати всі завдання
app.MapGet("/todos", () =>
{
    var hostname = Environment.GetEnvironmentVariable("HOSTNAME") ?? "unknown";
    return Results.Ok(new
    {
        todos = todos.Values.ToList(),
        servedBy = hostname,
        count = todos.Count
    });
})
.WithName("GetAllTodos")
.WithOpenApi();

// GET /todos/{id} - отримати завдання за ID
app.MapGet("/todos/{id:int}", (int id) =>
{
    if (todos.TryGetValue(id, out var todo))
    {
        var hostname = Environment.GetEnvironmentVariable("HOSTNAME") ?? "unknown";
        return Results.Ok(new { todo, servedBy = hostname });
    }
    return Results.NotFound(new { error = "Todo not found", id });
})
.WithName("GetTodoById")
.WithOpenApi();

// POST /todos - створити нове завдання
app.MapPost("/todos", (CreateTodoRequest request) =>
{
    var id = Interlocked.Increment(ref nextId);
    var todo = new Todo
    {
        Id = id,
        Title = request.Title,
        IsCompleted = false,
        CreatedAt = DateTime.UtcNow
    };

    todos[id] = todo;

    var hostname = Environment.GetEnvironmentVariable("HOSTNAME") ?? "unknown";
    return Results.Created($"/todos/{id}", new { todo, servedBy = hostname });
})
.WithName("CreateTodo")
.WithOpenApi();

// PUT /todos/{id} - оновити завдання
app.MapPut("/todos/{id:int}", (int id, UpdateTodoRequest request) =>
{
    if (!todos.TryGetValue(id, out var todo))
    {
        return Results.NotFound(new { error = "Todo not found", id });
    }

    todo.Title = request.Title ?? todo.Title;
    todo.IsCompleted = request.IsCompleted ?? todo.IsCompleted;

    var hostname = Environment.GetEnvironmentVariable("HOSTNAME") ?? "unknown";
    return Results.Ok(new { todo, servedBy = hostname });
})
.WithName("UpdateTodo")
.WithOpenApi();

// DELETE /todos/{id} - видалити завдання
app.MapDelete("/todos/{id:int}", (int id) =>
{
    if (todos.TryRemove(id, out var todo))
    {
        var hostname = Environment.GetEnvironmentVariable("HOSTNAME") ?? "unknown";
        return Results.Ok(new { message = "Todo deleted", todo, servedBy = hostname });
    }
    return Results.NotFound(new { error = "Todo not found", id });
})
.WithName("DeleteTodo")
.WithOpenApi();

app.Run();

// Моделі
record Todo
{
    public int Id { get; set; }
    public required string Title { get; set; }
    public bool IsCompleted { get; set; }
    public DateTime CreatedAt { get; set; }
}

record CreateTodoRequest(string Title);
record UpdateTodoRequest(string? Title, bool? IsCompleted);

TodoApi.csproj:

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.OpenApi" Version="10.*" />
    <PackageReference Include="Scalar.AspNetCore" Version="2.*" />
  </ItemGroup>

</Project>

Крок 2: Створення Dockerfile

Створимо multi-stage Dockerfile для оптимізації розміру образу:

Dockerfile:

# Stage 1: Build
FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
WORKDIR /src

# Копіюємо .csproj та відновлюємо залежності (кешування шарів)
COPY TodoApi.csproj .
RUN dotnet restore

# Копіюємо решту файлів та збираємо
COPY . .
RUN dotnet publish -c Release -o /app/publish

# Stage 2: Runtime
FROM mcr.microsoft.com/dotnet/aspnet:10.0 AS runtime
WORKDIR /app

# Копіюємо зібраний застосунок
COPY --from=build /app/publish .

# Відкриваємо порт 8080 (non-privileged port)
EXPOSE 8080

# Налаштовуємо ASP.NET Core для прослуховування на порту 8080
ENV ASPNETCORE_URLS=http://+:8080

# Запускаємо застосунок
ENTRYPOINT ["dotnet", "TodoApi.dll"]

Крок 3: Збірка та завантаження образу у Minikube

Тепер зберемо Docker образ та завантажимо його у Minikube:

Перевіримо, що образ створено:

Крок 4: Створення Deployment YAML

Створимо маніфест Deployment для TodoApi:

k8s/deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
    name: todoapi
    labels:
        app: todoapi
        version: '1.0.0'
spec:
    # Три репліки для балансування навантаження
    replicas: 3

    # Селектор для вибору Pod
    selector:
        matchLabels:
            app: todoapi

    # Шаблон Pod
    template:
        metadata:
            labels:
                app: todoapi
                version: '1.0.0'
        spec:
            containers:
                - name: todoapi
                  image: todoapi:1.0.0
                  imagePullPolicy: Never # Використовувати локальний образ (для Minikube)

                  ports:
                      - name: http
                        containerPort: 8080
                        protocol: TCP

                  # Змінні оточення
                  env:
                      - name: ASPNETCORE_ENVIRONMENT
                        value: 'Production'
                      - name: ASPNETCORE_URLS
                        value: 'http://+:8080'

                  # Ресурси (requests та limits)
                  resources:
                      requests:
                          memory: '128Mi'
                          cpu: '100m'
                      limits:
                          memory: '256Mi'
                          cpu: '500m'

                  # Liveness probe - перевірка, чи застосунок живий
                  livenessProbe:
                      httpGet:
                          path: /health
                          port: 8080
                      initialDelaySeconds: 10
                      periodSeconds: 10
                      timeoutSeconds: 5
                      failureThreshold: 3

                  # Readiness probe - перевірка, чи застосунок готовий приймати трафік
                  readinessProbe:
                      httpGet:
                          path: /health
                          port: 8080
                      initialDelaySeconds: 5
                      periodSeconds: 5
                      timeoutSeconds: 3
                      failureThreshold: 3

Розберемо нові поля детально.

Різниця між Liveness та Readiness Probe

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

@startuml
skinparam style plain
skinparam backgroundColor #ffffff

state "Pod Lifecycle" as plc {
    state "Container Starting" as starting #fff3e0
    state "Initializing\n(підключення до БД,\nзавантаження конфігурації)" as init #fff3e0
    state "Ready\n(приймає трафік)" as ready #e8f5e9
    state "Unhealthy\n(тимчасова проблема)" as unhealthy #ffebee
    state "Dead\n(deadlock, crash)" as dead #ffebee
    state "Restarting" as restart #fff3e0

    [*] --> starting
    starting --> init : Container started
    init --> ready : Readiness probe ✓
    ready --> unhealthy : Readiness probe ✗
    unhealthy --> ready : Readiness probe ✓
    ready --> dead : Liveness probe ✗\n(3 рази підряд)
    unhealthy --> dead : Liveness probe ✗\n(3 рази підряд)
    dead --> restart : Kubernetes kills container
    restart --> starting : Container restarted
}

note right of init
    Readiness probe fails
    → Pod не отримує трафік
    → Контейнер НЕ перезапускається
end note

note right of dead
    Liveness probe fails
    → Kubernetes kills container
    → Контейнер перезапускається
end note

@enduml

Приклад сценаріїв:

livenessProbe:
    httpGet:
        path: /health
        port: 8080
    initialDelaySeconds: 5
    periodSeconds: 5

readinessProbe:
    httpGet:
        path: /health
        port: 8080
    initialDelaySeconds: 5
    periodSeconds: 5

livenessProbe:
    initialDelaySeconds: 60 # Достатньо часу для старту
    periodSeconds: 10

readinessProbe:
    initialDelaySeconds: 10 # Швидше виявляє готовність
    periodSeconds: 5

Крок 5: Розгортання у Kubernetes

Перед розгортанням завантажимо наш щойно зібраний образ у кластер Minikube, щоб Kubernetes міг отримати до нього доступ:

Тепер застосуємо маніфест:

Перевіримо стан Deployment:

Бачимо 0/3 — жоден Pod ще не готовий. Це нормально — Pod стартують. Почекаємо кілька секунд:

Тепер усі 3 репліки готові! Переглянемо Pod:

Переглянемо детальну інформацію про один Pod:

Тут ви бачите всю інформацію про Pod: образ, порти, ресурси, probes, змінні оточення та події.

Крок 6: Тестування API через port-forward

Щоб протестувати API, використаємо kubectl port-forward для перенаправлення трафіку з локальної машини на Pod:

Тепер API доступний на http://localhost:8080. Відкрийте новий термінал та протестуйте:

Зверніть увагу на поле servedBy — кожен запит обробляється різним Pod! Це демонструє, що kubectl port-forward автоматично балансує навантаження між репліками.

# Створюємо todo (обробляє Pod 1)
curl -X POST http://localhost:8080/todos -d '{"title":"Test"}'
# Відповідь: servedBy: todoapi-xxx-pod1

# Запитуємо список (обробляє Pod 2)
curl http://localhost:8080/todos
# Відповідь: servedBy: todoapi-xxx-pod2, todos: [] (порожньо!)

Крок 7: Тестування self-healing

Тепер продемонструємо self-healing — видалимо один Pod та подивимося, як Deployment автоматично створить новий:

Одразу перевіримо список Pod:

Бачимо новий Pod n8p2r у стані ContainerCreating. Через кілька секунд:

Знову три репліки! Deployment автоматично відновив бажаний стан.

Крок 8: Тестування масштабування

Тепер збільшимо кількість реплік з 3 до 5:

Два нові Pod створюються. Через 10-15 секунд:

Тепер працює 5 реплік! Зменшимо назад до 3:

Два Pod видаляються (статус Terminating). Kubernetes вибрав найновіші Pod для видалення.

Крок 9: Моніторинг ресурсів

Переглянемо, скільки ресурсів використовують Pod:

minikube addons enable metrics-server

Бачимо, що кожен Pod використовує ~2m CPU (0.002 cores) та ~45 MiB пам'яті. Це значно менше за наші limits (500m CPU, 256Mi memory), тому Pod працюють без обмежень.

Крок 10: Перегляд логів

Переглянемо логи одного з Pod:

Якщо хочете стежити за логами в реальному часі (як tail -f):

Щоб переглянути логи всіх Pod одночасно:

Прапорець --tail=10 показує лише останні 10 рядків з кожного Pod.

Очищення ресурсів

Після експериментів видалимо Deployment:

Це автоматично видалить:

• Deployment
• ReplicaSet (створений Deployment)
• Всі Pod (створені ReplicaSet)

Перевіримо:

Все видалено!

kubectl delete -f k8s/deployment.yaml

Практичні завдання

Тепер, коли ви розумієте основи Deployment, виконайте наступні завдання для закріплення знань:

Завдання 1: Deployment з різними образами

Мета: Навчитись створювати Deployment з різними образами та порівнювати їх поведінку.

Завдання:

1. Створіть два Deployment:
   • nginx-deployment з образом nginx:1.27 (3 репліки)
   • httpd-deployment з образом httpd:2.4 (2 репліки)
2. Перевірте, що всі Pod працюють
3. Використайте kubectl port-forward для доступу до кожного Deployment та порівняйте відповіді (nginx показує "Welcome to nginx!", httpd показує "It works!")
4. Видаліть один Pod з кожного Deployment та переконайтесь, що вони автоматично відновлюються

Очікуваний результат:

kubectl get deployments
# NAME               READY   UP-TO-DATE   AVAILABLE   AGE
# nginx-deployment   3/3     3            3           2m
# httpd-deployment   2/2     2            2           2m

kubectl get pods
# NAME                                READY   STATUS    RESTARTS   AGE
# nginx-deployment-xxx-yyy            1/1     Running   0          2m
# nginx-deployment-xxx-zzz            1/1     Running   0          2m
# nginx-deployment-xxx-www            1/1     Running   0          2m
# httpd-deployment-aaa-bbb            1/1     Running   0          2m
# httpd-deployment-aaa-ccc            1/1     Running   0          2m

apiVersion: apps/v1
kind: Deployment
metadata:
    name: nginx-deployment
spec:
    replicas: 3
    selector:
        matchLabels:
            app: nginx
    template:
        metadata:
            labels:
                app: nginx
        spec:
            containers:
                - name: nginx
                  image: nginx:1.27
                  ports:
                      - containerPort: 80

apiVersion: apps/v1
kind: Deployment
metadata:
    name: httpd-deployment
spec:
    replicas: 2
    selector:
        matchLabels:
            app: httpd
    template:
        metadata:
            labels:
                app: httpd
        spec:
            containers:
                - name: httpd
                  image: httpd:2.4
                  ports:
                      - containerPort: 80

# Створення
kubectl apply -f nginx-deployment.yaml
kubectl apply -f httpd-deployment.yaml

# Перевірка
kubectl get deployments
kubectl get pods

# Тестування nginx
kubectl port-forward deployment/nginx-deployment 8080:80
curl http://localhost:8080
# Відповідь: Welcome to nginx!

# Тестування httpd (у новому терміналі)
kubectl port-forward deployment/httpd-deployment 8081:80
curl http://localhost:8081
# Відповідь: <html><body><h1>It works!</h1></body></html>

# Тестування self-healing
kubectl delete pod <nginx-pod-name>
kubectl get pods -w  # Спостерігайте за створенням нового Pod

# Очищення
kubectl delete deployment nginx-deployment httpd-deployment

Завдання 2: Експерименти з ресурсами

Мета: Зрозуміти, як працюють resource requests та limits.

Завдання:

1. Створіть Deployment з дуже низькими limits:

   resources:
       limits:
           memory: '10Mi'
           cpu: '10m'
   

2. Спостерігайте, що відбувається з Pod (можливо, OOMKilled)
3. Поступово збільшуйте limits, поки Pod не стане стабільним
4. Використайте kubectl top pods для моніторингу реального споживання ресурсів

Очікуваний результат:

Ви побачите, як Pod з недостатніми ресурсами постійно перезапускаються (CrashLoopBackOff або OOMKilled), а після збільшення limits стають стабільними.

apiVersion: apps/v1
kind: Deployment
metadata:
    name: low-resources-test
spec:
    replicas: 1
    selector:
        matchLabels:
            app: test
    template:
        metadata:
            labels:
                app: test
        spec:
            containers:
                - name: nginx
                  image: nginx:1.27
                  resources:
                      limits:
                          memory: '10Mi' # Занадто мало для nginx!
                          cpu: '10m'
                      requests:
                          memory: '5Mi'
                          cpu: '5m'

# Створення
kubectl apply -f low-resources-deployment.yaml

# Спостереження (Pod буде постійно перезапускатись)
kubectl get pods -w
# NAME                                 READY   STATUS      RESTARTS   AGE
# low-resources-test-xxx-yyy           0/1     OOMKilled   1          10s
# low-resources-test-xxx-yyy           0/1     CrashLoopBackOff   1   20s

# Перегляд причини
kubectl describe pod <pod-name>
# Last State:     Terminated
#   Reason:       OOMKilled
#   Exit Code:    137

# Збільшення ресурсів
kubectl edit deployment low-resources-test
# Змініть memory limit на 64Mi

# Тепер Pod має стартувати успішно
kubectl get pods
# NAME                                 READY   STATUS    RESTARTS   AGE
# low-resources-test-xxx-zzz           1/1     Running   0          15s

# Перевірка реального споживання
kubectl top pods
# NAME                                 CPU(cores)   MEMORY(bytes)
# low-resources-test-xxx-zzz           1m           8Mi

# Очищення
kubectl delete deployment low-resources-test

Завдання 3: Масштабування під навантаженням

Мета: Навчитись масштабувати застосунок залежно від навантаження.

Завдання:

1. Розгорніть TodoApi з 2 репліками
2. Використайте kubectl port-forward та інструмент навантаження (наприклад, ab або wrk) для генерації трафіку
3. Під час навантаження збільште кількість реплік до 5
4. Спостерігайте за розподілом навантаження через логи (kubectl logs)
5. Після завершення тесту зменшіть репліки назад до 2

Очікуваний результат:

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

# Розгортання TodoApi (використовуйте YAML з попереднього прикладу)
kubectl apply -f k8s/deployment.yaml
kubectl scale deployment todoapi --replicas=2

# Port-forward
kubectl port-forward deployment/todoapi 8080:8080 &

# Генерація навантаження (потрібен Apache Bench)
# macOS: brew install httpd
# Ubuntu: sudo apt install apache2-utils
ab -n 1000 -c 10 http://localhost:8080/health

# Під час виконання ab — у новому терміналі:
kubectl scale deployment todoapi --replicas=5

# Спостереження за Pod
kubectl get pods -l app=todoapi -w

# Перегляд логів (побачите, що запити розподіляються між Pod)
kubectl logs -l app=todoapi --tail=20

# Після завершення тесту
kubectl scale deployment todoapi --replicas=2

# Очищення
kubectl delete deployment todoapi

# Встановлення wrk
# macOS: brew install wrk
# Ubuntu: sudo apt install wrk

# Генерація навантаження (10 потоків, 100 з'єднань, 30 секунд)
wrk -t10 -c100 -d30s http://localhost:8080/health

Завдання 4: Налаштування Health Checks

Мета: Навчитись правильно налаштовувати liveness та readiness probes.

Завдання:

1. Створіть Deployment з некоректними health checks (занадто короткий initialDelaySeconds)
2. Спостерігайте за CrashLoopBackOff
3. Виправте налаштування та досягніть стабільного стану
4. Експериментуйте з різними значеннями periodSeconds, timeoutSeconds, failureThreshold

Очікуваний результат:

Ви зрозумієте, як неправильні health checks можуть призвести до постійних перезапусків Pod, та навчитесь підбирати оптимальні значення.

apiVersion: apps/v1
kind: Deployment
metadata:
    name: bad-probes-test
spec:
    replicas: 1
    selector:
        matchLabels:
            app: test
    template:
        metadata:
            labels:
                app: test
        spec:
            containers:
                - name: nginx
                  image: nginx:1.27
                  ports:
                      - containerPort: 80
                  livenessProbe:
                      httpGet:
                          path: /
                          port: 80
                      initialDelaySeconds: 1 # Занадто мало! nginx не встигне стартувати
                      periodSeconds: 2
                      failureThreshold: 2
                  readinessProbe:
                      httpGet:
                          path: /
                          port: 80
                      initialDelaySeconds: 1
                      periodSeconds: 2
                      failureThreshold: 2

# Створення з поганими налаштуваннями
kubectl apply -f bad-probes-deployment.yaml

# Спостереження (Pod буде постійно перезапускатись)
kubectl get pods -w
# NAME                               READY   STATUS    RESTARTS   AGE
# bad-probes-test-xxx-yyy            0/1     Running   0          2s
# bad-probes-test-xxx-yyy            0/1     Running   1          5s
# bad-probes-test-xxx-yyy            0/1     CrashLoopBackOff   1   10s

# Перегляд подій
kubectl describe pod <pod-name>
# Events:
#   Warning  Unhealthy  10s (x3 over 14s)  kubelet  Liveness probe failed: Get "http://10.244.0.15:80/": dial tcp 10.244.0.15:80: connect: connection refused
#   Warning  BackOff    5s (x2 over 10s)   kubelet  Back-off restarting failed container

# Виправлення (збільшення initialDelaySeconds)
kubectl edit deployment bad-probes-test
# Змініть initialDelaySeconds на 10 для обох probes

# Тепер Pod має стартувати успішно
kubectl get pods
# NAME                               READY   STATUS    RESTARTS   AGE
# bad-probes-test-xxx-zzz            1/1     Running   0          15s

# Очищення
kubectl delete deployment bad-probes-test

livenessProbe:
    httpGet:
        path: /
        port: 80
    initialDelaySeconds: 10 # Достатньо часу для старту
    periodSeconds: 10
    timeoutSeconds: 5
    failureThreshold: 3

readinessProbe:
    httpGet:
        path: /
        port: 80
    initialDelaySeconds: 5 # Може бути менше за liveness
    periodSeconds: 5
    timeoutSeconds: 3
    failureThreshold: 3

Завдання 5: Декларативне управління через Git

Мета: Навчитись використовувати Git для версійного контролю Kubernetes маніфестів.

Завдання:

1. Створіть Git репозиторій для Kubernetes маніфестів
2. Додайте Deployment YAML з 3 репліками
3. Зробіть commit та застосуйте через kubectl apply
4. Змініть кількість реплік на 5 у YAML, зробіть commit
5. Застосуйте зміни через kubectl apply
6. Використайте git log для перегляду історії змін
7. Поверніться до попередньої версії через git revert та застосуйте

Очікуваний результат:

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

# Створення Git репозиторію
mkdir k8s-manifests
cd k8s-manifests
git init

# Створення першої версії Deployment
cat > nginx-deployment.yaml <<'YAML'
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.27
          ports:
            - containerPort: 80
YAML

# Commit
git add nginx-deployment.yaml
git commit -m "Initial deployment: 3 replicas"

# Застосування
kubectl apply -f nginx-deployment.yaml

# Перевірка
kubectl get deployments
# NAME               READY   UP-TO-DATE   AVAILABLE   AGE
# nginx-deployment   3/3     3            3           10s

# Зміна кількості реплік
sed -i.bak 's/replicas: 3/replicas: 5/' nginx-deployment.yaml

# Commit
git add nginx-deployment.yaml
git commit -m "Scale up to 5 replicas"

# Застосування
kubectl apply -f nginx-deployment.yaml

# Перевірка
kubectl get deployments
# NAME               READY   UP-TO-DATE   AVAILABLE   AGE
# nginx-deployment   5/5     5            5           1m

# Перегляд історії
git log --oneline
# a1b2c3d Scale up to 5 replicas
# d4e5f6g Initial deployment: 3 replicas

# Повернення до попередньої версії
git revert HEAD --no-edit

# Застосування
kubectl apply -f nginx-deployment.yaml

# Перевірка (знову 3 репліки)
kubectl get deployments
# NAME               READY   UP-TO-DATE   AVAILABLE   AGE
# nginx-deployment   3/3     3            3           2m

# Очищення
kubectl delete -f nginx-deployment.yaml
cd ..
rm -rf k8s-manifests

Резюме

У цій статті ми детально вивчили Deployment — основний ресурс Kubernetes для управління застосунками у production. Ось що ми розглянули:

Ключові висновки

1. Завжди використовуйте Deployment у production — ніколи не створюйте Pod напряму. Deployment надає self-healing, масштабування та rolling updates.
2. Декларативний підхід — описуйте бажаний стан у YAML, а Kubernetes автоматично досягає його. Зберігайте YAML у Git для версійного контролю.
3. Reconciliation loop — фундаментальний принцип Kubernetes. Контролери постійно порівнюють бажаний стан з поточним та усувають розбіжності.
4. ReplicaSet — проміжний шар — Deployment не створює Pod напряму. Він використовує ReplicaSet для підтримки кількості реплік та реалізації rolling updates.
5. Health checks критично важливі — правильно налаштовані liveness та readiness probes гарантують стабільність застосунку. Неправильні налаштування призводять до CrashLoopBackOff.
6. Resource requests та limits — завжди вказуйте ресурси для Pod. Requests використовуються для scheduling, limits запобігають перевитраті ресурсів.
7. Масштабування — це просто — змінити кількість реплік можна однією командою або редагуванням YAML. Kubernetes автоматично створює або видаляє Pod.

Що далі?

У наступній статті "Rolling Updates та управління життєвим циклом Deployment" ми детально розглянемо:

• Як працює rolling update (покрокова візуалізація)
• Стратегії оновлення: RollingUpdate vs Recreate
• Параметри: maxSurge, maxUnavailable, progressDeadlineSeconds, minReadySeconds (з математичними розрахунками)
• Rollback та історія версій
• Оновлення TodoApi з v1.0 на v2.0 з реальними змінами в коді
• Troubleshooting типових проблем

Ви навчитесь виконувати оновлення застосунків без downtime та швидко повертатись до попередніх версій у разі проблем.

Корисні команди

Для швидкого доступу — всі команди, які ми використовували у цій статті:

# Створення Deployment
kubectl apply -f deployment.yaml

# Перегляд Deployment
kubectl get deployments
kubectl get deploy  # скорочена форма

# Детальна інформація
kubectl describe deployment <name>

# Перегляд Pod
kubectl get pods
kubectl get pods -l app=myapp  # з фільтром за міткою

# Детальна інформація про Pod
kubectl describe pod <pod-name>

# Масштабування через kubectl scale
kubectl scale deployment <name> --replicas=5

# Масштабування через kubectl edit
kubectl edit deployment <name>

# Масштабування через kubectl apply
# (змініть replicas у YAML та застосуйте)
kubectl apply -f deployment.yaml

# Логи одного Pod
kubectl logs <pod-name>

# Логи з follow (реальний час)
kubectl logs -f <pod-name>

# Логи всіх Pod з міткою
kubectl logs -l app=myapp --tail=20

# Моніторинг ресурсів
kubectl top pods
kubectl top pods -l app=myapp

# Port-forward на Deployment
kubectl port-forward deployment/<name> 8080:8080

# Port-forward на конкретний Pod
kubectl port-forward pod/<pod-name> 8080:8080

# Тестування через curl
curl http://localhost:8080/health

# Видалення Deployment (також видаляє ReplicaSet та Pod)
kubectl delete deployment <name>

# Видалення через файл
kubectl delete -f deployment.yaml

# Видалення всіх ресурсів з міткою
kubectl delete all -l app=myapp

# Перегляд подій
kubectl get events --sort-by=.metadata.creationTimestamp

# Виконання команди всередині Pod
kubectl exec -it <pod-name> -- /bin/bash

# Копіювання файлів з/до Pod
kubectl cp <pod-name>:/path/to/file ./local-file
kubectl cp ./local-file <pod-name>:/path/to/file

Додаткові ресурси

Наступна стаття: Rolling Updates та управління життєвим циклом Deployment