Модуль 1.3: Архітектура Kubernetes - Площина управління
Складність:
[СЕРЕДНІЙ]- Основні концепції архітектуриЧас на виконання: 25-30 хвилин
Передумови: Модулі 1.1, 1.2
Що ви зможете робити
Розділ «Що ви зможете робити»Після завершення цього модуля ви зможете:
- Пояснити роль кожного компонента площини управління: API server, etcd, scheduler та controller manager
- Простежити як запит на створення Pod проходить через компоненти площини управління
- Визначити який компонент відповідає за дану поведінку або збій кластера
- Порівняти архітектури з однією площиною управління та високою доступністю
Чому цей модуль важливий
Розділ «Чому цей модуль важливий»Площина управління — це мозок Kubernetes. Розуміння того, що робить кожен компонент, є важливим для KCNA — очікуйте кілька питань про архітектуру площини управління.
Архітектура кластера Kubernetes
Розділ «Архітектура кластера Kubernetes»┌─────────────────────────────────────────────────────────────┐│ АРХІТЕКТУРА КЛАСТЕРА KUBERNETES │├─────────────────────────────────────────────────────────────┤│ ││ ┌─────────────────────────────────────────────────────┐ ││ │ ПЛОЩИНА УПРАВЛІННЯ (Master) │ ││ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ ││ │ │ API │ │Планува- │ │Менеджер │ │ ││ │ │ Server │ │льник │ │контроле- │ │ ││ │ │ │ │ │ │рів │ │ ││ │ └──────────┘ └──────────┘ └──────────┘ │ ││ │ ┌──────────┐ ┌──────────┐ │ ││ │ │ etcd │ │ Хмарний │ │ ││ │ │ │ │контролер │ │ ││ │ └──────────┘ └──────────┘ │ ││ └─────────────────────────────────────────────────────┘ ││ │ ││ │ Виклики API ││ │ ││ ┌─────────────────────────────────────────────────────┐ ││ │ РОБОЧІ ВУЗЛИ │ ││ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ ││ │ │ Вузол 1 │ │ Вузол 2 │ │ Вузол 3 │ │ ││ │ │ ┌─────────┐ │ │ ┌─────────┐ │ │ ┌─────────┐ │ │ ││ │ │ │ kubelet │ │ │ │ kubelet │ │ │ │ kubelet │ │ │ ││ │ │ └─────────┘ │ │ └─────────┘ │ │ └─────────┘ │ │ ││ │ │ ┌─────────┐ │ │ ┌─────────┐ │ │ ┌─────────┐ │ │ ││ │ │ │kube-proxy│ │ │ │kube-proxy│ │ │ │kube-proxy│ │ │ ││ │ │ └─────────┘ │ │ └─────────┘ │ │ └─────────┘ │ │ ││ │ │ ┌─────────┐ │ │ ┌─────────┐ │ │ ┌─────────┐ │ │ ││ │ │ │Середови-│ │ │ │Середови-│ │ │ │Середови-│ │ │ ││ │ │ │ще вик. │ │ │ │ще вик. │ │ │ │ще вик. │ │ │ ││ │ │ └─────────┘ │ │ └─────────┘ │ │ └─────────┘ │ │ ││ │ └─────────────┘ └─────────────┘ └─────────────┘ │ ││ └─────────────────────────────────────────────────────┘ ││ │└─────────────────────────────────────────────────────────────┘Компоненти площини управління
Розділ «Компоненти площини управління»1. kube-apiserver
Розділ «1. kube-apiserver»API server — це парадний вхід до Kubernetes:
┌─────────────────────────────────────────────────────────────┐│ KUBE-APISERVER │├─────────────────────────────────────────────────────────────┤│ ││ Що він робить: ││ ───────────────────────────────────────────────────────── ││ • Надає Kubernetes API (REST-інтерфейс) ││ • Вся комунікація проходить через нього ││ • Автентифікує та авторизує запити ││ • Валідує об'єкти API ││ • Єдиний компонент, який спілкується з etcd ││ ││ Хто з ним спілкується: ││ ───────────────────────────────────────────────────────── ││ kubectl ────────→ ┌──────────────┐ ││ Dashboard ──────→ │ API Server │ ←──── kubelet ││ Інші інструм. ─→ └──────────────┘ ←──── Контролери ││ ││ Ключовий момент: ││ API server — це ЄДИНИЙ компонент, який читає/записує ││ до etcd. Все інше спілкується з API server. ││ │└─────────────────────────────────────────────────────────────┘2. etcd
Розділ «2. etcd»etcd — це база даних кластера:
┌─────────────────────────────────────────────────────────────┐│ ETCD │├─────────────────────────────────────────────────────────────┤│ ││ Що це: ││ ───────────────────────────────────────────────────────── ││ • Розподілене сховище ключ-значення ││ • Зберігає ВЕСЬ стан кластера ││ • Високодоступне (зазвичай 3 або 5 вузлів) ││ • Використовує алгоритм консенсусу Raft ││ ││ Що зберігає: ││ ───────────────────────────────────────────────────────── ││ • Визначення Подів ││ • Конфігурації сервісів ││ • Secrets та ConfigMaps ││ • Інформацію про вузли ││ • Політики RBAC ││ • Все у кластері! ││ ││ Ключовий момент: ││ Якщо etcd втрачено, весь стан кластера втрачено. ││ Робіть резервні копії etcd регулярно! ││ │└─────────────────────────────────────────────────────────────┘3. kube-scheduler
Розділ «3. kube-scheduler»Планувальник розміщує Поди на вузлах:
┌─────────────────────────────────────────────────────────────┐│ KUBE-SCHEDULER │├─────────────────────────────────────────────────────────────┤│ ││ Що він робить: ││ ───────────────────────────────────────────────────────── ││ • Спостерігає за щойно створеними Подами без вузла ││ • Вибирає вузол для кожного Пода ││ • НЕ запускає Под (це робить kubelet) ││ ││ Як приймає рішення: ││ ───────────────────────────────────────────────────────── ││ Фільтрація: ││ • Чи має вузол достатньо ресурсів? ││ • Чи відповідає nodeSelector Пода? ││ • Чи задовольняє правила affinity? ││ ││ Оцінювання: ││ • Розподілити Поди між вузлами (баланс) ││ • Надати перевагу вузлам з кешованим образом ││ • Врахувати користувацькі пріоритети ││ ││ Новий Под → Планувальник → "Запустити на Вузлі 2" ││ → kubelet запускає його ││ │└─────────────────────────────────────────────────────────────┘4. kube-controller-manager
Розділ «4. kube-controller-manager»Менеджер контролерів запускає контролери:
┌─────────────────────────────────────────────────────────────┐│ KUBE-CONTROLLER-MANAGER │├─────────────────────────────────────────────────────────────┤│ ││ Що він робить: ││ ───────────────────────────────────────────────────────── ││ • Запускає процеси контролерів ││ • Кожен контролер спостерігає за певними ресурсами ││ • Контролери приводять поточний стан до бажаного ││ ││ Важливі контролери: ││ ───────────────────────────────────────────────────────── ││ Контролер вузлів: ││ • Моніторить здоров'я вузлів ││ • Реагує, коли вузли виходять з ладу ││ ││ Контролер реплікації: ││ • Підтримує правильну кількість Подів ││ • Створює/видаляє Поди за потреби ││ ││ Контролер Endpoints: ││ • Заповнює об'єкти Endpoints ││ • Зв'язує Services з Подами ││ ││ Контролер ServiceAccount: ││ • Створює стандартні ServiceAccounts ││ │└─────────────────────────────────────────────────────────────┘5. cloud-controller-manager
Розділ «5. cloud-controller-manager»Хмарний менеджер контролерів інтегрується з хмарними провайдерами:
┌─────────────────────────────────────────────────────────────┐│ CLOUD-CONTROLLER-MANAGER │├─────────────────────────────────────────────────────────────┤│ ││ Що він робить: ││ ───────────────────────────────────────────────────────── ││ • Хмарно-специфічна логіка управління ││ • Присутній тільки у хмарних середовищах ││ • Відділяє хмарний код від ядра K8s ││ ││ Контролери, які він запускає: ││ ───────────────────────────────────────────────────────── ││ Контролер вузлів: ││ • Перевіряє, чи вузол ще існує у хмарі ││ ││ Контролер маршрутів: ││ • Налаштовує маршрути у хмарній інфраструктурі ││ ││ Контролер сервісів: ││ • Створює хмарні балансувальники для Services ││ ││ Приклад: ││ Service type: LoadBalancer → cloud-controller створює ││ AWS ELB, GCP Load Balancer або Azure LB ││ │└─────────────────────────────────────────────────────────────┘Комунікація площини управління
Розділ «Комунікація площини управління»┌─────────────────────────────────────────────────────────────┐│ ЯК КОМПОНЕНТИ КОМУНІКУЮТЬ │├─────────────────────────────────────────────────────────────┤│ ││ ┌──────────────┐ ││ │ kubectl │ ││ └──────┬───────┘ ││ │ ││ ▼ ││ ┌──────────────┐ ││ Менеджер ──────→ │ API Server │ ←───── Планувальник ││ контролерів └──────┬───────┘ ││ │ ││ ▼ ││ ┌──────────────┐ ││ │ etcd │ ││ └──────────────┘ ││ ││ Приклад потоку - Створення Deployment: ││ ││ 1. kubectl створює Deployment через API Server ││ 2. API Server зберігає його в etcd ││ 3. Контролер Deployment бачить новий Deployment ││ 4. Контролер створює ReplicaSet ││ 5. Контролер ReplicaSet створює Поди ││ 6. Планувальник бачить незаплановані Поди ││ 7. Планувальник призначає Поди на вузли ││ 8. kubelet на вузлі бачить призначення, запускає Поди ││ │└─────────────────────────────────────────────────────────────┘Висока доступність
Розділ «Висока доступність»У продакшені компоненти площини управління реплікуються:
┌─────────────────────────────────────────────────────────────┐│ НАЛАШТУВАННЯ ВИСОКОЇ ДОСТУПНОСТІ │├─────────────────────────────────────────────────────────────┤│ ││ ┌──────────────────────────────────────────────────────┐ ││ │ Балансувальник навантаження │ ││ └──────────────────────────────────────────────────────┘ ││ │ ││ ┌────────────────┼────────────────┐ ││ │ │ │ ││ ▼ ▼ ▼ ││ ┌────────────┐ ┌────────────┐ ┌────────────┐ ││ │ Master 1 │ │ Master 2 │ │ Master 3 │ ││ │ │ │ │ │ │ ││ │ API Server │ │ API Server │ │ API Server │ ││ │ Scheduler │ │ Scheduler │ │ Scheduler │ ││ │ Controller │ │ Controller │ │ Controller │ ││ │ etcd │ │ etcd │ │ etcd │ ││ └────────────┘ └────────────┘ └────────────┘ ││ ││ • Кілька API серверів (всі активні) ││ • Scheduler/Controller використовують вибір лідера ││ • etcd вимагає кворум (непарне число: 3, 5, 7) ││ │└─────────────────────────────────────────────────────────────┘Чи знали ви?
Розділ «Чи знали ви?»-
etcd означає “/etc distributed” - Названий на честь каталогу Unix /etc, де зберігається конфігурація, плюс “distributed”.
-
Вибір лідера запобігає конфліктам - Тільки один планувальник та менеджер контролерів активний одночасно. Інші в режимі очікування.
-
API server не має стану - Він нічого не зберігає локально. Весь стан в etcd. Це робить масштабування легким.
-
Контролери використовують патерн watch - Вони не опитують. Вони отримують повідомлення при зміні об’єктів, що робить їх ефективними.
Типові помилки
Розділ «Типові помилки»| Помилка | Чому це шкодить | Правильне розуміння |
|---|---|---|
| ”Планувальник запускає Поди” | Втрачено роль kubelet | Планувальник призначає; kubelet запускає |
| ”etcd необов’язковий” | Недооцінка стану кластера | Без etcd немає стану кластера |
| ”API server зберігає дані” | Плутання з etcd | API server — шлюз без стану |
| ”Контролери необов’язкові” | Втрата автоматизації | Контролери роблять K8s самовідновлюваним |
Вікторина
Розділ «Вікторина»-
Який компонент єдиний спілкується безпосередньо з etcd?
Відповідь
kube-apiserver. Всі інші компоненти читають та записують стан кластера через API server. -
Що робить kube-scheduler?
Відповідь
Він спостерігає за щойно створеними Подами без призначеного вузла та вибирає вузол для їх запуску. Він НЕ запускає Поди. -
Що таке etcd?
Відповідь
Розподілене сховище ключ-значення, яке зберігає весь стан кластера. Це єдине джерело істини для кластера Kubernetes. -
Що робить менеджер контролерів?
Відповідь
Він запускає процеси контролерів, які спостерігають за станом кластера та вносять зміни для приведення поточного стану до бажаного. Приклади: Контролер вузлів, Контролер ReplicaSet. -
Чому у продакшені запускають кілька вузлів площини управління?
Відповідь
Висока доступність. Якщо один вузол площини управління виходить з ладу, інші продовжують працювати. etcd вимагає кворум, тому використовуються непарні числа (3, 5).
Підсумок
Розділ «Підсумок»Компоненти площини управління:
| Компонент | Призначення |
|---|---|
| kube-apiserver | Шлюз API, автентифікація, валідація |
| etcd | Розподілене сховище для всього стану кластера |
| kube-scheduler | Призначає Поди на вузли |
| kube-controller-manager | Запускає контролери (цикли узгодження) |
| cloud-controller-manager | Інтеграція з хмарним провайдером |
Ключові моменти:
- Тільки API server спілкується з etcd
- Планувальник вирішує ДЕ; kubelet запускає
- Контролери забезпечують бажаний стан = поточний стан
- Висока доступність вимагає кількох вузлів площини управління
Наступний модуль
Розділ «Наступний модуль»Модуль 1.4: Архітектура Kubernetes - Компоненти вузлів - Розуміння робочих одиниць, що запускають ваші застосунки.