Эксперты в подборе IT-оборудования
Допустим, вы запустили своё первое приложение в контейнере. Всё работает, вы довольны. Потом приложение начинает расти: появляется отдельный сервис для авторизации, отдельный для базы данных, ещё один для отправки уведомлений. Контейнеров становится десять, потом двадцать. И вот вы уже вручную следите за тем, какой из них упал, перезапускаете их в правильном порядке, вручную переносите нагрузку с перегруженного сервера на свободный.
Это не масштабирование. Это ручной труд, который рано или поздно даёт сбой - обычно ночью в пятницу.
Kubernetes решает именно эту проблему. Не «как запустить контейнер», а «как управлять сотнями контейнеров так, чтобы не сойти с ума».
K8s - сокращение от Kubernetes: между «K» и «s» ровно восемь букв. Это open-source платформа для оркестрации контейнеров: она автоматически развёртывает приложения, следит за их работой, перезапускает упавшие сервисы и распределяет нагрузку между серверами.
Платформу создал Google на основе внутреннего опыта с системой Borg, которая управляла их собственной инфраструктурой. В 2014 году Google открыл код и передал проект в Cloud Native Computing Foundation. Сегодня K8s - стандарт де-факто для запуска контейнеризованных приложений в production.
Чтобы понять, зачем он нужен, полезно разобраться, что вообще такое контейнер и почему одного Docker для серьёзной работы не хватает.
Контейнер - это изолированная упаковка для приложения. Внутри лежит сам код, все его зависимости и конфигурация. Контейнер запускается одинаково на любом сервере, где установлен Docker, без сюрпризов в духе «а у меня локально работало». Если тема контейнеров для вас новая, начните с разбора что такое контейнеризация.
Docker - это инструмент для создания и запуска контейнеров. Он отлично справляется на одной машине. Но представьте, что ваше приложение разбито на двадцать сервисов, и они должны работать на нескольких серверах одновременно. Кто решает, какой сервис запустить на каком сервере? Кто перезапускает упавший контейнер? Кто добавляет новые копии сервиса, когда нагрузка растёт?
Docker Engine на эти вопросы не отвечает. Kubernetes - отвечает.
| Что умеет | Docker Engine | Kubernetes |
|---|---|---|
| Запускать контейнеры | да | да |
| Управлять одним сервером | да | да |
| Управлять кластером серверов | нет | да |
| Перезапускать упавшие сервисы | частично | да |
| Масштабировать под нагрузку | нет | да |
| Распределять трафик | нет | да |
Оговорка для точности: речь именно про Docker Engine. У Docker есть собственный оркестратор - Swarm, он кластер умеет и для небольших задач бывает достаточным. Есть и третий вариант, Nomad. Чем они отличаются друг от друга и от Kubernetes, разобрано в статье про оркестрацию контейнеров. А если хочется понять, чем контейнер отличается от того, что даёт LXC, - есть сравнение Docker и LXC.
Если провести аналогию: Docker - это грузовик, Kubernetes - это диспетчерская служба, которая знает, куда какой грузовик отправить, следит за маршрутами и вызывает замену, если один из грузовиков сломался.
Насколько велик может быть масштаб: на конференции GlueCon в мае 2014 года инженер Google Джо Беда рассказал, что компания запускает более 2 миллиардов контейнеров в неделю. Kubernetes - переосмысление этого опыта для всех остальных.
Kubernetes работает с группой серверов - это называется кластер. Внутри кластера есть два типа узлов с принципиально разными ролями.
| Тип узла | Что это | Что делает |
|---|---|---|
| Control plane | Управляющий уровень, мозг кластера | Принимает решения, где и что запускать, следит за состоянием системы, реагирует на изменения. Сюда идут ваши команды |
| Worker node | Рабочий узел | Здесь непосредственно работают контейнеры с вашими приложениями. Узлов может быть три, может быть триста - Kubernetes управляет ими одинаково |
Внутри control plane живут несколько компонентов, и у каждого своя работа.
| Компонент | Роль |
|---|---|
| API Server | Единая точка входа: все команды идут через него |
| Scheduler | Планировщик: решает, на каком узле запустить новый контейнер, учитывая свободные ресурсы |
| Controller Manager | Следит, чтобы реальное состояние кластера совпадало с желаемым. Контейнер упал - создаёт новый |
| etcd | База данных, где хранится всё состояние кластера |
| kubelet | Живёт на каждом рабочем узле: общается с control plane и следит за контейнерами на своём сервере |
Отдельно про etcd: если он недоступен, кластер теряет управление. Поэтому его бэкапят отдельно и тщательно, а под сам etcd выделяют быстрые локальные диски - он чувствителен к задержкам записи.
Вопрос, который в учебных материалах обычно опускают, а у того, кто собирает кластер, он встаёт первым. Несколько ориентиров.
Память важнее ядер. Поды на узле делят его память, и переподписки здесь нет: сколько просуммировали лимитов, столько и нужно физически, плюс запас на саму операционную систему и kubelet. Процессор Kubernetes умеет делить долями (те самые 250m из примера ниже), память - нет.
Три узла control plane, а не один. etcd работает по кворуму, и для отказоустойчивости нужно нечётное число узлов от трёх. Один управляющий узел - это учебный стенд, а не production.
Локальные диски под etcd. Сетевое хранилище тут работает плохо: etcd упирается в задержку записи, а не в объём.
Запас на переезд подов. Если узел выведут на обслуживание, его поды поедут на соседние. Кластер, загруженный на 95 %, этого не переживёт - закладывайте свободную ёмкость хотя бы на один узел.
Как из отдельных серверов собирается отказоустойчивая связка, разобрано в материале про кластер серверов.
Три термина, без которых невозможно понять K8s.
Pod - минимальная единица в Kubernetes. Это один или несколько контейнеров, которые всегда работают вместе на одном узле и делят общий сетевой адрес. Обычно в поде живёт один контейнер - с вашим приложением. Поды временные: они создаются, умирают и пересоздаются. Kubernetes не «лечит» упавший под, он просто создаёт новый.
Deployment - описание того, как должно работать ваше приложение: какой образ использовать, сколько копий держать живыми, как обновлять при выходе новой версии. Вы говорите Deployment: «мне нужно три копии этого сервиса». Он создаёт три пода и следит, чтобы их всегда было именно три. Упал один - Deployment поднимает новый.
Service - стабильный сетевой адрес для доступа к группе подов. Поды пересоздаются и получают новые IP-адреса, а Service остаётся неизменным. Именно через Service другие части приложения обращаются к вашему сервису: они не знают и не должны знать, на каком узле и под каким IP он сейчас работает.
Вот как выглядит простой Deployment в виде конфигурационного файла:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-app
image: nginx:1.30
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
Два места в этом файле стоят отдельного внимания.
Блок resources - не опция для продвинутых. Без него один контейнер может съесть всю память узла и положить соседей. Kubernetes не угадывает, сколько ресурсов нужно вашему приложению, вы указываете это явно. requests - сколько гарантированно выделить, limits - выше чего не пускать.
Тег образа - nginx:1.30, а не nginx:latest. С плавающим тегом два пода одного Deployment могут оказаться разных версий, а откат перестаёт быть предсказуемым.
Для разработчика и администратора Kubernetes - это автоматизация рутины. Но у IT-руководителей свои вопросы: зачем платить за сложность, если и так всё работает?
Три конкретных аргумента.
Отказоустойчивость. Когда сервер падает, Kubernetes автоматически переносит поды на оставшиеся узлы. Приложение продолжает работать, пользователи могут ничего не заметить. Без оркестрации та же ситуация требует ручного вмешательства и означает простой.
Масштабирование без человека. HPA (Horizontal Pod Autoscaler) следит за нагрузкой и добавляет или убирает копии сервиса автоматически. Пришёл неожиданный трафик - K8s поднял дополнительные поды. Нагрузка спала - лишние убраны. Платите за реально используемые ресурсы, а не за запас на всякий случай. Насколько это выгодно в деньгах, зависит от того, как сильно ваша нагрузка гуляет: у сервиса с ровным трафиком экономии почти не будет, у сезонного она заметна.
Обновления без даунтайма. Rolling update - стандартный механизм в Kubernetes. Новая версия приложения разворачивается постепенно: поды со старой версией заменяются новыми по одному. Если что-то пошло не так, откат занимает одну команду.
Общий знаменатель у всех трёх - время реакции. У Kubernetes оно измеряется секундами, у дежурного, который смотрит в дашборд, - минутами. На SLA это видно.
Разворачивать production-кластер с нуля для знакомства с K8s избыточно. Есть инструменты, которые поднимают кластер на вашем ноутбуке за несколько минут.
Minikube - самый популярный вариант для начала. Разворачивает однонодовый кластер поверх Docker или виртуальной машины. Достаточно, чтобы понять базовые концепции и попробовать первые команды:
minikube start --driver=docker
kubectl get nodes
kind (Kubernetes IN Docker) - альтернатива, которая умеет имитировать несколько узлов на одной машине. Ближе к реальному кластеру, полезен, когда хочется понять, как работает взаимодействие между узлами.
Оба инструмента бесплатны, оба работают на Linux, macOS и Windows. Для первого знакомства разницы почти нет - берите minikube.
Две вещи, которые новички обычно настраивают в последнюю очередь и потом жалеют.
RBAC - разграничение прав доступа внутри кластера. После первоначальной настройки у вас есть полный admin-доступ везде. В production это неприемлемо: разные команды и сервисы должны иметь доступ только к тому, что им реально нужно. RBAC позволяет настроить это точно: этот сервис-аккаунт читает поды только в своём namespace, этот разработчик деплоит только в staging, но не в prod.
Secrets - хранение паролей, токенов и ключей. Kubernetes умеет хранить чувствительные данные отдельно от кода приложения. Базовая реализация сохраняет их в etcd в формате base64 - это не шифрование, а просто кодирование. Для серьёзного использования настраивают шифрование at rest или интеграцию с внешними хранилищами вроде HashiCorp Vault.
Обе темы выглядят как «разберёмся потом». На практике «потом» наступает вместе с инцидентом. Что ещё стоит закрыть до боевой нагрузки, собрано в разборе контейнеры в production.
Голый Kubernetes из upstream ставят редко: он даёт ядро, но всё вокруг - сеть, хранилище, мониторинг, обновления, разграничение доступа - приходится собирать самому. Поэтому в производственных внедрениях берут платформу, где это уже собрано и поддерживается вендором.
Для российского заказчика набор здесь свой. По обзорам рынка 2026 года в верхней группе идут Боцман, Nova Container Platform от Orion Soft, Штурвал от «Лаборатории Числитель» и Deckhouse Kubernetes Platform от «Фланта». Deckhouse развивают с 2017 года, у команды больше 240 внедрений, и его же берут под капот некоторые российские облака.
Отдельная история - сертификация. Если данные подпадают под требования регулятора, смотреть надо не на платформу вообще, а на конкретную редакцию: сертифицированные ФСТЭК версии есть у Nova (Special Edition), у Deckhouse (Certified Security Edition) и у Боцмана, получившего сертификат в декабре 2025 года. Обычная редакция того же продукта требованиям не удовлетворяет, и это первое, что проверяют в закупке.
Про managed-кластеры стоит сказать прямо. EKS у Amazon, GKE у Google и AKS у Microsoft российскому заказчику недоступны - ни по оплате, ни по требованиям к размещению данных. Их роль играют либо кластеры у российских облачных провайдеров, либо своё железо с одной из перечисленных платформ. Второй вариант выбирают, когда данные нельзя выносить наружу или когда постоянная нагрузка делает аренду дороже покупки.
Если кластер разворачивается на собственном оборудовании, заранее решите вопрос с платформой виртуализации под узлы - какой гипервизор выбрать, мы разбирали в отдельном материале.
Kubernetes - это не продукт, который ставится один раз и забывается. Это экосистема, которая продолжает развиваться.
После базового знакомства открываются следующие уровни. Helm - менеджер пакетов для K8s: вместо того чтобы писать десятки YAML-файлов вручную, вы используете готовые чарты для PostgreSQL, Redis, Prometheus и сотен других инструментов. Operators - механизм для автоматизации сложной логики управления приложениями: резервное копирование базы данных, failover, обновления со специфической бизнес-логикой. Service Mesh (Istio, Linkerd) - дополнительный уровень контроля над сетевым трафиком между сервисами: шифрование, детальные метрики, канареечные деплои.
Порог входа у Kubernetes действительно высокий. Первые несколько дней всё кажется избыточно сложным. Потом начинаешь понимать логику - и она оказывается довольно стройной. Каждая абстракция решает конкретную проблему, которая неизбежно возникает при работе с контейнерами в масштабе.
Хорошая новость: minikube на ноутбуке, официальная документация kubernetes.io и пара часов экспериментов дают достаточно контекста, чтобы перестать бояться этого слова и начать разбираться всерьёз.
По теме: мониторинг виртуальных машин и контейнеров, виртуализация и контейнеризация: отличия.
Считаете, на каком железе поднимать кластер?
Инженеры ITTELO подберут узлы под ваш профиль нагрузки - с нужным объёмом памяти, локальными дисками под etcd и запасом на переезд подов, соберут и протестируют их перед отгрузкой, с гарантией и поддержкой после продажи. На рынке серверов 11+ лет.
