PrepBro
← Назад к вопросам

В чем разница между Master node и Worker node?

1.0 Junior🔥 251 комментариев
#Kubernetes

Комментарии (1)

🐱
deepseek-v3.2PrepBro AI5 апр. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

Разница между Master Node и Worker Node в Kubernetes

В архитектуре Kubernetes (K8s), кластер чётко разделяется на две основные роли: Master Node (Управляющий узел) и Worker Node (Рабочий узел). Это разделение ответственности является фундаментом для обеспечения отказоустойчивости, масштабируемости и управляемости системы. Master отвечает за глобальное управление и координацию, а Workers — за непосредственное исполнение рабочей нагрузки.

Master Node (Control Plane)

Master Node, или Control Plane (Панель управления), — это мозг кластера. Его основная задача — принимать глобальные решения о кластере (например, планирование работы подов), а также обнаруживать и реагировать на события кластера (например, запуск нового пода при падении существующего).

Ключевые компоненты Master Node:

  • kube-apiserver: Фронтенд Control Plane. Это единственный компонент, с которым взаимодействуют все остальные (через REST API). Он валидирует и конфигурирует данные для объектов K8s (поды, сервисы и т.д.).
  • etcd: Высокодоступное хранилище ключ-значение, в котором хранится вся конфигурация и состояние кластера. Это "единый источник истины".
  • kube-scheduler: Отвечает за планирование (scheduling) подов на Worker Nodes. Он оценивает требования к ресурсам (CPU, RAM), аппаратные/программные ограничения, политики сходства/антисходства и выбирает наиболее подходящий узел.
  • kube-controller-manager: Запускает контроллеры — фоновые циклы, которые следят за состоянием кластера и стремятся привести его к желаемому.
    *   Node Controller: Отвечает за обнаружение и реагирование на недоступность узлов.
    *   Replication Controller: Поддерживает корректное количество реплик подов для каждого объекта ReplicationController.
    *   Endpoints Controller: Заполняет объекты Endpoints (связывает сервисы и поды).
  • cloud-controller-manager (опционально): Позволяет связывать кластер с API облачного провайдера (например, для создания Load Balancer'ов или дисков).

В продакшен-средах Master Node обычно разворачивается с высокой доступностью (HA) — несколько реплик на отдельных физических машинах или виртуальных машинах.

Worker Node (Data Plane)

Worker Node (ранее Minion) — это машины (виртуальные или физические), где выполняются рабочие нагрузки в виде контейнеров, упакованных в поды (Pods). Каждый Worker управляется Master'ом.

Ключевые компоненты Worker Node:

  • Kubelet: Агент, который работает на каждом Worker Node. Он отвечает за управление жизненным циклом подов: получает их спецификации (PodSpecs) от API-сервера и обеспечивает, чтобы контейнеры в этих подах были запущены и здоровы.
  • Kube-proxy: Сетевой прокси, который реализует концепцию Kubernetes Service на каждом узле. Он поддерживает сетевые правила, которые обеспечивают маршрутизацию трафика к подам, как внутри кластера, так и извне. Может работать в различных режимах (iptables, ipvs).
  • Container Runtime: Программное обеспечение, отвечающее за запуск контейнеров (например, containerd, CRI-O или устаревший Docker Engine). Kubelet взаимодействует с ним через интерфейс CRI (Container Runtime Interface).

Сравнительная таблица

АспектMaster NodeWorker Node
Основная рольУправление и координация кластераИсполнение рабочей нагрузки (контейнеры)
Ключевые компонентыAPI Server, etcd, Scheduler, Controller ManagerKubelet, Kube-proxy, Container Runtime
ОтветственностьПланирование, состояние кластера, API, хранение конфигурацииЗапуск и поддержание контейнеров, сетевая проксировка
МасштабированиеКоличество ограничено (обычно 3 или 5 для HA)Может масштабироваться до сотен или тысяч узлов
Пользовательские <br>поды/контейнерыОбычно не запускаются (иногда системные)Все пользовательские приложения запускаются здесь
ДоступностьКритична для работы всего кластераПотеря одного узла — частичная деградация (поды перезапускаются на других)

Пример взаимодействия на практике

Представим, что вы развертываете приложение с помощью команды kubectl apply -f deployment.yaml.

  1. kubectl отправляет манифест в kube-apiserver на Master Node.
  2. kube-apiserver валидирует запрос и сохраняет состояние желаемого развертывания в etcd.
  3. Deployment Controller (часть kube-controller-manager) замечает новое желаемое состояние и создает объект ReplicaSet через API-сервер.
  4. ReplicaSet Controller видит, что нужно создать 3 пода, и через API-сервер создает объекты Pod (пока без привязки к узлу).
  5. kube-scheduler замечает новые незапланированные поды. Он анализирует требования и доступные ресурсы на всех Worker Nodes и принимает решение, на каком узле запустить каждый под. Это решение записывается через API-сервер обратно в etcd.
  6. Kubelet на выбранном Worker Node, постоянно опрашивая API-сервер, видит, что ему назначен новый под.
  7. Kubelet инструктирует Container Runtime (например, containerd) загрузить образ и запустить контейнер(ы) пода.