Які основні компоненти архітектури Kubernetes і за що кожен відповідає?
Кластер Kubernetes складається з площини керування плюс набору робочих машин, які називаються вузлами, які запускають контейнерні програми в Pods. Кожному кластеру потрібен принаймні один робочий вузол для запуску Pods.
Концептуально Kubernetes є декларативним: ви надсилаєте бажаний стан на сервер API (зберігається в etcd), а контролери запускають безперервні цикли узгодження, які відстежують відмінності та діють, щоб привести фактичний стан до бажаного.
Компоненти площини керування
Площина керування приймає глобальні рішення щодо кластера (наприклад, планування) і реагує на події кластера. У виробництві він зазвичай працює на кількох машинах для високої доступності.
- kube-apiserver — основний компонент, який надає Kubernetes HTTP API. Це передній кінець рівня керування та єдина точка контакту: уся автентифікація, авторизація, перевірка запитів і читання/запис стану кластера проходять через нього. Він масштабується горизонтально. У звичайних розгортаннях це єдиний компонент Kubernetes, який читає та записує стан кластера безпосередньо в etcd; усі інші компоненти взаємодіють із станом через сервер API.
- etcd — послідовне та високодоступне сховище ключ-значення, яке використовується як резервне сховище Kubernetes для всіх даних кластера: конфігурації, стану та метаданих. etcd є обов’язковим і є єдиним джерелом істини — його втрата означає втрату всього стану кластера, тому він повинен працювати з кворумом (непарна кількість учасників) і регулярно створювати резервні копії.
- kube-scheduler — спостерігає за Pods, ще не прив’язаними до вузла, і призначає кожен Pod відповідному вузлу, враховуючи ресурси, обмеження та політики.
- kube-controller-manager — запускає контролери, які реалізують поведінку Kubernetes API (наприклад, контролер вузла, контролер завдання, контролер EndpointSlice). Кожен контролер спостерігає за бажаним станом і узгоджує з ним фактичний стан.
- cloud-controller-manager (необов’язково) — інтегрується з основним хмарним постачальником, ізолюючи спеціальну хмарну логіку від основних компонентів Kubernetes.
Компоненти вузла
Вони працюють на кожному вузлі, забезпечуючи роботу Pods і забезпечуючи середовище виконання.
- kubelet — агент, який забезпечує роботу Pods, включаючи їхні контейнери. Він спостерігає за сервером API для призначень Pod, запускає контейнери через середовище виконання, монтує томи, запускає зонди живучості/готовності та повідомляє про стан вузла.
- kube-proxy — реалізує мережу Сервісу шляхом програмування iptables або правил IPVS на вузлах, щоб трафік до Сервісу перенаправлявся на правильні IP-адреси Pod. Він позначений як необов’язковий, оскільки деякі плагіни CNI (наприклад, Cilium у режимі eBPF) беруть на себе його роботу, але в стандартному кластері він є обов’язковим.
- Container runtime — програмне забезпечення, відповідальне за запуск контейнерів (container, CRI-O тощо, через інтерфейс CRI).
Додатки
Додатки розширюють функціональні можливості кластера: кластерний DNS (CoreDNS за замовчуванням), веб-інтерфейс панелі інструментів, моніторинг ресурсів контейнера та журналювання на рівні кластера.
Загальні подальші дії: уся комунікація проходить через сервер API — планувальник, контролери та kubelets просто спостерігають за цим і реагують — що робить сервер API критичним центром кластера.
