Анатомия кластера: Control Plane и Worker Nodes

Иерархия управления: разделение ответственности между Control Plane и Worker Nodes

Представьте кластер из тысячи серверов, на которых крутятся десятки тысяч контейнеров. Внезапно в дата-центре сгорает стойка, и 50 серверов мгновенно выходят из строя. Уже через несколько секунд приложения, работавшие на сгоревшем железе, начинают запускаться на уцелевших машинах, а пользователи даже не замечают сбоя. Кто именно заметил «пожар»? Кто принял решение, куда перенести нагрузку? И кто физически запустил новые контейнеры? Ответ кроется в строгом разделении архитектуры Kubernetes на «мозг» и «мышцы».

В предыдущем курсе мы выяснили, что Kubernetes работает на основе цикла согласования (Reconciliation Loop), постоянно подгоняя реальное состояние системы под желаемое декларативное описание. Чтобы эта магия работала в масштабах сотен серверов, система не может быть монолитной. Она разделена на две изолированные плоскости: Control Plane (управляющая плоскость) и Worker Nodes (рабочие узлы).

Понимание этой границы — фундамент для проектирования отказоустойчивых систем (High Availability) и первый шаг к траблшутингу на экзамене CKA. Если вы не знаете, где физически исполняется компонент, вы не будете знать, на каком сервере искать его логи.

Control Plane: Глобальный разум кластера

Control Plane — это набор системных компонентов, которые принимают глобальные решения о состоянии кластера. Они не занимаются запуском ваших пользовательских приложений. Их задача — управлять, наблюдать и хранить истину.

Если провести аналогию с корпорацией, Control Plane — это совет директоров. Они не стоят у станка, но именно они решают, какой цех нужно расширить и куда направить ресурсы.

В состав Control Plane входят четыре ключевых компонента (каждый из них мы детально разберем в следующих главах, сейчас важна их роль в иерархии):

kube-apiserver — единственный фронтенд кластера. Все внешние и внутренние запросы проходят только через него.

etcd — распределенное хранилище данных формата «ключ-значение». Это долгосрочная память кластера, где лежат все манифесты и текущие статусы.

kube-scheduler — диспетчер ресурсов. Именно он реализует алгоритм Bin Packing, решая, на какой конкретно узел отправить новый Pod.

kube-controller-manager — набор контроллеров, в которых физически крутятся циклы согласования. Они замечают, если узел упал, и создают запросы на замену потерянных Pod'ов.

Worker Nodes: Исполнительная сила

Worker Nodes — это рабочие лошадки. Их единственная цель — принимать приказы от Control Plane и обеспечивать бесперебойную работу Pod'ов.

Суммарная вычислительная мощность кластера складывается именно из ресурсов рабочих узлов. Если обозначить процессорные мощности и память каждого -го узла как и , то общая емкость кластера для запуска полезной нагрузки выражается как:

На каждом рабочем узле всегда запущены три инфраструктурных компонента:

Kubelet — агент Kubernetes. Как бригадир на стройке, он получает спецификации Pod'ов от Control Plane и следит за их состоянием на своем узле (включая выполнение Liveness и Readiness проб).

Container Runtime (например, containerd или CRI-O) — низкоуровневый движок, который Kubelet вызывает для фактической распаковки образов и запуска процессов в изолированных пространствах имен.

kube-proxy — сетевой диспетчер узла, настраивающий правила маршрутизации (обычно через iptables или IPVS), чтобы сетевой трафик находил нужный Pod.

!Архитектура Kubernetes: Control Plane и Worker Nodes

Золотое правило коммуникации: API Server как бутылочное горлышко

Главный архитектурный принцип Kubernetes, который нужно запомнить раз и навсегда: компоненты никогда не общаются друг с другом напрямую.

Kubelet на рабочем узле не имеет права напрямую читать данные из etcd. Scheduler не может напрямую приказать Kubelet'у запустить Pod. Controller Manager не общается со Scheduler'ом.

Абсолютно все коммуникации идут по схеме звезды (Hub-and-Spoke), где в центре находится kube-apiserver.

> Любое изменение в кластере — это всегда запись в etcd, сделанная API-сервером, на которую затем реагируют другие компоненты, подписанные на обновления этого API.

Рассмотрим, как это работает в динамике, когда вы применяете манифест через kubectl apply.

!Прохождение команды через API Server к узлу

Такая архитектура кажется перегруженной, но она обеспечивает невероятную слабую связность (loose coupling). Вы можете обновить версию Scheduler'а или заменить Container Runtime на узлах, и система продолжит работать, потому что контракт взаимодействия через API остается неизменным.

Асимметрия отказов: что будет, если сломается мозг или мышцы?

Разделение на Control Plane и Worker Nodes диктует совершенно разные подходы к проектированию отказоустойчивости (High Availability) и масштабированию.

Сценарий 1: Падение Worker Node

Если сервер из группы Worker Nodes выходит из строя (отключили питание), Kubelet перестает отправлять сигналы сердцебиения (heartbeats) в Control Plane. * Влияние на приложения: Pod'ы на упавшем узле недоступны. * Реакция системы: Controller Manager замечает отсутствие сердцебиения, помечает узел как мертвый и создает новые Pod'ы. Scheduler находит для них место на других Worker Nodes. Kubelet'ы на новых узлах запускают контейнеры. * Итог: Система самовосстанавливается. Кластер продолжает работать.

Сценарий 2: Падение Control Plane

Представим, что вышли из строя серверы, на которых запущен Control Plane (API Server недоступен). * Влияние на приложения: Уже запущенные на Worker Nodes Pod'ы продолжают работать. Kubelet не убивает контейнеры при потере связи с базой. Сетевой трафик через kube-proxy продолжает ходить. Пользователи вашего сайта могут даже не заметить аварии. * Реакция системы: Вы не можете применить новый манифест. Вы не можете масштабировать Deployment. Если в этот момент упадет Worker Node, никто не пересоздаст его Pod'ы на других узлах — цикл согласования разорван. * Итог: Кластер переходит в режим «только чтение» и теряет способность к самовосстановлению до починки Control Plane.

Именно поэтому в Highload-системах Control Plane и Worker Nodes масштабируют по разным метрикам. Worker Nodes добавляют, когда вашим приложениям не хватает CPU или RAM. Узлы Control Plane дублируют, когда растет количество узлов и API Server перестает справляться с потоком внутренних запросов от тысяч Kubelet'ов.

В следующих главах мы возьмем микроскоп и подробно изучим каждый компонент этой системы, начиная с самого сердца — kube-apiserver.