Kubernetes: что это такое и как работает

Kubernetes (сокращённо K8s) — система оркестрации контейнеров с открытым исходным кодом: автоматизирует развёртывание, масштабирование и управление контейнерными приложениями в кластере серверов. Проще говоря, платформа берёт на себя рутину: где запустить контейнер, что делать при сбое, как распределить нагрузку между узлами и обновить приложение без остановки сервиса.

Название происходит от древнегреческого κυβερνήτης (kybernḗtēs) — «кормчий», «рулевой». Метафора точная: Kubernetes «ведёт» контейнеры через изменчивую среду кластера, где узлы выходят из строя, нагрузка скачет, версии сервисов обновляются, — и удерживает систему на курсе. K8s — классический нумероним по тому же принципу, что i18n.

Проект вырос из внутреннего опыта Google по управлению кластерами — систем Borg и её «младшего брата» Omega, где компания больше десяти лет отрабатывала принципы планирования задач и изоляции ресурсов. Google опубликовала исходный код Kubernetes в 2014 году, а годом позже вместе с Linux Foundation учредила фонд Cloud Native Computing Foundation (CNCF). Формально проект приняли в CNCF 10 марта 2016 года на уровне Incubating, а статус Graduated получил 6 марта 2018 года — согласно отчёту CNCF «Kubernetes Project Journey Report» (CNCF, 2024).

Kubernetes работает с контейнерами — изолированными средами выполнения приложения со всеми зависимостями, которые чаще всего собирают через Docker или аналогичные инструменты. Docker решает задачу упаковки приложения — одного контейнера на одной машине; Kubernetes решает задачу управления сотнями и тысячами таких контейнеров сразу на множестве машин.

Разница между контейнером и виртуальной машиной — не в масштабе, а в уровне изоляции. ВМ эмулирует полноценное оборудование и поднимает поверх гипервизора собственное ядро ОС — надёжная, но тяжёлая изоляция. Контейнер — изолированный процесс на том же ядре хост-системы: Linux-механизмы namespaces и cgroups разграничивают для него сеть, файловую систему и лимиты ресурсов, не создавая отдельное ядро с нуля. Поэтому контейнеры стартуют быстрее и экономнее по ресурсам, но дают более слабую изоляцию на уровне ядра, чем ВМ — если это критично, контейнеры запускают внутри отдельных ВМ ради дополнительного барьера безопасности.

Ключевая идея платформы — декларативный подход к управлению инфраструктурой в противовес императивному. При императивном управлении администратор описывает, как достичь результата: команда kubectl run mypod --image=nginx явно запускает под. При декларативном описывается, что должно быть в итоге, — манифест YAML фиксирует желаемое состояние, а Kubernetes сам решает, что делать: создать, обновить или пересоздать под после сбоя.

Разница между оркестрацией и ручным управлением видна на трёх ситуациях. Упал контейнер — служба замирает, пока инженер вручную не поднимет новый экземпляр на другом узле. Выросла нагрузка — масштабирование без автоматики требует ручного развёртывания и переконфигурирования балансировщика, «на лету» так не получится. Обновление версии на сотне контейнеров вручную растягивается на дни и часто требует остановки сервиса. Kubernetes закрывает все три сценария сам: пересоздаёт под на здоровом узле, масштабирует реплики под нагрузкой и обновляет поды последовательно — без простоя.

Кластер Kubernetes — это объединение узлов (node), логически разделённых на две плоскости: control plane (плоскость управления) и worker-ноды (плоскость выполнения). Принцип тот же, что «ведущий — ведомый»: control plane решает, что и где должно быть запущено, а worker-ноды физически исполняют эти решения.

Нода — физическая или виртуальная машина в кластере: чаще всего сервер в дата-центре или инстанс облачного провайдера. Control plane можно сравнить с «мозгом» кластера — он не запускает поды напрямую, а планирует и координирует. Worker-ноды — «руки»: исполняют его инструкции, размещают поды и отчитываются об их состоянии.

В продакшен-конфигурациях компоненты control plane обычно распределены по нескольким машинам ради отказоустойчивости, а кластер включает несколько worker-нод — это позволяет пережить отказ отдельного узла без потери доступности API или состояния кластера.

kube-apiserver — фронтенд управляющего слоя: любое изменение конфигурации — создание Deployment, изменение числа реплик, обновление Service — сначала проходит валидацию, а затем записывается в etcd. Компонент спроектирован для горизонтального масштабирования: можно запускать несколько экземпляров с балансировкой нагрузки между ними.

etcd — распределённое хранилище «ключ-значение» на основе протокола консенсуса Raft: один лидер и несколько фолловеров в каждый момент. Здесь хранится всё состояние кластера — объекты API, Secrets, ConfigMaps, данные о подах и узлах. Запись фиксируется только после fsync на диск у кворума узлов (N/2 + 1) — отсюда строгая согласованность. Если etcd падает, kube-apiserver не может ни читать, ни писать, и кластер парализуется; доступ к etcd идёт только через kube-apiserver.

kube-scheduler — планировщик: отслеживает поды без назначенного узла и подбирает им ноду в два этапа. На фильтрации отсеиваются ноды без достаточных ресурсов CPU и памяти, с несовместимыми taints, без нужных меток (NodeSelector) и без соответствия affinity/anti-affinity. На ранжировании оставшиеся ноды оцениваются по стратегиям — LeastAllocated (приоритет узлам со свободными ресурсами, по умолчанию), баланс CPU/RAM и наличие образа на ноде (ImageLocality). При равном балле выбор случаен.

kube-controller-manager запускает встроенные контроллеры, реализующие цикл согласования (reconciliation loop): читают желаемое состояние из etcd, сравнивают с фактическим и создают или удаляют объекты при расхождении. Среди них — Node Controller, следящий за здоровьем узлов, и Endpoints Controller, обновляющий список подов для Service.

cloud-controller-manager — опциональный компонент, который интегрирует кластер с API конкретного облачного провайдера для управления облачными узлами, сетью и балансировщиками — актуален для managed-кластеров в публичных облаках.

На каждой worker-ноде обязательно работают три процесса.
kubelet — агент ноды: регистрирует узел в API-сервере, получает от него спецификацию пода (PodSpec) и обеспечивает запуск, мониторинг и перезапуск контейнеров по этой спецификации. Kubelet непрерывно сравнивает текущее состояние пода с желаемым и обрабатывает пробы liveness/readiness, отправляя статус обратно в кластер для self-healing.

kube-proxy — сетевой прокси на каждой ноде, который реализует концепцию Service: поддерживает правила маршрутизации трафика к подам по стабильному виртуальному IP, независимо от того, что реальные IP-адреса подов меняются.

Между kube-proxy и физической сетью есть ещё один обязательный слой — сетевой плагин, реализующий спецификацию Container Network Interface (CNI): без него под на одной ноде не может напрямую достучаться до пода на другой ноде, а kubelet создаст под без маршрутизируемого сетевого интерфейса за пределами своей ноды. Плагин (например, Calico, Cilium или Flannel) разворачивается как DaemonSet на каждой ноде, выделяет подсети и маршрутизирует трафик между нодами, а у части реализаций — ещё и применяет Network Policy на уровне пакетов.

Container runtime — среда выполнения, которая запускает и останавливает контейнеры: containerd, CRI-O или, в устаревших конфигурациях, Docker через прослойку cri-dockerd. Взаимодействие kubelet со средой выполнения стандартизировано через Container Runtime Interface (CRI) — gRPC-протокол для подключения любого совместимого рантайма без пересборки кластера. По документации Kubernetes (CNCF), с версии 1.24 dockershim удалён — Docker не реализует CRI напрямую, — а с 1.26 kubelet требует CRI v1: без неё узел не зарегистрируется.

Работа с Kubernetes строится вокруг набора базовых абстракций — объектов API, которые описывают желаемое состояние приложения и инфраструктуры. Дальше — из чего в принципе состоит развёрнутое в кластере приложение.

Pod — минимальная и атомарная единица развёртывания в Kubernetes: логическое окружение для одного или нескольких контейнеров, которые запускаются совместно и разделяют сетевой стек, единый IP-адрес и, при необходимости, тома хранения. Контейнеры внутри пода видят друг друга как localhost и обмениваются данными через общие volumes — типичный пример — веб-сервер и sidecar-контейнер, читающий логи через общий том emptyDir.

Жизненный цикл пода проходит через фазы: Pending (ресурс создан, но под ещё не запланирован или образы не получены), Running (под назначен ноде, контейнеры запущены), Succeeded (все контейнеры завершились с кодом 0), Failed (хотя бы один завершился с ошибкой) и Unknown (статус не определить, обычно из-за проблем связи). Важный нюанс: сам под не «переезжает» на другую ноду при отказе исходной — контроллер вроде ReplicaSet замечает пропажу, а kube-scheduler размещает замену на здоровом узле.

Поды редко создают напрямую — обычно ими управляют контроллеры более высокого уровня, каждый под свой сценарий нагрузки.

Deployment — предпочтительный способ запуска stateless-нагрузок именно потому, что не хранит изменяемые данные внутри пода: любой под можно пересоздать без потери информации. StatefulSet решает обратную задачу — для баз данных и очередей, где важны стабильный сетевой идентификатор и привязка конкретной реплики к своему тому хранения.

Обновление версии через Deployment по умолчанию идёт стратегией rolling update: контроллер создаёт новый ReplicaSet, постепенно масштабирует новые поды, проверяет их readiness-пробами и лишь потом удаляет старые. Параметры maxUnavailable и maxSurge — по умолчанию оба 25% реплик — ограничивают, сколько подов недоступно и сколько лишних создаётся при обновлении. Более осторожный вариант — canary-развёртывание: новая версия сначала идёт на узкую группу пользователей и лишь потом на всех.

Прежде чем говорить о Service, стоит определить Labels — пары «ключ-значение», которыми размечают поды и другие объекты API; именно по ним Service, Deployment и другие контроллеры находят «свои» поды среди тысяч чужих.

Service — абстракция API, которая даёт группе подов постоянную точку сетевого доступа: стабильный виртуальный IP (ClusterIP) и DNS-имя, не зависящие от того, что реальные IP-адреса подов меняются при пересоздании. Набор подов под сервисом определяется селектором меток — сервис сам добавляет подходящие поды в список endpoints и убирает исчезнувшие. Балансировка идёт на транспортном уровне (L4, TCP/UDP) round-robin.

Типы сервисов различаются по способу доступа:

Namespace — механизм логической изоляции ресурсов внутри одного физического кластера: несколько виртуальных кластеров в одном. Имена объектов уникальны внутри namespace, но не между разными — удобно для разделения на команды, проекты или среды разработки (dev/staging/prod). Встроенные namespace — default (без явного указания), kube-system (служебные компоненты) и kube-public (общедоступные ресурсы, видимые даже неаутентифицированным пользователям). Namespace — основная граница безопасности: RBAC и Network Policy применяются именно на этом уровне.

Отдельно есть объекты для конфигурации: ConfigMap хранит нечувствительные настройки — URL, флаги, переменные окружения, а Secret — чувствительные данные: пароли, API-токены, TLS-сертификаты. Оба позволяют менять конфигурацию без пересборки образа. Важная деталь для безопасности: Secret по умолчанию только кодируется в Base64, а не шифруется — в etcd данные хранятся в открытом виде, если не настроено шифрование хранилища или дисков etcd.

Для данных, которые должны пережить пересоздание пода, используется связка Persistent Volume (PV) и Persistent Volume Claim (PVC). PV абстрагирует физическое хранилище — сетевой диск, облачный том, локальный SSD — независимо от жизненного цикла пода. PVC — запрос приложения на выделение хранилища с указанием размера и режима доступа; Kubernetes сам связывает PVC с подходящим PV. При статическом provisioning администратор заранее создаёт PV; при динамическом — кластер создаёт том на лету через StorageClass, описывающий тип диска, провайдера и политику удаления данных.

Механика управления кластером «в динамике» строится вокруг одного цикла: пользователь описывает желаемое состояние в YAML-манифесте и применяет его командой kubectl apply, kube-apiserver сохраняет спецификацию в etcd, kube-scheduler размещает поды на подходящих нодах, а kubelet запускает контейнеры по этой спецификации. Цепочка манифест → kube-apiserver → scheduler → kubelet описана в документе «Управление объектами Kubernetes» официальной документации проекта (kubernetes.io, актуально на 2024 год).

kubectl — консольный клиент, который отправляет манифесты в kube-apiserver (внутри они конвертируются в Protobuf). Базовые команды: kubectl apply -f file.yaml для создания или обновления ресурсов, kubectl get pods для списка, kubectl describe pod для деталей объекта, kubectl logs и kubectl exec для диагностики внутри контейнера.

Самовосстановление реализуется через три типа проверок здоровья. Liveness probe проверяет, «жив» ли контейнер: при провале kubelet перезапускает его, устраняя deadlock или зависший процесс. Readiness probe определяет готовность принимать трафик — при провале под исключается из балансировки Service, но не перезапускается. Startup probe блокирует обе проверки до успешного запуска приложения с долгой инициализацией, предотвращая ложные перезапуски на старте.

Автоматическое масштабирование работает на трёх уровнях. Horizontal Pod Autoscaler (HPA) меняет число реплик Deployment или StatefulSet по метрикам CPU, памяти или кастомным показателям, опрашивая metrics API каждые 15 секунд. Vertical Pod Autoscaler (VPA) меняет объём ресурсов уже запущенных подов, а не их количество. Cluster Autoscaler добавляет или убирает worker-ноды, когда подам не хватает места.

Важно не путать декларативность с «полной автономностью»: Kubernetes точно исполняет описанное состояние, но не оценивает его бизнес-логику. Типичная ошибка эксплуатации — задать лимиты ресурсов «на глаз», без сбора метрик по реальной нагрузке: это ведёт либо к троттлингу CPU, либо к OOM-килам подов.

Оценка технологии для бизнеса требует взвешивать реальную пользу против операционных издержек — Kubernetes не бесплатен в эксплуатации, даже если сам дистрибутив открыт и бесплатен.

Среди преимуществ — прежде всего независимость от облачного провайдера: Kubernetes работает одинаково в AWS, Google Cloud, Azure и on-premise благодаря единому API, что снижает риск vendor lock-in — Helm-чарты и манифесты переносятся между площадками без переписывания. Cluster Autoscaler подстраивает число worker-нод под нагрузку — по данным VK Cloud, это снижает расходы на инфраструктуру до 60% за счёт устранения простаивающих мощностей, хотя эффект зависит от исходной утилизации серверов и на практике укладывается в диапазон 30-60%. Мультиоблачные сценарии становятся практичнее, а managed Kubernetes ускоряет цикл разработки за счёт готовой интеграции с балансировщиками и хранилищами облака.

Масштаб adoption подтверждает зрелость технологии: по данным CNCF Annual Cloud Native Survey 2025 года (CNCF, публикация — январь 2026), 82% организаций, использующих контейнеры, запускают Kubernetes в production — рост с 80% в 2024 году и 66% в 2023 году.

Обратная сторона — ощутимые издержки эксплуатации. Порог входа высокий: многие процессы настраиваются вручную, а миграция между облаками требует опытной команды. Держать полноценную DevOps/SRE-команду своими силами часто невыгодно — специалистов с реальным опытом эксплуатации кластеров немного, и стоят они дорого. Сетевая организация усложняется — изоляция трафика между контейнерами начинается с настройки CNI-плагина, а хранилище требует отдельного подхода: сетевые тома медленнее локальных дисков, критично для высоконагруженных СУБД. Издержки Day 2 Operations тоже никуда не деваются: обновления несут свои риски, а TCO на старте обычно кажется ниже реальной — в неё стоит закладывать зарплаты инженеров и время на инциденты, а не только цену серверов.

Kubernetes оправдан там, где архитектура приложения и темп изменений реально требуют автоматизации оркестрации. Прежде всего это микросервисная архитектура с частыми релизами: платформа позволяет выкатывать новые версии продукта многократно за короткий срок, что критично при регулярных обновлениях десятков независимых сервисов. Оправдана она и при переменной нагрузке с горизонтальным масштабированием под пиковый трафик, а также при мультиоблачной стратегии, когда компания распределяет нагрузку между провайдерами ради бюджета и отказоустойчивости.

Обратная картина — монолитное приложение со стабильной нагрузкой: планировщик резервирует мощности, которые фактически не потребляются, а издержки оркестрации (сбор метрик, QoS-классы, ResourceQuota) превышают пользу. Отсутствие DevOps-экспертизы — отдельный ограничивающий фактор: для простых проектов кластер скорее усложняет эксплуатацию, чем упрощает её.

На практике ошибки Day 2 Operations редко ограничиваются лимитами «на глаз» — они складываются в набор: отсутствие PodDisruptionBudget роняет в недоступность больше подов, чем рассчитывал инженер, при плановом обслуживании; отсутствие ResourceQuota на уровне namespace позволяет одной команде исчерпать ресурсы кластера; игнорирование readiness-проб при rolling update пускает трафик на под, который формально запущен, но не готов его обрабатывать. По отдельности каждая ошибка малозначительна, но именно из их совокупности складывается разница между «Kubernetes запущен» и «стабильно держит продакшен-нагрузку».

Практический критерий для IT-директора: если команда не может назвать конкретный сценарий, где ей не хватает ручного управления контейнерами — частые релизы, нестабильная нагрузка, несколько сред развёртывания, — Kubernetes, вероятнее всего, добавит сложности без соразмерной выгоды.

Практический вопрос «как начать» сводится к выбору одной из трёх моделей эксплуатации.

Self-hosted Kubernetes — полная установка и обслуживание кластера на собственном или арендованном оборудовании: команда сама отвечает за control plane, worker-ноды, сеть, хранилище и безопасность. Это даёт максимальный контроль, но требует зрелой SRE-практики внутри компании.

Managed Kubernetes передаёт управление control plane (kube-apiserver, etcd, scheduler) облачному провайдеру — например, Yandex Cloud, VK Cloud или Selectel, — оставляя на стороне заказчика только workload и worker-ноды: это резко упрощает эксплуатацию, но добавляет зависимость от конкретной платформы провайдера.

Готовые Kubernetes-платформы вроде OpenShift, Rancher или Deckhouse — дистрибутивы поверх vanilla Kubernetes со встроенными CI/CD, RBAC, observability и управлением мультикластером, которых нет «из коробки» у базового дистрибутива. Если инфраструктура относится к значимым объектам критической информационной инфраструктуры (187-ФЗ) или должна соответствовать требованиям к отечественному ПО — российские платформы разрабатываются локальными командами, что обычно упрощает комплаенс, хотя и не отменяет отдельной оценки соответствия требованиям вашей организации.

Сам кластер редко эксплуатируют «в одиночку»: вокруг vanilla Kubernetes обычно добавляют пакетный менеджер Helm, service mesh для маршрутизации и наблюдаемости трафика между сервисами, отдельный стек мониторинга. Часть экосистемы уже встроена в готовые платформы; при self-hosted и managed-кластере это отдельная интеграция, которую закладывают в бюджет заранее.

При выборе модели стоит проверять CNCF conformance — сертификацию, которая подтверждает, что дистрибутив поддерживает все базовые API оркестратора и требуемые версии Kubernetes. Это гарантирует интероперабельность приложений между установками и свободу смены вендора; проверить соответствие можно самостоятельно через открытый инструмент Sonobuoy — тот же, что используется для официальной сертификации.

Расчёт аппаратных ресурсов под self-hosted-кластер подчиняется нескольким принципам, которые не меняются от масштаба развёртывания. Control plane критичен к отказоустойчивости etcd: хранилище принято разворачивать на нечётном числе узлов — как правило, трёх или пяти, — чтобы кворум (N/2 + 1) сохранялся даже при отказе одного узла. Диск под etcd — не место для экономии: запись фиксируется только после fsync у большинства узлов кворума, и задержка накопителя напрямую становится задержкой всего API, а на медленном или перегруженном диске это грозит таймаутами выборов лидера Raft и потерей кворума под нагрузкой — поэтому под etcd закладывают быстрый локальный NVMe, а не сетевой том общего назначения. На worker-нодах закладывают запас CPU и памяти сверх суммы запросов (requests) реальных подов — иначе планировщик исчерпает ресурсы раньше, чем это станет заметно по метрикам, — а сеть между control plane и worker-нодами дублируют по интерфейсам, чтобы отказ порта или коммутатора не обрывал связь с API-сервером.

Именно такие расчёты команда Work System проводила в проекте для логистического оператора «КазКонтракт Трейд»: за один месяц и в условиях ограниченного бюджета спроектировала и развернула отказоустойчивый кластер 1С и СУБД на оборудовании Dell, сохранив нужное качество поставки несмотря на осложнения, вызванные уходом части зарубежных производителей с российского рынка в период проекта. Для компаний без зрелой DevOps-команды, но с требованием контроля над данными и оборудованием, разумный компромисс — заказать проектирование и поставку серверной инфраструктуры под кластер внешнему интегратору, а эксплуатацию самого Kubernetes оставить своей команде или готовой платформе.