Control plane (api-server, etcd, scheduler)
Тема дорожной карты · Kubernetes
Плоскость управления Kubernetes — это набор компонентов, поддерживающих желаемое состояние K8s-кластера: они принимают глобальные решения о планировании, реагируют на события кластера и предоставляют API Kubernetes клиентам. kube-apiserver — фасад плоскости управления, валидирующий и сохраняющий всё состояние ресурсов в etcd — распределённое хранилище ключей и значений с сильной согласованностью, являющееся единственным источником истины для каждого объекта Kubernetes. kube-scheduler наблюдает за вновь созданными Pod'ами без назначенного узла и выбирает оптимальный узел на основе запросов ресурсов, nodeSelector, правил affinity/anti-affinity и taints/tolerations, а kube-controller-manager запускает циклы согласования для контроллеров ReplicaSet, Deployment, StatefulSet, Job и CronJob. В высокодоступных кластерах Kubernetes плоскость управления реплицируется на три или пять узлов: etcd использует протокол консенсуса Raft, а kube-apiserver находится за балансировщиком нагрузки, так что сбои плоскости управления не прерывают работу запущенных рабочих нагрузок.
Как это работает
Control plane (api-server, etcd, scheduler) структурирован вокруг control plane и node plane Kubernetes. В control plane: API-сервер, etcd (хранилище состояния кластера), scheduler и controller-manager. В node plane: kubelet (агент, исполняющий pods), kube-proxy (сетевой слой) и container runtime. Решения по Control plane (api-server, etcd, scheduler) идут от API-сервера через контроллеры и применяются на нодах.
Когда применять
Понимание Control plane (api-server, etcd, scheduler) важно когда (а) вы отлаживаете проблемы кластера и нужно знать, какой компонент виноват, (б) sизируете кластер и решаете control-plane vs worker ресурсы, (в) проектируете HA-топологию (multi-master, etcd quorum), (г) выбираете между managed K8s (EKS/GKE/AKS) и self-managed. Без этого фундамента ошибки kubectl становятся гаданием.
Типичные ошибки
Архитектурные ловушки с Control plane (api-server, etcd, scheduler): 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.
Связанные понятия
Полезные ресурсы
Проверить знания (1)
Загрузка вопросов…