Worker nodes и kubelet
Тема дорожной карты · Kubernetes
Рабочие узлы — вычислительные машины в кластере Kubernetes — физические серверы, виртуальные машины или облачные инстансы, — запускающие Pod'ы приложений под руководством плоскости управления. Каждый рабочий узел запускает три основных компонента: kubelet — агент, регистрирующий узел в kube-apiserver, отслеживающий назначенные Pod'ы, дающий команды containerd или CRI-O загружать образы и запускать контейнеры, а также сообщающий о статусе узла и потреблении ресурсов; kube-proxy — поддерживает правила iptables или IPVS для балансировки нагрузки на уровне Service; и CNI-плагин (Calico, Cilium, Flannel), подключающий сетевые интерфейсы Pod'ов и программирующий маршрутизацию между узлами. Ёмкость узла — выделяемые CPU, память, эфемерное хранилище и расширенные ресурсы, такие как количество GPU, — сообщается в kube-apiserver через NodeStatus kubelet и определяет, сколько Pod'ов kube-scheduler может разместить на каждом рабочем узле. Работоспособность узлов отслеживается через Node Lifecycle Controller в kube-controller-manager, который применяет taint node.kubernetes.io/not-ready:NoExecute и инициирует вытеснение Pod'ов, когда узел перестаёт отправлять heartbeat в течение --node-monitor-grace-period. В управляемых Kubernetes-сервисах (EKS, GKE, AKS) рабочие узлы группируются в пулы узлов или управляемые группы узлов, интегрирующиеся с Cluster Autoscaler для автоматического масштабирования на основе спроса ожидающих Pod'ов.
Как это работает
Worker nodes и kubelet структурирован вокруг control plane и node plane Kubernetes. В control plane: API-сервер, etcd (хранилище состояния кластера), scheduler и controller-manager. В node plane: kubelet (агент, исполняющий pods), kube-proxy (сетевой слой) и container runtime. Решения по Worker nodes и kubelet идут от API-сервера через контроллеры и применяются на нодах.
Когда применять
Понимание Worker nodes и kubelet важно когда (а) вы отлаживаете проблемы кластера и нужно знать, какой компонент виноват, (б) sизируете кластер и решаете control-plane vs worker ресурсы, (в) проектируете HA-топологию (multi-master, etcd quorum), (г) выбираете между managed K8s (EKS/GKE/AKS) и self-managed. Без этого фундамента ошибки kubectl становятся гаданием.
Типичные ошибки
Архитектурные ловушки с Worker nodes и kubelet: single-master control plane в production (один etcd-отказ = outage кластера), under-sizing control plane для размера кластера (1000+ pods требуют больше CPU API-сервера, чем дефолты), допущение что режимы kube-proxy (iptables vs IPVS) не важны — они важны на масштабе. Относитесь к control plane как к critical infrastructure со своим мониторингом и DR.