Как устроена архитектура Kubernetes (Master и Worker узлы)?
Архитектура Kubernetes — Master (Control Plane) и Worker узлы
Kubernetes разделён на две логические части: Control Plane (раньше — «Master») — отвечает за управление кластером, и Worker (узлы) — на которых запускаются приложения (Pods). Между ними идёт взаимодействие через API-сервер.
Control Plane (Master)
kube-apiserver — единственная «входная точка». Обрабатывает REST-запросы, аутентификацию/авторизацию, валидацию, хранит и читает состояние из etcd. Все остальные компоненты общаются через API-сервер.
etcd — распределённое ключ-значение хранилище, где хранится вся конфигурация и состояние кластера (desired state). Должен быть отказоустойчивым (кластер etcd).
kube-scheduler — принимает решения, на какой ноде запускать неподвязаные Pod'ы (учитывает ресурсы, taints/tolerations, affinity, локальные ограничения). Записывает binding в API.
kube-controller-manager — набор контроллеров (replica, deployment, node controller, endpoint controller и др.). Каждый контроллер — цикл «наблюдение — сравнение — коррекция»: смотрит на desired state в API и создаёт/удаляет ресурсы, чтобы привести real state в соответствие.
cloud-controller-manager — интеграция с облачным провайдером (если есть): управление балансировщиками, томами, нодами в облаке. Отдельный процесс для разделения облачной логики.
Admission controllers & webhooks — промежуточные плагины, которые могут изменять или отклонять запросы к API (например, добавление default-ов, проверка политик).
Control Plane обычно разворачивают в HA: несколько экземпляров API-сервера за балансировщиком, etcd — кластер, контроллеры и scheduler используют лидер-элекшн.
Worker узлы (Node)
На каждой ноде есть несколько ключевых компонентов:
kubelet — агент, который следит за PodSpec, пришедшим через API. Обеспечивает запуск контейнеров через CRI, следит за состоянием, выполняет probes, монтирует тома, отправляет статус в API.
container runtime (containerd/CRI-O/раньше Docker) — запускает контейнеры по запросу kubelet через CRI.
kube-proxy — реализует сетевой доступ к сервисам: может работать через iptables или ipvs, обеспечивает перенаправление трафика на Pod IP-адреса, реализует сервисную виртуализацию (ClusterIP, NodePort).
CNI-плагин — реализует сетевую модель кластера (назначение IP Pod'ам, маршрутизация, сетевые политики). Популярные реализации: Calico, Flannel, Weave, Canal и т. п.
Как всё взаимодействует (упрощённо)
-
Пользователь/CI кладёт манифест в API (kubectl → kube-apiserver).
-
Объект (например Deployment) сохраняется в etcd.
-
Контроллеры создают ReplicaSet → Pod'ы (desired state ←).
-
Scheduler выбирает node для Pod и пишет binding.
-
Kubelet на выбранной ноде видит PodSpec, запрашивает у контейнерного рантайма образы, монтирует тома и запускает контейнеры.
-
kube-proxy и CNI обеспечивают сетевой доступ; сервисы распределяют трафик.
-
Контроллеры и kubelet постоянно репонируют состояние: если Pod упал — контроллер создаст новый, если node NotReady — контроллер переместит/пересоздаст по политике.
Расширяемость и безопасность
Kubernetes расширяем через CRD/Operators, webhook'и, CSI для стека хранения. Безопасность — через RBAC, NetworkPolicy, TLS между компонентами и admission-политики.
Особенности
-
Единая модель «desired vs actual» с контроллерами-репликаторами.
-
Поддержка разных сред: on-prem, облако, managed Kubernetes (Control Plane мог быть закрыт провайдером).
-
Разделение обязанностей: Control Plane — интеллект и хранение состояния; Nodes — исполнение контейнеров и местные операции.