В Kubernetes слово node означает обычную рабочую машину в кластере. Это может быть железный сервер или виртуалка в облаке — для Kubernetes разницы почти нет. На этих машинах и крутятся ваши поды, то есть всё приложение в итоге физически живёт именно там. У каждого узла есть ресурсы — CPU, память, диск — которыми оркестр пользуется при планировании.
Внутри node’а всегда работает базовый «набор выживания»:
kubelet— агент, который общается с control plane, следит, чтобы нужные поды были запущены, и отчитывается об их состоянии;kube-proxy— настраивает iptables/ipvs или что там выбрано, чтобы трафик доходил до сервисов и подов как надо;- container runtime (containerd, CRI-O и т.п.) — та самая штука, которая реально стартует контейнеры.
Проще говоря: если упал узел — упало всё, что на нём крутилось. От количества и состояния nodes зависит, потянет ли кластер нагрузку, как будет масштабирование и насколько спокойно вы переживёте пик трафика или обновление. Кластер может состоять из пары нод, а может — из сотен, и Kubernetes сам раскидывает поды по ним в зависимости от ресурсов и ограничений.
Работать с узлами обычно приходится через kubectl:
kubectl get nodes— посмотреть список нод и их статус;kubectl cordon <node-name>— пометить узел как недоступный для новых подов (но старые останутся);kubectl drain <node-name>— аккуратно выгнать поды с узла перед обновлением или выводом из эксплуатации.
В архитектуре Kubernetes есть довольно жёсткое разделение ролей:
- Control Plane — «мозг» кластера, принимает решения: что, где и когда запускать;
- Nodes — «руки», которые эти решения исполняют, запускают поды и тянут реальный трафик.
Если вы администрируете кластер, важно понимать не только абстрактные Deployment’ы, но и то, что происходит на самих узлах: сколько там свободных ресурсов, не забит ли диск, не ушла ли нода в NotReady. От этого напрямую зависят и стабильность, и возможность масштабироваться.
Архитектура Kubernetes: Control Plane и Node #
Control Plane (управляющий уровень) #
Этот слой отвечает за все «управленческие» решения в кластере. Пользователь что-то применяет — сюда прилетает запрос, тут его обрабатывают, тут решают, на какую ноду посадить под, и вообще, всё ли в порядке.
kube-apiserver— центральная точка входа, весьkubectlи все операторы стучатся сюда;etcd— хранилище состояния кластера в формате key-value, тут лежат все манифесты и актуальное состояние;kube-scheduler— выбирает, на какой node отправить новый под, учитывая ресурсы, taints/tolerations и прочие ограничения;kube-controller-manager— контроллеры, которые следят, чтобы «заявленное» сходилось с «фактическим» (реплики, ноды, namespace и т.д.);cloud-controller-manager— общается с облаком (если оно есть): создаёт балансировщики, диски, обновляет статусы нод.
Сам control plane ваши обычные поды приложений не крутит. Он ими управляет: принимает манифесты, решает, что с ними сделать, и отдаёт команды рабочим узлам.
Nodes (рабочие узлы) #
Nodes — это просто машины, на которых уже реально запускаются контейнеры. Для кластера это «рабочие лошадки». На каждой ноде есть минимум:
kubelet— общается с API-сервером и следит за локальными подами;kube-proxy— крутит сетевые правила и помогает с доступом к сервисам;- container runtime — тот самый движок для контейнеров (containerd, CRI-O, Docker и пр.).
Узел получает от control plane инструкции вида «запусти вот этот под с такими-то параметрами» и дальше выполняет. Плюс он же репортит состояние, ресурсы, ошибки и т.д.
Связь: как всё работает #
- Вы делаете
kubectl apply— запрос летит вkube-apiserver; - Control plane решает, что с этим манифестом делать и где его разместить;
kube-schedulerподбирает подходящий node;kubeletна выбранной ноде поднимает контейнеры из пода через container runtime;kube-proxyобеспечивает сетевую доступность пода и его сервисов.
