← Back to notes

Архитектура кластера
Kubernetes

2026-04-26

#control-plane#etcd

Кластер Kubernetes — набор машин (физических или виртуальных), которые вместе запускают контейнеризированные приложения. Логически кластер делится на две части: control plane и worker nodes. Control plane управляет кластером, worker nodes выполняют нагрузки.

[source: kubernetes.io/docs/concepts/overview/components/]

Типы узлов

Control plane node — отвечает за API, планирование, reconciliation и хранение состояния кластера. На production разворачивают 3 или 5 control plane nodes: нечётное число для кворума etcd.

Worker node — запускает Pod с пользовательскими приложениями. Кластер может содержать от одного до тысяч рабочих узлов.

Компоненты control plane

kube-apiserver

Единственная точка входа в кластер. Предоставляет REST API — все операции чтения и записи состояния проходят через него. Обрабатывает аутентификацию, авторизацию и admission control. Горизонтально масштабируется: несколько экземпляров apiserver за балансировщиком.

[source: kubernetes.io/docs/concepts/overview/components/#kube-apiserver]

etcd

Распределённое key-value хранилище, где живёт всё состояние кластера — конфигурация и объекты (Pod, Service, ConfigMap и т.д.). Только kube-apiserver работает с etcd напрямую — остальные компоненты идут через API. Использует алгоритм Raft для консенсуса. Потеря etcd без backup = потеря всего состояния кластера.

[source: kubernetes.io/docs/concepts/overview/components/#etcd]

kube-scheduler

Отслеживает Pod без назначенного узла и выбирает для них подходящий worker. При выборе учитывает:

  • Запрошенные ресурсы (CPU, memory) — должны влезть в свободные ресурсы узла
  • Affinity/anti-affinity правила
  • Taints и tolerations
  • Ограничения топологии (spread constraints)

Scheduler не запускает Pod — он только записывает решение о назначении через API Server.

[source: kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler/]

kube-controller-manager

Запускает встроенные контроллеры — процессы, которые приводят текущее состояние кластера к желаемому. Каждый контроллер следит за своим типом объектов через API Server и реагирует на изменения.

[source: kubernetes.io/docs/concepts/overview/components/#kube-controller-manager]

Компоненты worker node

kubelet

Агент на каждом worker node. Получает от API Server описания Pod (PodSpec) и гарантирует, что контейнеры запущены и работают в соответствии со spec. Отчитывается о статусе Pod обратно в API Server. Не управляет контейнерами, созданными вне Kubernetes.

[source: kubernetes.io/docs/concepts/overview/components/#kubelet]

kube-proxy

Сетевой прокси на каждом узле. Реализует абстракцию Service: настраивает dataplane для маршрутизации трафика к Pod за Service. Режимы работы:

  • iptables — по умолчанию, создаёт правила NAT
  • nftables — stable с Kubernetes 1.33, рекомендуемая Linux-замена для старых iptables/IPVS режимов
  • IPVS — исторически использовался для больших кластеров, но deprecated в Kubernetes 1.35

[source: kubernetes.io/docs/concepts/overview/components/#kube-proxy]

Container Runtime

Среда выполнения контейнеров. Kubernetes работает с любым runtime, реализующим CRI (Container Runtime Interface):

  • containerd — стандартный выбор, используется по умолчанию в большинстве дистрибутивов
  • CRI-O — минималистичный runtime, разработан специально для Kubernetes

Docker как runtime удалён начиная с Kubernetes 1.24. Docker-образы продолжают работать — они соответствуют OCI-стандарту.

[source: kubernetes.io/docs/setup/production-environment/container-runtimes/]

Как компоненты взаимодействуют

┌─────────────────────────────────────────────────┐
│                 Control Plane                    │
│                                                  │
│  ┌──────────┐  ┌────────────┐  ┌─────────────┐  │
│  │   etcd   │◄─┤ API Server ├──┤  Scheduler  │  │
│  └──────────┘  └─────┬──────┘  └─────────────┘  │
│                      │                           │
│                      │         ┌──────────────┐  │
│                      ├─────────┤  Controller  │  │
│                      │         │  Manager     │  │
│                      │         └──────────────┘  │
└──────────────────────┼──────────────────────────┘
                       │
          ┌────────────┼────────────┐
          │            │            │
  ┌───────▼──┐  ┌──────▼───┐  ┌────▼─────┐
  │ Worker 1 │  │ Worker 2 │  │ Worker 3 │
  │ kubelet  │  │ kubelet  │  │ kubelet  │
  │ kube-    │  │ kube-    │  │ kube-    │
  │ proxy    │  │ proxy    │  │ proxy    │
  │ runtime  │  │ runtime  │  │ runtime  │
  └──────────┘  └──────────┘  └──────────┘

API Server — центральный хаб. Все компоненты общаются только через него:

  1. Scheduler запрашивает у API Server Pod без узла → принимает решение → записывает назначение через API Server
  2. Controller Manager наблюдает за объектами через API Server → создаёт/удаляет объекты через API Server
  3. kubelet получает PodSpec от API Server → отчитывается о статусе Pod
  4. etcd принимает записи только от API Server — прямой доступ других компонентов не предусмотрен
  5. kubectl отправляет HTTP-запросы к API Server

Типичные ошибки

Один control plane node на production. Падение control plane останавливает управление кластером — новые Pod не планируются, нет reconciliation. Работающие Pod продолжают работать.

Прямой доступ к etcd. Любое прямое взаимодействие с etcd (помимо backup/restore) минует валидацию API Server и может оставить кластер в несогласованном состоянии.

Нет backup etcd. etcd — единственное место, где хранится состояние кластера. Без регулярных snapshot восстановление после сбоя невозможно. Минимум — ежедневный etcdctl snapshot save.

Путаница kubelet и container runtime. kubelet не запускает контейнеры напрямую — он делегирует это container runtime через CRI. Если runtime недоступен, kubelet не сможет запускать Pod даже при живом API Server.

Ожидание, что control plane работает без ресурсов. На production нодах с control plane нужен запас CPU и memory для API Server, etcd и controller manager. Дефицит ресурсов на control plane приводит к медленной реакции кластера или сбоям.

Альтернативы

Managed Kubernetes (EKS, GKE, AKS) — провайдер управляет control plane. Не нужно думать о HA etcd и обновлениях control plane. Потеря контроля над конфигурацией API Server и etcd.

k3s — облегчённый Kubernetes. Один бинарный файл вместо набора компонентов, встроенный SQLite вместо etcd (для single-node). Подходит для edge/IoT и CI.

kind / minikube — локальные кластеры для разработки и тестирования. Не для production.

Talos Linux — immutable OS специально для Kubernetes. Control plane и worker nodes управляются через API, SSH недоступен. Хорошо для security-conscious production.

02: Pod →

Архитектура кластера Kubernetes | Aleksandr Suprun