Модуль 1.3: Що таке Kubernetes?

Складність: [ШВИДКО] — високорівневий огляд

Час на проходження: 30-35 хвилин

Пререквізити: Модуль 1 (Контейнери), Модуль 2 (Docker)

Що ви зможете зробити

Після цього модуля ви зможете:

Оцінити, чи виправдовує певне навантаження складність Kubernetes порівняно з простішою моделлю розгортання
Діагностувати, який компонент control plane вийшов з ладу, коли операції кластера (як-от планування або масштабування) перестають працювати
Спрогнозувати вплив відмови вузла (node) на запущені навантаження та реакцію control plane
Оцінити компроміси між керованим Kubernetes (EKS/GKE/AKS) та самостійно керованими кластерами для продуктивних середовищ

Чому це важливо

У 2017 році розгортання одного з великих ритейлерів на одному сервері вийшло з ладу під вагою раптового сплеску трафіку на Black Friday. Оскільки у них не було автоматичної оркестрації, черговим інженерам довелося гарячково підключатися через SSH до резервних серверів, вручну завантажувати Docker-образи та перезапускати сервіси, поки компанія втрачала тисячі доларів за хвилину через втрачені продажі.

Ви знаєте, що таке контейнери. Ви можете створювати та запускати їх за допомогою Docker. Але Docker запускає контейнери на ОДНІЙ машині. Що станеться, коли вам знадобляться:

Сотні контейнерів?
Висока доступність (без простоїв)?
Автоматичне масштабування?
Кілька машин?

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

Проблема: Контейнери у масштабі

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

┌─────────────────────────────────────────────────────────────┐
│              ОБМЕЖЕННЯ ОДНІЄЇ МАШИНИ                        │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Ваш Docker-хост:                                           │
│  ┌────────────────────────────────────────────────────┐    │
│  │  🐳 Container 1  🐳 Container 2  🐳 Container 3    │    │
│  │  🐳 Container 4  🐳 Container 5  🐳 Container 6    │    │
│  └────────────────────────────────────────────────────┘    │
│                                                             │
│  Проблеми:                                                  │
│  ❌ Машина "вмирає" = ВСІ контейнери "вмирають"            │
│  ❌ Потрібно більше потужності? Купуйте більшу машину      │
│  ❌ Немає автоматичного відновлення                        │
│  ❌ Ручне балансування навантаження                        │
│  ❌ Оновлення потребують простою                            │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Що потрібно для продакшну

✅ Запуск контейнерів на кількох машинах
✅ Автоматичний перезапуск у разі падіння контейнерів
✅ Автоматичне розміщення (яка машина має вільне місце?)
✅ Балансування навантаження між контейнерами
✅ Ковзні оновлення (rolling updates) без простоїв
✅ Масштабування вгору/вниз залежно від попиту
✅ Самовідновлення, коли щось ламається

Це — оркестрація контейнерів, і Kubernetes є галузевим стандартом.

Зупиніться та подумайте: У вас є 200 контейнерів, які працюють на 15 серверах. О 3 годині ночі виходить з ладу жорсткий диск одного з серверів. При ручному налаштуванні хтось отримує сповіщення, заходить через SSH, з’ясовує, що працювало на цьому сервері, і вручну розгортає ці контейнери в іншому місці. З Kubernetes система виявляє збій, точно знає, що саме працювало, і автоматично переносить ці контейнери на справні сервери — і все це до того, як ваш черговий інженер встигне прокинутися. У цьому і полягає цінність оркестрації.

Що таке Kubernetes?

Kubernetes (K8s) — це платформа для оркестрації контейнерів з відкритим кодом. Він:

Керує розгортанням контейнерів на кількох машинах
Гарантує бажаний стан — якщо щось ламається, K8s це виправляє
Керує мережею — контейнери знаходять один одного та спілкуються між собою
Керує сховищем — забезпечує постійні дані для застосунків зі станом (stateful)
Автоматизує операції — масштабування, оновлення, відновлення

Аналогія: Робота аеропорту

┌─────────────────────────────────────────────────────────────┐
│              KUBERNETES ЯК РОБОТА АЕРОПОРТУ                 │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Вежа керування аеропорту = Kubernetes Control Plane        │
│  - Призначає літаки до гейтів (планує Pods на вузли)        │
│  - Моніторить всю активність (відстежує стан кластера)      │
│  - Реагує на інциденти (перезапускає контейнери, що впали)  │
│                                                             │
│  Гейти/Злітні смуги = Worker Nodes                          │
│  - Фізична інфраструктура, де відбувається робота           │
│  - Вежа призначає, гейти виконують                          │
│                                                             │
│  Літаки = Pods (контейнери)                                 │
│  - Прибувають, відлітають, обслуговуються                   │
│  - Вежа відстежує статус кожного                            │
│                                                             │
│  Авіакомпанії = Простори імен (Namespaces)                  │
│  - Delta використовує гейти 1-10                            │
│  - United використовує гейти 11-20                          │
│  - Ізоляція між орендарями                                  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Архітектура Kubernetes (спрощена)

┌─────────────────────────────────────────────────────────────┐
│              КЛАСТЕР KUBERNETES                             │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌─────────────────────────────────────────────────────┐   │
│  │           CONTROL PLANE (Майстер-вузол)             │   │
│  │  ┌───────────┐  ┌──────────┐  ┌───────────────┐    │   │
│  │  │ API       │  │Scheduler │  │ Controller    │    │   │
│  │  │ Server    │  │          │  │ Manager       │    │   │
│  │  └───────────┘  └──────────┘  └───────────────┘    │   │
│  │  ┌───────────────────────────────────────────┐     │   │
│  │  │              etcd (база даних)              │     │   │
│  │  └───────────────────────────────────────────┘     │   │
│  └─────────────────────────────────────────────────────┘   │
│                          │                                  │
│                          ▼                                  │
│  ┌─────────────────────────────────────────────────────┐   │
│  │                   РОБОЧІ ВУЗЛИ                      │   │
│  │                                                     │   │
│  │  ┌──────────────┐  ┌──────────────┐  ┌──────────┐  │   │
│  │  │   Вузол 1    │  │   Вузол 2    │  │  Вузол 3  │  │   │
│  │  │ ┌──┐ ┌──┐    │  │ ┌──┐ ┌──┐    │  │ ┌──┐     │  │   │
│  │  │ │P1│ │P2│    │  │ │P3│ │P4│    │  │ │P5│     │  │   │
│  │  │ └──┘ └──┘    │  │ └──┘ └──┘    │  │ └──┘     │  │   │
│  │  └──────────────┘  └──────────────┘  └──────────┘  │   │
│  │                                                     │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  P1-P5 = Pods (ваші контейнери)                            │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Зв’язок з Модулем 0.1: Пам’ятаєте кухню ресторану з Модуля 0.1? Control plane — це команда менеджерів ресторану. API Server — це стійка адміністратора (всі замовлення проходять через неї), Scheduler — менеджер залу (вирішує, яка кухня обробляє яке замовлення), etcd — журнал замовлень (записує все), а Controller Manager — супервайзер зміни (стежить, щоб працювала потрібна кількість персоналу).

Компоненти Control Plane

Компонент	Що він робить
API Server	”Вхідні двері” до K8s. Усі команди проходять через нього.
etcd	База даних, що зберігає стан усього кластера.
Scheduler	Вирішує, на якому вузлі (node) запускати кожен Pod.
Controller Manager	Гарантує, що бажаний стан збігається з фактичним.

Зупиніться та подумайте: Якщо весь control plane вийде з ладу (наприклад, впаде API Server), що станеться з контейнерами, які вже працюють на ваших робочих вузлах? Відповідь: Вони продовжать працювати! Робочі вузли виконують останні відомі інструкції. Однак ви не зможете розгорнути оновлення, а якщо Pod впаде, він не буде замінений, поки control plane не відновиться.

Компоненти робочого вузла (Worker Node)

Компонент	Що він робить
kubelet	Агент на кожному вузлі, що керує Pods.
Container Runtime	Безпосередньо запускає контейнери (containerd).
kube-proxy	Керує мережею для сервісів.

Огляд основних концепцій

Pods

Найменша одиниця розгортання. Зазвичай це один контейнер, іноді кілька пов’язаних контейнерів.

# Ви не запускаєте контейнери напряму — ви створюєте Pods
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.25

Deployments

Керують кількома однаковими Pods. Забезпечують оновлення та масштабування.

# "Я хочу завжди мати 3 Pods з nginx"
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25

Services

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

# "Зроби мої Pods з nginx доступними на порту 80"
apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  selector:
    app: nginx
  ports:
  - port: 80
    targetPort: 80

Чому не просто Docker?

Функція	Docker (один хост)	Kubernetes
Кілька вузлів	❌	✅
Автомасштабування	❌	✅
Самовідновлення	❌	✅
Ковзні оновлення	Вручну	✅ Автоматично
Балансування навантаження	Вручну	✅ Вбудовано
Виявлення сервісів	Вручну	✅ Вбудовано
Керування секретами	❌	✅
Ліміти ресурсів	На контейнер	На весь кластер

Docker призначений для запуску контейнерів. Kubernetes — для експлуатації контейнерів у великих масштабах.

Де працює Kubernetes

Хмарні керовані сервіси (найпростіший варіант)

AWS: EKS (Elastic Kubernetes Service)
Google Cloud: GKE (Google Kubernetes Engine)
Azure: AKS (Azure Kubernetes Service)

Хмарні провайдери керують control plane. Ви просто запускаєте свої навантаження.

Самостійне керування

kubeadm: Офіційний інструмент для встановлення K8s
k3s: Полегшений K8s (добре підходить для edge/IoT)
OpenShift: Корпоративний K8s від Red Hat

Ви керуєте всім самостійно.

Повчальна історія: Ціна самостійного керування У 2019 році фінтех-компанія середнього розміру вирішила запустити власний керований кластер Kubernetes на “голому залізі” (bare metal), щоб заощадити на витратах на AWS EKS. Через шість місяців невдале оновлення бази даних etcd пошкодило стан їхнього кластера, що спричинило повну зупинку продуктивного середовища на 14 годин. Вони зрозуміли, що керування високонадійним control plane — це робота на повний робочий день, яка потребує спеціалізованої команди. Вони негайно мігрували на Amazon EKS, сприйнявши плату за керований сервіс як необхідний “страховий поліс” для стабільності свого control plane.

Локальна розробка

kind: Kubernetes у Docker
minikube: Локальний K8s у віртуальній машині або контейнері
Docker Desktop: Включає опцію Kubernetes

Для навчання та розробки.

Візуалізація: Потік запиту

┌─────────────────────────────────────────────────────────────┐
│              ЯК ПРОХОДИТЬ ЗАПИТ У K8S                       │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  1. Користувач запускає команду kubectl                      │
│     ┌─────────────┐                                        │
│     │ kubectl     │──────────────────┐                     │
│     │ apply -f    │                  │                     │
│     │ deploy.yaml │                  ▼                     │
│     └─────────────┘          ┌──────────────┐              │
│                              │  API Server  │              │
│                              └──────┬───────┘              │
│                                     │                       │
│  2. API Server перевіряє та зберігає ▼                       │
│                              ┌──────────────┐              │
│                              │    etcd      │              │
│                              └──────┬───────┘              │
│                                     │                       │
│  3. Scheduler призначає Pod на вузол ▼                       │
│                              ┌──────────────┐              │
│                              │  Scheduler   │              │
│                              └──────┬───────┘              │
│                                     │                       │
│  4. Kubelet на вузлі запускає Pod    ▼                       │
│                              ┌──────────────┐              │
│                              │   kubelet    │              │
│                              │  (на вузлі)  │              │
│                              └──────┬───────┘              │
│                                     │                       │
│  5. Container runtime запускає його  ▼                       │
│                              ┌──────────────┐              │
│                              │  containerd  │──► 🐳 Працює │
│                              └──────────────┘              │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Чи знали ви?

“Kubernetes” у перекладі з грецької означає “керманич” (той, хто керує кораблем). Логотип — це штурвал корабля з 7 спицями, на честь 7 перших розробників.
K8s — це нумеронім. K-[8 літер]-s. Як i18n (internationalization) або a11y (accessibility).
Google запускає все на Kubernetes. Gmail, Пошук, YouTube — все працює на Borg (попередник K8s) або на самому K8s.
Найбільший відомий кластер K8s налічує 15 000 вузлів, на яких працює понад 300 000 Pods (Alibaba).

Поширені помилки

Помилка	Реальність
”K8s замінює Docker”	K8s оркеструє контейнери. Ви все одно використовуєте Docker (або containerd) для створення та запуску образів контейнерів.
”K8s лише для великих компаній”	Невеликі стартапи також використовують K8s. Керовані сервіси роблять control plane доступним для малих команд.
”K8s — це складно”	K8s СПРАВДІ складний, але керовані сервіси беруть на себе більшу частину цієї складності. Ви в основному взаємодієте з його декларативним API.
”K8s вирішує всі проблеми”	K8s — це інфраструктура. Вам все одно потрібно проектувати якісні застосунки. Погано написаний застосунок так само падатиме в K8s.
”Контейнери в K8s повністю безпечні за замовчуванням”	K8s за замовчуванням оптимізований для простоти мережевої взаємодії. Ви повинні активно налаштовувати мережеві політики та RBAC, щоб захистити його.
”Базу даних слід запускати в K8s”	Хоча це можливо, запуск даних зі станом потребує глибокої експертизи. Багато компаній віддають перевагу керованим базам даних (як-от RDS) разом із K8s.
”Перехід на K8s автоматично економить гроші”	K8s покращує щільність ресурсів, але control plane має фіксовані витрати, а час інженерів коштує дорого. Він оптимізує масштаб, а не базову вартість.

Контрольні запитання

Сценарій: Ваш сайт електронної комерції відчуває раптовий сплеск трафіку на 500%. Ваше налаштування Docker-compose на одному величезному екземплярі EC2 досягає максимуму свого процесора і починає розривати з’єднання. Чому Kubernetes краще підходить для вирішення цієї конкретної ситуації?

Відповідь
Kubernetes може автоматично виділити додаткові робочі вузли (worker nodes) і запланувати нові репліки Pods для обробки підвищеного навантаження. На відміну від Docker-налаштування на одній машині, яке обмежене жорсткими лімітами цієї конкретної машини, Kubernetes розподіляє робоче навантаження по масштабованому парку машин. Як тільки сплеск трафіку вщухне, Kubernetes може автоматично масштабуватися назад, щоб заощадити витрати на інфраструктуру.
Сценарій: Ви розгортаєте трирівневий вебзастосунок у кластері Kubernetes. Вам потрібно переконатися, що фронтенд-контейнери завжди можуть спілкуватися з бекенд-контейнерами, навіть якщо бекенд-контейнери падають і перестворюються з абсолютно іншими IP-адресами. Яка концепція Kubernetes гарантує цей стабільний зв’язок?

Відповідь
Концепція Service забезпечує стабільну мережу для Pods. Оскільки Pods ефемерні (тимчасові) і отримують нові IP-адреси при їх перестворенні за допомогою Deployment, покладання безпосередньо на IP-адреси Pods неминуче призведе до збоїв у зв'язку. Service надає єдину статичну IP-адресу та DNS-ім'я, які балансують трафік між усіма справними Pods, що відповідають його селектору, гарантуючи, що фронтенд завжди зможе знайти бекенд.
Сценарій: Молодший інженер випадково видалив єдиний запущений Pod вашого критично важливого сервісу обробки платежів. У чистому середовищі Docker сервіс був би недоступний, поки інженер не перезапустив би його вручну. Якби цим керував Kubernetes Deployment, спрогнозуйте, що саме сталося б далі.

Відповідь
Kubernetes Controller Manager негайно виявив би, що фактичний стан кластера (0 запущених Pods) відрізняється від бажаного стану, визначеного в Deployment (1 запущений Pod). Він автоматично дав би вказівку API Server створити новий Pod замість видаленого. Потім Scheduler призначив би цей новий Pod на доступний робочий вузол, швидко відновивши роботу сервісу без будь-якого втручання людини.
Сценарій: Ваша команда обговорює, чи створювати самостійно керований кластер Kubernetes на віртуальних машинах, чи використовувати Amazon EKS. У вашому стартапі лише два DevOps-інженери. Виходячи з типових вимог до продакшну, чому керований сервіс (EKS) є безпечнішим вибором?

Відповідь
EKS знімає величезний операційний тягар керування компонентами Kubernetes Control Plane, такими як API Server та база даних etcd. Керування високонадійним кластером etcd та виконання оновлень без простоїв потребує спеціалізованої експертизи на повний робочий день. Маючи лише двох інженерів, самостійно керований control plane стає величезною єдиною точкою відмови та операційним ризиком, тоді як EKS надає стійкий керований control plane "з коробки".
Сценарій: Апаратний збій призвів до того, що робочий вузол №3 раптово втратив живлення. На ньому працювало 5 екземплярів Pods вашого вебзастосунку. Діагностуйте, який компонент control plane відповідає за те, щоб помітити цей збій і вжити заходів.

Відповідь
За виявлення збою та вжиття коригувальних заходів відповідає Controller Manager. Зокрема, підкомпонент під назвою Node Controller моніторить "серцебиття" (heartbeat) усіх вузлів. Коли він виявляє, що робочий вузол №3 перестав відповідати, він позначає вузол як недоступний. Потім інші контролери помічають, що бажана кількість Pods більше не забезпечується, що запускає створення нових Pods, які Scheduler розмістить на справних вузлах.
Сценарій: Ви запускаєте kubectl apply -f my-app.yaml для розгортання нової функції, але час очікування команди минає, і вона повертає помилку “connection refused”. Однак ваші панелі моніторингу показують, що робочі вузли та існуючі застосунки цілком справні. Діагностуйте, який саме компонент control plane, найімовірніше, вийшов з ладу.

Відповідь
Майже напевно API Server офлайн або недоступний. API Server діє як єдині вхідні двері для всіх операцій кластера Kubernetes; ваш інструмент `kubectl` спілкується безпосередньо з ним, а не з робочими вузлами чи іншими компонентами control plane. Якщо API Server не працює, ви не можете запитати стан кластера або розгорнути нові ресурси, хоча існуючі запущені навантаження на робочих вузлах продовжуватимуть функціонувати нормально.

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

Завдання: Дослідіть кластер Kubernetes (це огляд того, що буде далі).

# Якщо у вас запущено кластер (kind, minikube або інший):

# 1. Перегляньте вузли вашого кластера
kubectl get nodes
# Вивід покаже машини у вашому кластері

# 2. Перегляньте запущені системні компоненти
kubectl get pods -n kube-system
# Це компоненти, завдяки яким працює K8s

# 3. Перегляньте всі простори імен (це як папки для ресурсів)
kubectl get namespaces

# 4. Створіть щось просте
kubectl run hello --image=nginx --restart=Never
kubectl get pods
# Ви щойно створили Pod!

# 5. Подивіться, що Kubernetes знає про нього
kubectl describe pod hello
# Багато інформації про планування, контейнери, події

# 6. Приберіть за собою
kubectl delete pod hello

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

Ще немає кластера? Це нормально! Трек “Основи Kubernetes” проведе вас через процес його налаштування. Це лише попередній перегляд.

Критерії успіху: Переконатися, що Kubernetes надає API для керування контейнерами на різних машинах.

Підсумок

Kubernetes — це платформа для оркестрації контейнерів, яка:

Планує контейнери на кількох машинах
Самовідновлюється, перезапускаючи контейнери, що впали
Масштабується залежно від попиту
Балансує навантаження трафіку на контейнери
Оновлює застосунки без простоїв
Керує мережею та сховищем

Основні концепції:

Кластер: Control plane + робочі вузли (worker nodes)
Pod: Найменша одиниця розгортання
Deployment: Керує реплікованими Pods
Service: Стабільна мережа для Pods

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

Модуль 1.4: Cloud Native екосистема — Розуміння ландшафту CNCF та місця Kubernetes у ньому.