Kubernetes

01Какие проблемы решает Kubernetes

Когда у вас несколько контейнеров на одном сервере, хватает Docker Compose. Когда десятки сервисов на двадцати машинах, появляются новые вопросы. На какой машине есть место для этого контейнера (планирование)? Кто перезапустит его, когда он упадёт, или перенесёт, когда умрёт машина (самовосстановление)? Как добавить копий, когда растёт трафик (масштабирование)? Как выпустить новую версию без простоя и откатиться, если она сломалась (rolling update'ы)? Как сервисам находить друг друга, если их адреса постоянно меняются (service discovery)? Kubernetes отвечает на всё это одной идеей: вы объявляете желаемое состояние, например три реплики web версии 1.4.2, а контроллеры непрерывно сравнивают с ним фактическое состояние и действуют, чтобы закрыть разрыв. Этот цикл согласования (reconciliation loop) — сердце Kubernetes.

• Control plane: API-сервер, планировщик, контроллеры, etcd (база данных кластера).
• Worker-ноды: kubelet запускает поды; container runtime запускает контейнеры.
• Всё — это API-объекты, которые вы создаёте, читаете и обновляете через kubectl или GitOps-инструменты.

02Pod'ы и Deployment'ы

Pod — наименьшая единица, которую запускает Kubernetes: один или несколько контейнеров с общим сетевым адресом, которые могут делить volume'ы. Поды одноразовые: при замене они получают новые имена и IP, поэтому напрямую их почти никогда не создают. Deployment управляет подами за вас: держит запрошенное число реплик и выполняет rolling update, когда вы меняете образ. Важны две проверки здоровья. Readiness probe говорит Kubernetes, когда под готов принимать трафик; liveness probe — когда под завис и его надо перезапустить. Resource requests говорят планировщику, сколько CPU и памяти зарезервировать; limits ограничивают потребление. Без requests планирование и автомасштабирование принимают плохие решения.

1apiVersion: apps/v1
2kind: Deployment
3metadata: { name: web }
4spec:
5  replicas: 3
6  selector: { matchLabels: { app: web } }
7  template:
8    metadata: { labels: { app: web } }
9    spec:
10      containers:
11        - name: web
12          image: registry.example.com/web:1.4.2
13          ports: [{ containerPort: 3000 }]
14          readinessProbe: { httpGet: { path: /healthz, port: 3000 } }
15          resources:
16            requests: { cpu: 250m, memory: 256Mi }
17            limits: { memory: 512Mi }

03Service'ы, конфигурация и автомасштабирование

Service даёт стабильное имя и виртуальный IP меняющемуся набору подов, выбранных по меткам, и балансирует нагрузку между готовыми из них. Другие поды обращаются к нему через DNS, например http://web. Service'ы типа ClusterIP доступны только внутри кластера; Service'ы типа LoadBalancer просят у облака внешний балансировщик. Конфигурация хранится вне образов: ConfigMap — для несекретных настроек, Secret — для паролей и ключей. Учтите, что по умолчанию Secret'ы лишь закодированы в base64, поэтому включите шифрование at rest и ограничьте, кто может их читать, или синхронизируйте их из внешнего менеджера секретов. HorizontalPodAutoscaler (HPA) меняет число реплик по CPU, памяти или пользовательским метрикам в пределах заданных вами минимума и максимума.

1apiVersion: v1
2kind: Service
3metadata: { name: web }
4spec:
5  selector: { app: web }
6  ports: [{ port: 80, targetPort: 3000 }]
7---
8apiVersion: autoscaling/v2
9kind: HorizontalPodAutoscaler
10metadata: { name: web }
11spec:
12  scaleTargetRef: { apiVersion: apps/v1, kind: Deployment, name: web }
13  minReplicas: 3
14  maxReplicas: 10
15  metrics:
16    - type: Resource
17      resource: { name: cpu, target: { type: Utilization, averageUtilization: 70 } }

04Как запрос доходит до пода

Проследим один запрос. Браузер через DNS превращает app.example.com в адрес облачного load balancer'а. Балансировщик передаёт запрос пограничному proxy кластера — это либо Ingress-контроллер, либо, всё чаще, реализация Gateway API. Этот proxy читает правила маршрутизации (хост и путь) и отправляет запрос в подходящий Service. Service, реализованный на каждой ноде через kube-proxy или eBPF data plane вроде Cilium, выбирает один готовый под из своих endpoint'ов и пересылает запрос на IP и порт пода. В этом списке только поды, прошедшие readiness probe, — так rolling update'ы не шлют трафик в контейнеры, которые ещё стартуют. Обратите внимание: популярный community-контроллер ingress-nginx был выведен из эксплуатации в марте 2026 года; новым кластерам стоит использовать Gateway API или поддерживаемый контроллер.

1apiVersion: gateway.networking.k8s.io/v1
2kind: HTTPRoute
3metadata: { name: web }
4spec:
5  parentRefs: [{ name: public-gateway }]
6  hostnames: ["app.example.com"]
7  rules:
8    - matches: [{ path: { type: PathPrefix, value: / } }]
9      backendRefs: [{ name: web, port: 80 }]

05Helm и управляемый Kubernetes

Реальным приложениям нужно множество YAML-файлов, которые слегка отличаются между staging и продакшеном. Helm упаковывает их в chart: шаблоны плюс файл значений, так что вы ставите или обновляете всё приложение одной командой и можете откатиться к предыдущему релизу. Многие сторонние инструменты (базы данных, мониторинг, cert-manager) распространяются как Helm chart'ы. Kustomize — альтернатива без шаблонов, встроенная в kubectl, с overlay'ями для каждого окружения. Самому держать control plane сложно, поэтому большинство команд используют управляемый Kubernetes: Amazon EKS, Google GKE, Azure AKS или DigitalOcean DOKS. Провайдер запускает и обновляет control plane, а на вас по-прежнему пулы нод, обновления ваших нагрузок, сетевые дополнения, политики безопасности и расходы. Готовьтесь регулярно обновлять версию Kubernetes: каждый минорный релиз upstream поддерживается примерно год.

1helm install web ./charts/web -f values.prod.yaml -n prod --create-namespace
2helm upgrade web ./charts/web -f values.prod.yaml -n prod --atomic --wait
3helm history web -n prod
4helm rollback web 3 -n prod
5kubectl rollout status deployment/web -n prod

06Когда Kubernetes — перебор и что использовать вместо него

Kubernetes приносит с собой много всего: сетевые плагины, ingress или gateway'и, сертификаты, секреты, RBAC, мониторинг, обновления и YAML для всего подряд. Для команды из нескольких разработчиков с одним продуктом эта платформенная работа может стоить больше, чем реальная инфраструктура продукта. Если приложение помещается на один-два сервера, Docker Compose с хорошими бэкапами и мониторингом проще, дешевле и легче в отладке. Если хочется контейнеров с меньшей эксплуатационной нагрузкой, управляемые контейнерные сервисы вроде AWS ECS с Fargate, Google Cloud Run или Fly.io берут на себя планирование и масштабирование без кластера, которым нужно управлять. Инструменты вроде Kamal деплоят контейнеры на обычные серверы с переключением без простоя. Выбирайте Kubernetes, когда у вас много сервисов, реальные потребности в масштабировании и люди, готовые отвечать за платформу.

• Один-два сервера: Docker Compose.
• Контейнеры без эксплуатации кластера: ECS/Fargate, Cloud Run, Fly.io.
• Простые деплои на несколько серверов: Kamal, Docker Swarm, Nomad.

07Внутри control plane: API server, etcd и watch'и

Каждый компонент Kubernetes общается только с API server; никто не обращается к etcd или друг к другу напрямую. API server аутентифицирует запрос, проверяет RBAC, прогоняет admission-контроллеры (мутирующие могут добавить значения по умолчанию или sidecar'ы, валидирующие — отклонить объекты, нарушающие политику) и сохраняет объект в etcd — консистентное key-value хранилище на протоколе Raft. Для записи etcd нужно большинство участников, поэтому кластеры держат три или пять членов: три переживают один отказ, пять — два. Контроллеры не опрашивают API: они открывают долгоживущие watch'и, получают поток изменений, держат локальный кэш и выполняют reconcile. Scheduler следит за подами без ноды, отсеивает ноды, на которые под не помещается, оценивает остальные и записывает свой выбор обратно. Kubelet на выбранной ноде видит назначенный ему под и запускает его контейнеры через container runtime.

• Admission: сначала мутирующие webhook'и, затем валидирующие webhook'и и политики.
• Кворум etcd: 3 члена переживают 1 отказ, 5 — 2.
• Делайте бэкап etcd или убедитесь, что это делает managed-провайдер.

08Requests, limits, классы QoS и троттлинг CPU

Requests — это то, что резервирует scheduler; limits — то, что принудительно применяет ядро. Вместе они определяют класс quality of service для каждого пода. Guaranteed: у каждого контейнера requests равны limits по CPU и памяти. Burstable: заданы какие-то requests или limits. BestEffort: не задано ничего. Когда на ноде заканчивается память, kubelet сначала вытесняет BestEffort-поды, затем Burstable-поды, превысившие свои requests. Превышение лимита памяти не обсуждается: контейнер убивает OOM killer, он показывает exit code 137 и причину OOMKilled и перезапускается. Превышение лимита CPU вместо этого приводит к троттлингу через CFS quota ядра, и троттлинг может давать большие всплески задержки нагруженному сервису, даже когда на ноде есть свободный CPU. Поэтому многие команды ставят лимит памяти равным request'у, аккуратно подбирают CPU requests и не задают CPU limits для чувствительных к задержке сервисов, а общий объём держат под контролем квоты namespace'ов.

1resources:
2  requests: { cpu: 500m, memory: 512Mi }
3  limits:   { memory: 512Mi }       # no CPU limit: avoid throttling
4 
5# diagnose
6# kubectl describe pod web-7d9f -n prod | grep -A3 "Last State"
7# kubectl top pod -n prod --containers

09Graceful shutdown и добровольные прерывания

Когда под удаляется — во время rollout'а, уменьшения числа реплик или drain'а ноды, — одновременно происходят две вещи: kubelet отправляет контейнерам SIGTERM, а endpoint-контроллер убирает под из endpoints Service'а. Прокси и балансировщики узнают об этом чуть позже, поэтому секунду-две трафик ещё может приходить в процесс, который уже завершается. Короткий sleep в preStop откладывает SIGTERM, пока маршрутизация не догонит. Дальше приложение должно перестать принимать новую работу, завершить текущие запросы и выйти в пределах terminationGracePeriodSeconds (по умолчанию 30), после чего его убьют. Для плановых событий вроде обновления нод PodDisruptionBudget говорит Kubernetes, сколько реплик может быть недоступно одновременно, и drain это учитывает. Topology spread constraints разносят реплики по разным нодам и зонам, чтобы один сбой никогда не выбил их все.

1spec:
2  terminationGracePeriodSeconds: 45
3  topologySpreadConstraints:
4    - maxSkew: 1
5      topologyKey: topology.kubernetes.io/zone
6      whenUnsatisfiable: ScheduleAnyway
7      labelSelector: { matchLabels: { app: web } }
8  containers:
9    - name: web
10      lifecycle:
11        preStop: { exec: { command: ["sleep", "5"] } }
12---
13apiVersion: policy/v1
14kind: PodDisruptionBudget
15metadata: { name: web }
16spec: { minAvailable: 2, selector: { matchLabels: { app: web } } }

10Базовая безопасность: Pod Security, RBAC и NetworkPolicy

По умолчанию кластер Kubernetes довольно либерален: любой под может общаться с любым другим, а под может работать от root с широкими привилегиями. Ужесточить это помогают три встроенных механизма. Pod Security Admission применяет Pod Security Standards на уровне namespace через метки: privileged, baseline или restricted. Restricted требует non-root, запрета повышения привилегий, сброшенных capabilities и профиля seccomp — это хорошая цель для namespace'ов приложений. RBAC должен следовать принципу наименьших привилегий: по возможности Role в namespace вместо ClusterRole, никаких wildcard-глаголов, и отключённое автоматическое монтирование токена service account для подов, которые никогда не обращаются к API. NetworkPolicy — это файрвол для подов: начинайте каждый namespace с default deny, а затем разрешайте только нужные потоки, например ingress от gateway и egress к базе данных и DNS. NetworkPolicy работают, только если их поддерживает CNI-плагин, как Calico и Cilium.

1apiVersion: v1
2kind: Namespace
3metadata:
4  name: prod
5  labels:
6    pod-security.kubernetes.io/enforce: restricted
7---
8apiVersion: networking.k8s.io/v1
9kind: NetworkPolicy
10metadata: { name: default-deny, namespace: prod }
11spec:
12  podSelector: {}
13  policyTypes: [Ingress, Egress]