Архитектура кластера
Тема дорожной карты · Kubernetes
Архитектура Kubernetes — это распределённая система, разделяющая ответственность за управление кластером между плоскостью управления и плоскостью данных рабочих узлов, что обеспечивает автоматическое планирование, самовосстановление и горизонтальное масштабирование контейнеризированных рабочих нагрузок. Плоскость управления состоит из kube-apiserver (единственная точка входа для всех REST-операций), etcd (распределённое хранилище ключей и значений, хранящее всё состояние кластера), kube-scheduler (назначает Pod'ы на узлы с учётом запросов ресурсов и taints/tolerations) и kube-controller-manager (запускает циклы согласования для Deployment, ReplicaSet и StatefulSet). На каждом рабочем узле работают kubelet (взаимодействует с API-сервером и управляет CRI-совместимым контейнерным рантаймом, например containerd или CRI-O), kube-proxy (поддерживает правила iptables или IPVS для сетевого взаимодействия Service) и CNI-плагин, например Calico или Cilium. Понимание архитектуры Kubernetes является основой для надёжной эксплуатации K8s-кластеров, настройки RBAC-политик и диагностики проблем в etcd, API-сервере и компонентах уровня узла.
Как это работает
Архитектура кластера структурирован вокруг control plane и node plane Kubernetes. В control plane: API-сервер, etcd (хранилище состояния кластера), scheduler и controller-manager. В node plane: kubelet (агент, исполняющий pods), kube-proxy (сетевой слой) и container runtime. Решения по Архитектура кластера идут от API-сервера через контроллеры и применяются на нодах.
Когда применять
Понимание Архитектура кластера важно когда (а) вы отлаживаете проблемы кластера и нужно знать, какой компонент виноват, (б) sизируете кластер и решаете control-plane vs worker ресурсы, (в) проектируете HA-топологию (multi-master, etcd quorum), (г) выбираете между managed K8s (EKS/GKE/AKS) и self-managed. Без этого фундамента ошибки kubectl становятся гаданием.
Типичные ошибки
Архитектурные ловушки с Архитектура кластера: 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)
Загрузка вопросов…