Перейти до вмісту

Модуль 1.4: Архітектура Kubernetes - Компоненти вузлів

Складність: [СЕРЕДНІЙ] - Основні концепції архітектури

Час на виконання: 20-25 хвилин

Передумови: Модуль 1.3


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

Розділ «Що ви зможете робити»

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

  • Пояснити роль kubelet, kube-proxy та середовища виконання контейнерів на кожному вузлі
  • Визначити який компонент вузла відповідає за дану поведінку мережі або життєвого циклу Pod
  • Порівняти режими kube-proxy (iptables та IPVS) та їхні компроміси
  • Простежити як Pod призначається та запускається на робочому вузлі

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

Розділ «Чому цей модуль важливий»

Поки площина управління приймає рішення, робочі вузли виконують фактичну роботу із запуску контейнерів. Розуміння компонентів вузлів завершує вашу картину архітектури Kubernetes — ключова тема KCNA.


Вузол — це робоча машина в Kubernetes:

┌─────────────────────────────────────────────────────────────┐
│ ЩО ТАКЕ ВУЗОЛ? │
├─────────────────────────────────────────────────────────────┤
│ │
│ Вузол може бути: │
│ • Фізичний сервер (bare metal) │
│ • Віртуальна машина (EC2, GCE VM, Azure VM) │
│ • Хмарний екземпляр │
│ │
│ Кожен вузол запускає: │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ kubelet - Агент вузла │ │
│ │ kube-proxy - Мережевий проксі │ │
│ │ Середовище виконання контейнерів - Запускає │ │
│ │ контейнери │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Вузли реєструються у площині управління │
│ Площина управління призначає Поди на вузли │
│ │
└─────────────────────────────────────────────────────────────┘

kubelet — це основний агент вузла:

┌─────────────────────────────────────────────────────────────┐
│ KUBELET │
├─────────────────────────────────────────────────────────────┤
│ │
│ Що він робить: │
│ ───────────────────────────────────────────────────────── │
│ • Працює на кожному вузлі кластера │
│ • Спостерігає за призначеннями Подів від API server │
│ • Забезпечує роботу та здоров'я контейнерів │
│ • Звітує про стан вузла та Подів до API server │
│ │
│ Як він працює: │
│ ───────────────────────────────────────────────────────── │
│ │
│ API Server: "Вузол 2, запусти Под X" │
│ │ │
│ ▼ │
│ kubelet: │
│ 1. Отримує специфікацію Пода │
│ 2. Завантажує образи контейнерів │
│ 3. Створює контейнери через середовище виконання │
│ 4. Моніторить здоров'я контейнерів │
│ 5. Звітує про стан до API server │
│ │
│ Ключовий момент: │
│ kubelet не керує контейнерами, створеними не через K8s │
│ │
└─────────────────────────────────────────────────────────────┘

kube-proxy обробляє мережу:

┌─────────────────────────────────────────────────────────────┐
│ KUBE-PROXY │
├─────────────────────────────────────────────────────────────┤
│ │
│ Що він робить: │
│ ───────────────────────────────────────────────────────── │
│ • Підтримує мережеві правила на вузлах │
│ • Забезпечує абстракцію Service │
│ • Обробляє перенаправлення з'єднань до Подів │
│ │
│ Як працюють Services: │
│ ───────────────────────────────────────────────────────── │
│ │
│ Клієнт │
│ │ │
│ │ Запит до IP Service │
│ ▼ │
│ ┌───────────┐ │
│ │kube-proxy │ → Шукає, які Поди обслуговують Service │
│ └───────────┘ │
│ │ │
│ │ Перенаправляє на IP Пода │
│ ▼ │
│ ┌───────────┐ │
│ │ Под │ │
│ └───────────┘ │
│ │
│ Режими: │
│ • iptables (за замовчуванням) - Використовує правила │
│ iptables │
│ • IPVS - Вища продуктивність для великих кластерів │
│ • userspace - Застарілий, рідко використовується │
│ │
└─────────────────────────────────────────────────────────────┘

3. Середовище виконання контейнерів

Розділ «3. Середовище виконання контейнерів»

Середовище виконання контейнерів фактично запускає контейнери:

┌─────────────────────────────────────────────────────────────┐
│ СЕРЕДОВИЩЕ ВИКОНАННЯ КОНТЕЙНЕРІВ │
├─────────────────────────────────────────────────────────────┤
│ │
│ Що воно робить: │
│ ───────────────────────────────────────────────────────── │
│ • Завантажує образи з реєстрів │
│ • Створює та запускає контейнери │
│ • Керує життєвим циклом контейнерів │
│ │
│ Kubernetes використовує CRI (Container Runtime Interface):│
│ ───────────────────────────────────────────────────────── │
│ │
│ kubelet │
│ │ │
│ │ CRI (gRPC) │
│ ▼ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ containerd │ CRI-O │ Інше CRI середовище │ │
│ └─────────────────────────────────────────────────┘ │
│ │ │
│ │ OCI (Open Container Initiative) │
│ ▼ │
│ ┌───────────────┐ │
│ │ runc / kata │ (низькорівневе середовище вик.) │
│ └───────────────┘ │
│ │
│ Поширені середовища виконання: │
│ • containerd - За замовчуванням у більшості дистрибутивів │
│ • CRI-O - Легке, орієнтоване на Kubernetes │
│ │
└─────────────────────────────────────────────────────────────┘

Життєвий цикл вузла

Розділ «Життєвий цикл вузла»
┌─────────────────────────────────────────────────────────────┐
│ ЖИТТЄВИЙ ЦИКЛ ВУЗЛА │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. Вузол приєднується до кластера │
│ • kubelet запускається та реєструється в API server │
│ • Вузол з'являється у "kubectl get nodes" │
│ │
│ 2. Вузол готовий │
│ • Проходить перевірки здоров'я │
│ • Планувальник може розміщувати Поди на ньому │
│ Стан: Ready │
│ │
│ 3. Вузол працює │
│ • Запускає призначені Поди │
│ • kubelet періодично звітує про стан │
│ │
│ 4. Проблеми з вузлом │
│ • Пропускає heartbeats → Стан: Unknown │
│ • Мало ресурсів → Стан: NotReady │
│ │
│ 5. Вузол видалено │
│ • Дренований (Поди переміщені) │
│ • Видалений з кластера │
│ │
└─────────────────────────────────────────────────────────────┘
УмоваЗначення
ReadyВузол здоровий і може приймати Поди
DiskPressureЄмність диска низька
MemoryPressureПам’яті стає мало
PIDPressureЗабагато процесів
NetworkUnavailableМережа не налаштована

Як Поди плануються та запускаються

Розділ «Як Поди плануються та запускаються»
┌─────────────────────────────────────────────────────────────┐
│ ПЛАНУВАННЯ ТА ЗАПУСК ПОДІВ │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. Користувач створює Под │
│ kubectl apply -f pod.yaml │
│ │ │
│ ▼ │
│ 2. API Server зберігає Под │
│ Под зберігається в etcd (вузол ще не призначений) │
│ │ │
│ ▼ │
│ 3. Планувальник спостерігає, бачить незапланований Под │
│ Оцінює вузли, вибирає найкращий │
│ Оновлює Под з призначенням вузла │
│ │ │
│ ▼ │
│ 4. kubelet на цільовому вузлі бачить призначення │
│ "Мені потрібно запустити цей Под" │
│ │ │
│ ▼ │
│ 5. kubelet дає команду середовищу виконання │
│ Завантажити образ, створити контейнер, запустити його │
│ │ │
│ ▼ │
│ 6. Контейнер працює │
│ kubelet моніторить здоров'я │
│ Звітує про стан до API server │
│ │
└─────────────────────────────────────────────────────────────┘

Площина управління проти вузла

Розділ «Площина управління проти вузла»
┌─────────────────────────────────────────────────────────────┐
│ ПЛОЩИНА УПРАВЛІННЯ проти ВУЗЛА │
├─────────────────────────────────────────────────────────────┤
│ │
│ ПЛОЩИНА УПРАВЛІННЯ (Мозок) ВУЗОЛ (М'яз) │
│ ────────────────────────────────────────────────────── │
│ │
│ Приймає рішення Виконує рішення │
│ Зберігає стан кластера Запускає навантаження │
│ Планує Поди Запускає Поди │
│ Зазвичай 3+ для HA Багато (десятки до тисяч) │
│ │
│ Компоненти: Компоненти: │
│ • API Server • kubelet │
│ • etcd • kube-proxy │
│ • Планувальник • Середовище виконання │
│ • Менеджер контролерів контейнерів │
│ │
└─────────────────────────────────────────────────────────────┘

  • kubelet не працює як контейнер - Це системний сервіс, який працює безпосередньо на ОС вузла. Він повинен керувати контейнерами, тому не може бути одним з них.

  • kube-proxy замінюється - Новіші плагіни CNI (як Cilium) можуть обробляти маршрутизацію Service без kube-proxy, використовуючи eBPF.

  • Вузли можуть мати taints - Taints запобігають запуску певних Подів на вузлі. Подам потрібні відповідні tolerations для планування там.

  • Контейнер pause - Кожен Под має прихований контейнер “pause”, який тримає мережевий простір імен. Інші контейнери в Поді його спільно використовують.


ПомилкаЧому це шкодитьПравильне розуміння
”kubelet на площині управління”Плутання розташуванняkubelet є на КОЖНОМУ вузлі, включно з робочими
”kube-proxy — це проксі-сервер”Оманлива назваВін підтримує правила iptables, а не традиційний проксі
”Середовище виконання — Docker”Застаріла інформаціяcontainerd тепер за замовчуванням
”Вузли — це завжди ВМ”Втрата гнучкостіВузли можуть бути bare metal, ВМ або хмарними екземплярами

  1. Яка основна функція kubelet?

    Відповідь kubelet — це агент вузла, який забезпечує роботу контейнерів у Подах. Він спостерігає за призначеннями Подів та працює з середовищем виконання контейнерів для створення/керування контейнерами.
  2. Що робить kube-proxy?

    Відповідь kube-proxy підтримує мережеві правила на вузлах, які забезпечують абстракцію Service. Він перенаправляє трафік, призначений для IP Service, на відповідні IP Подів.
  3. Що таке CRI?

    Відповідь Container Runtime Interface — стандартний API, який kubelet використовує для комунікації з середовищами виконання контейнерів, такими як containerd та CRI-O.
  4. Які компоненти працюють на КОЖНОМУ вузлі?

    Відповідь kubelet, kube-proxy та середовище виконання контейнерів (як containerd). Ці три компоненти обов'язкові на кожному вузлі.
  5. Що відбувається, коли вузол пропускає heartbeats?

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

Компоненти вузла:

КомпонентПризначення
kubeletАгент вузла, керує Подами та контейнерами
kube-proxyМережеві правила для маршрутизації Service
Середовище виконання контейнерівФактично запускає контейнери (containerd)

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

  • Кожен вузол потребує всі три компоненти
  • kubelet — єдиний компонент, що спілкується з API server
  • kube-proxy забезпечує виявлення сервісів
  • Середовище виконання використовує CRI для комунікації з kubelet

Потік виконання Пода:

  1. API server зберігає Под
  2. Планувальник призначає вузол
  3. kubelet бачить призначення
  4. Середовище виконання запускає контейнери
  5. kubelet моніторить та звітує

Модуль 1.5: Поди - Фундаментальний будівельний блок навантажень Kubernetes.