Kubernetes Cluster: control plane, workers, services и operators

Зачем нужно знать

Kubernetes стал стандартным слоем оркестрации контейнеров, потому что решает не одну задачу, а целый набор повторяющихся production-проблем: запуск реплик, rolling deploy, self-healing, service discovery, health checks, конфигурация, секреты, storage, ingress, autoscaling и расширение платформы через controllers. Понимать Kubernetes нужно не как «место, где крутятся контейнеры», а как declarative control plane: вы описываете desired state, а контроллеры постоянно приводят actual state к desired.

Без этой mental model Kubernetes выглядит как большой набор YAML-ресурсов. С ней становится понятно, почему kubectl apply не «запускает pod напрямую», почему scheduler только назначает pod на node, почему kubelet отчитывается в apiserver, почему Service не является настоящим process-ом, и почему operator — это просто custom controller, работающий с CRD.

Для системного дизайна Kubernetes важен как платформа trade-offs. Он даёт portable ecosystem и operator pattern, но требует дисциплины: requests/limits, probes, RBAC, network policy, upgrade strategy, observability, backup etcd, admission control. Managed Kubernetes снимает часть боли control plane, но не снимает ответственность за workload-и и архитектуру кластера.

Mental model

Kubernetes — это распределённый reconciliation loop вокруг API Server и etcd. API Server принимает декларации и изменения статуса. etcd хранит desired и observed state. Scheduler выбирает node для pod-а. Controller Manager создаёт недостающие объекты и перезапускает упавшие реплики. Kubelet на каждой worker node получает pod specs и запускает контейнеры через containerd. Kube-proxy или eBPF dataplane программирует Service routing. Operators расширяют тот же механизм для доменных ресурсов вроде PostgresCluster.

Важная мысль: почти всё общается через API Server. Это не централизованный «исполнитель команд», а контрольная плоскость и источник состояния. Рабочая нагрузка бежит на worker nodes, а control plane хранит факты и координирует controllers. Если etcd теряет quorum, новые writes невозможны, но уже запущенные pods не исчезают мгновенно.

Service — это не контейнер и не load balancer сам по себе. Это стабильный виртуальный адрес и набор правил, которые направляют трафик к backing pods. Ingress, LoadBalancer, NodePort и ClusterIP отличаются точкой входа и операционными последствиями, но внутри всё равно надо понимать путь до pod IP.

Что показывает диаграмма

Диаграмма показывает большой production canvas: external traffic, ingress/services, HA control plane, две worker nodes, workload object types, extensions, security и storage. Снаружи есть User и CDN, которые идут через Ingress Controller. Cert Manager отвечает за TLS certificate flow. Service слой содержит LoadBalancer, NodePort и ClusterIP, чтобы сравнить способы входа в кластер.

Control plane включает kube-apiserver, etcd, kube-scheduler, controller-manager и cloud-controller-manager. На apiserver закреплены ADR-решения Kubernetes vs Nomad vs ECS и managed vs self-hosted control plane. На etcd показан trade-off 3-node vs 5-node quorum. Это важнее, чем просто список компонентов: диаграмма объясняет, почему платформа устроена именно так.

Worker nodes показывают pods, kubelet, kube-proxy и containerd. Kubelet управляет pod-ами и отчитывается в API Server. Containerd запускает контейнеры через CRI. Kube-proxy смотрит Endpoints/Service state и программирует iptables/IPVS или аналогичный dataplane. Storage слой показывает PersistentVolume, StorageClass, ConfigMap и Secret. Security слой показывает RBAC, ServiceAccount и PodSecurityStandard. Extension layer показывает CRD, Postgres Operator, Helm и CNI.

Сценарии и что они учат

HTTP Request учит отличать data plane от control plane. Пользовательский HTTPS-запрос идёт через Ingress, TLS проверяется через Cert Manager, затем запрос попадает в pod и читает PersistentVolume. API Server не стоит на пути каждого пользовательского request-а. Это частая ошибка новичков: control plane управляет, но не проксирует весь runtime traffic.

Deployment Rollout показывает declarative flow. kubectl apply отправляет desired state в API Server, RBAC проверяет права, состояние сохраняется в etcd, scheduler назначает pods на nodes, controller-manager следит за ReplicaSet, kubelets получают specs и запускают контейнеры через containerd. ADR-вывод: Kubernetes выигрывает там, где нужна стандартная модель rollout/self-healing, но цена — сложность всей цепочки.

Health Check показывает self-healing. Kubelet выполняет liveness probe, видит failure, сообщает статус, controller-manager замечает несоответствие desired replicas и actual health, pod перезапускается. Урок: probes являются частью контракта приложения с платформой. Неправильная liveness probe может сама создать outage, а отсутствие readiness probe отправит traffic в неготовый pod.

Service Routing (kube-proxy) показывает, что Service VIP — виртуальная абстракция. Kube-proxy смотрит Endpoints и программирует правила, которые DNAT-ят traffic к реальному pod IP. Это объясняет, почему ClusterIP «не пингуется как обычная машина», почему NodePort неудобен для production и почему LoadBalancer создаёт cloud resource через cloud-controller-manager.

Operator Reconciliation показывает extension model. CRD регистрирует новый kind PostgresCluster, Helm применяет custom resource, Operator watches API Server и создаёт StatefulSet, Service, ConfigMap, Secret и PVC. Урок: operator — это не магия и не bash-скрипт, а controller, который кодирует operational knowledge и постоянно приводит actual state к desired.

Trade-offs

ADR: Kubernetes vs Nomad vs ECS. Контекст: нужно оркестрировать десятки или сотни сервисов с rolling deploy, autoscaling, self-healing и экосистемой вокруг stateful workloads. Nomad проще и легче в эксплуатации, но ecosystem и CRD/operator story слабее. ECS удобен в AWS и снимает часть ops, но усиливает lock-in. Kubernetes сложнее, зато даёт CNCF ecosystem: Helm, Operators, Prometheus, Argo, Istio/Linkerd, cert-manager, CNI. Решение в пользу Kubernetes оправдано на горизонте нескольких лет и при потребности в переносимой платформе.

ADR: managed или self-hosted control plane. Self-hosted даёт контроль, но требует владеть etcd backups, certificate rotation, upgrades, security patches и HA masters. Managed EKS/GKE/AKS стоит денег за cluster control plane, но снимает undifferentiated heavy lifting. Практичное решение для большинства команд — managed. Self-hosted оправдан для on-prem, air-gapped, жёсткой регуляторики или особых требований к control plane.

ADR: etcd 3 vs 5 nodes. 3-node etcd терпит один отказ и имеет quorum 2. 5-node терпит два отказа, но каждый write должен ждать quorum 3, что повышает latency. 7-node обычно даёт diminishing returns. Для большинства кластеров 3 nodes достаточно; 5 nodes имеет смысл для крупных multi-AZ кластеров, где потеря двух masters реалистична и оправдывает latency.

ADR: Service type. ClusterIP хорош для internal-only traffic. NodePort прост для dev и bare metal, но неудобен: порт на каждой node, слабая L7-модель, больше ручной сетевой работы. LoadBalancer хорош для production external entrypoint в cloud, но создаёт платный cloud LB на service и требует контроля стоимости. Ingress часто используется поверх Service, чтобы объединять L7 routes, TLS и host/path routing.

ADR: Operators for stateful systems. Обычный StatefulSet даёт stable identity и PVC, но не знает, как делать failover Postgres, backup, restore, replication slots или version upgrade. Operator кодирует доменную эксплуатацию, но добавляет ещё один controller с собственными багами и правами. Используйте operator там, где operational knowledge действительно сложна; не заменяйте им простой Deployment.

Реальные системы

GKE, EKS и AKS являются managed Kubernetes offerings major cloud providers. OpenShift добавляет enterprise distribution, security defaults и developer tooling поверх Kubernetes. CNCF ecosystem включает Prometheus/Grafana для observability, Argo CD и Flux для GitOps, cert-manager для TLS, Cilium/Calico для CNI, ExternalDNS, KEDA, ingress-nginx, Gateway API controllers и множество database operators.

В больших компаниях Kubernetes часто становится внутренней платформой: product teams деплоят services через шаблоны, platform team владеет cluster upgrades, admission policies, observability и golden paths. В малых командах Kubernetes может быть избыточен: managed PaaS, ECS или Nomad иногда быстрее и дешевле, особенно если нет потребности в operator ecosystem.

Anti-patterns и типичные ошибки

Первая ошибка — воспринимать Kubernetes как бесплатный PaaS. Он даёт primitives, но не отменяет platform engineering. Без стандартов на resources, probes, logging, secrets и deployment policy каждая команда пишет свой хрупкий YAML.

Вторая ошибка — не задавать requests и limits. Scheduler не может корректно размещать pods без requests, а отсутствие limits или неправильные limits приводит к noisy neighbors, OOMKilled и непредсказуемой latency.

Третья ошибка — неправильные probes. Liveness, которая проверяет downstream DB, может перезапускать здоровое приложение во время чужого outage. Readiness, которая всегда true, отправляет traffic в pod до прогрева cache или migrations.

Четвёртая ошибка — хранить секреты как обычные ConfigMap или считать Kubernetes Secret шифрованием. Secret по умолчанию base64-encoded; для серьёзной защиты нужны encryption at rest, KMS, external secrets, Vault или SealedSecrets.

Пятая ошибка — давать слишком широкие RBAC права. ServiceAccount с cluster-admin внутри pod-а превращает SSRF или RCE в захват кластера. Минимальные роли и namespace boundaries должны быть default.

Шестая ошибка — использовать Kubernetes для stateful workloads без понимания storage и recovery. StatefulSet не делает базу данных highly available сам по себе. Нужны backup, restore tests, replication, anti-affinity, disruption budgets и operator/runbook.

Когда НЕ использовать

Не используйте Kubernetes для одного-двух сервисов без серьёзных требований к orchestration. Docker Compose, managed app platform, ECS/Fargate, Cloud Run или обычные VM могут быть дешевле и понятнее. Не используйте Kubernetes, если у команды нет времени владеть networking, security, upgrades и observability, даже в managed варианте.

Не используйте Kubernetes как замену архитектуре приложения. Он перезапустит pod, но не сделает handler идемпотентным, не исправит миграции, не обеспечит exactly-once и не спасёт от плохих timeouts. Не переносите stateful systems в Kubernetes только потому, что «всё должно быть в кластере»; сначала проверьте storage, backup и failure model.

Не используйте NodePort как основной production ingress в cloud, если доступен LoadBalancer/Ingress/Gateway API. Не ставьте operator для каждой мелочи: controller с cluster permissions должен приносить больше пользы, чем риска.

Дальше читать

• containers — базовая модель container runtime, image и isolation.
• raft — почему etcd quorum и leader election критичны для control plane.
• kubernetes-patterns — probes, sidecars, init containers, DaemonSet, StatefulSet, Jobs, configuration patterns.
• service-mesh — когда L7 traffic management выносится из приложения в sidecar/dataplane.
• gitops — как управлять desired state через Git и reconciliation.
• Kubernetes documentation: concepts, workloads, services, storage, security.
• Kubernetes in Action, Marko Luksa.
• Kubernetes Patterns, Bilgin Ibryam and Roland Huss.