Из каких компонентов состоит Kubernetes? Что происходит в кластере, когда вы применяете манифест Deployment?
Короткий ответ
- Control plane: kube-apiserver, etcd, scheduler, controller-manager
- На нодах: kubelet, kube-proxy и container runtime
- API-сервер — единая точка входа, состояние хранится в etcd
- Deployment-контроллер создаёт ReplicaSet, тот — поды
- Scheduler выбирает ноду, kubelet запускает контейнеры
- Всё построено на reconciliation loop: желаемое против фактического
Kubernetes — набор контроллеров, непрерывно приводящих фактическое состояние к желаемому, описанному в etcd.
Как сказать вслух
пример ответаУправляющий слой — это API-сервер, база etcd, планировщик и менеджер контроллеров, а на каждой ноде работают kubelet и container runtime. Когда я применяю Deployment, API-сервер валидирует объект и сохраняет его в etcd, контроллер создаёт ReplicaSet и поды, планировщик назначает каждому поду ноду, а kubelet на этой ноде запускает контейнеры. Вся система работает по принципу сверки: контроллеры постоянно приводят реальность к описанному состоянию.
Подробный ответ
Основной ответ
Control plane: kube-apiserver (REST API, аутентификация, валидация, admission-контроллеры), etcd (распределённое хранилище состояния), kube-scheduler (подбор ноды по ресурсам, affinity, taints), kube-controller-manager (циклы сверки для Deployment, ReplicaSet, Node и прочих). На нодах: kubelet (управляет подами через CRI-runtime, обычно containerd), kube-proxy (правила iptables/IPVS для Service), CNI-плагин (сеть подов). При kubectl apply объект проходит через API-сервер в etcd; Deployment-контроллер создаёт ReplicaSet, тот — Pod-объекты без ноды; scheduler проставляет nodeName; kubelet видит назначенный под, тянет образ, создаёт контейнеры и репортит статус. Ни один компонент не вызывает другой напрямую — все общаются через API-сервер, наблюдая за изменениями (watch).
Ключевые моменты
- Reconciliation loop. Контроллеры сравнивают desired и actual state и устраняют разницу — это фундаментальный паттерн всей системы.
- etcd. Единственное хранилище состояния кластера; его бэкап и кворум — критичны для живучести control plane.
- Цепочка Deployment. Deployment → ReplicaSet → Pod: именно ReplicaSet обеспечивает нужное число реплик и историю ревизий для отката.
- Decoupling через API. Компоненты связаны только через API-сервер и механизм watch, что делает систему расширяемой (операторы, CRD).
Практический контекст
Это базовый вопрос любого собеседования с Kubernetes. Понимание цепочки помогает в отладке: под в Pending — смотреть на scheduler и ресурсы; создаётся, но не стартует — на kubelet и образ; Deployment не обновляется — на события ReplicaSet. Интервьюер часто продолжает: «под в состоянии Pending/CrashLoopBackOff — ваши действия?», и ждёт отладки по цепочке компонентов.
Частые ошибки
- Не могут описать путь от kubectl apply до запущенного контейнера
- Считают, что scheduler сам запускает поды на нодах
- Забывают, что компоненты общаются только через API-сервер, а не напрямую