Ты выучил Pod, Deployment, Service, разобрался с сетью и хранилищем. И тут всплывает вопрос, который старый курс стыдливо обходил одной строчкой "поставьте minikube": а на чём, собственно, запускать кластер в реальной жизни? Потому что Kubernetes - это не один продукт. Это спецификация API и набор компонентов, которые можно собрать десятком способов. И от того, какой способ ты выберешь, зависит, будешь ли ты по ночам чинить отвалившийся etcd или спокойно спать, пока облако чинит его за тебя.
Разберём по-честному: что значит managed kubernetes, где проходит граница его удобства, когда тебе реально нужен self-hosted kubernetes на kubeadm, зачем существуют k3s и Deckhouse, и как не переплатить и не утонуть в эксплуатации. Ключевая мысль, которую держи в голове весь урок: ты выбираешь не "лучший Kubernetes", а то, сколько control plane и эксплуатации ты готов взять на себя. Всё остальное - производные от этого.
Что вообще делится: control plane и data plane
Любой кластер состоит из двух частей. Control plane (управляющий слой) - это kube-apiserver, etcd, kube-scheduler, kube-controller-manager. Мозг кластера: хранит состояние, принимает kubectl, решает, куда поставить Pod. Data plane (рабочий слой) - это узлы (nodes), на которых крутятся kubelet, container runtime (в 2026 это containerd через CRI, dockershim давно вырезан) и твои контейнеры.
Вся разница между способами развёртывания - в том, кто отвечает за control plane. Это не философия, это деньги и бессонные ночи. etcd - это распределённая БД на Raft, которая обижается на медленные диски, требует резервных копий, ротации сертификатов и аккуратных обновлений по версиям без перепрыгивания. Если этим занимаешься ты - это self-hosted. Если облако - это managed. Давай пройдёмся по вариантам от "максимум удобства" к "максимум контроля".
Managed Kubernetes: облако держит мозг кластера
Облачный kubernetes - самый частый старт для команд без выделенной платформенной команды. Провайдер поднимает и обслуживает control plane сам: ты его даже не видишь как набор виртуалок, ты просто получаешь endpoint apiserver и kubeconfig. etcd-бэкапы, патчи безопасности apiserver, обновление минорных версий - не твоя забота.
В РФ-реалиях это в первую очередь Yandex Managed Service for Kubernetes и VK Cloud; на западных площадках - EKS (AWS), GKE (Google), AKS (Azure). Создание кластера в Yandex Cloud выглядит так:
Код: Выделить всё
yc managed-kubernetes cluster create \
--name prod-cluster \
--network-name default \
--zone ru-central1-a \
--master-version 1.30 \
--public-ip
Код: Выделить всё
yc managed-kubernetes cluster get-credentials prod-cluster --external
kubectl get nodes
Код: Выделить всё
NAME STATUS ROLES AGE VERSION
cl1abc-node-group-xxxx-aaa Ready <none> 3m v1.30.4
cl1abc-node-group-xxxx-bbb Ready <none> 3m v1.30.4
Теперь про деньги, потому что тут зарыта собака. В Yandex Managed Kubernetes ты платишь отдельно за мастер и за исходящий трафик, а узлы тарифицируются как обычные ВМ Compute Cloud. Мастер бывает двух типов: зональный (базовый, в одной зоне доступности) и региональный (высокодоступный, размазан по зонам и стоит дороже). Тарифы официально обновлялись в феврале 2026 - всегда сверяйся с актуальной страницей yandex.cloud/docs/managed-kubernetes/pricing, цифры из чужих гайдов устаревают. Практический вывод: для dev/stage бери зональный мастер и экономь, для прода - региональный, иначе плановое обслуживание одной зоны положит тебе control plane.
Где границы managed. Удобство не бесплатно с точки зрения контроля:
- Ты не можешь поставить произвольную версию apiserver или подкрутить его флаги вроде --feature-gates как угодно - доступно только то, что разрешил провайдер.
- Список CNI и версий ограничен. Хочешь свежий Cilium с eBPF и kube-proxy replacement - проверяй, поддерживает ли его провайдер, иначе придётся ставить руками поверх и бодаться с дефолтным сетевым плагином.
- Обновления control plane идут по расписанию провайдера и его темпом. Если тебе нужна фича из самого свежего минора в день релиза - managed её даст с задержкой.
- Аудит, шифрование etcd, кастомные admission webhooks на уровне apiserver - частично или совсем недоступны для тонкой настройки.
Self-hosted на kubeadm: полный контроль и вся эксплуатация на тебе
Self-hosted kubernetes - это когда control plane поднимаешь и держишь ты сам, обычно на bare-metal или своих ВМ. Канонический инструмент - kubeadm, официальный бутстраппер кластера. Он не управляет инфраструктурой (ВМ, диски - твоя забота), но корректно поднимает компоненты control plane, генерирует сертификаты и настраивает kubelet.
Первый узел:
Код: Выделить всё
kubeadm init \
--pod-network-cidr=10.244.0.0/16 \
--control-plane-endpoint=k8s-api.internal:6443 \
--upload-certs
Код: Выделить всё
Your Kubernetes control-plane has initialized successfully!
To start using your cluster, you need to run the following as a regular user:
mkdir -p $HOME/.kube
cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
You should now deploy a pod network to the cluster.
Then you can join any number of worker nodes by running:
kubeadm join k8s-api.internal:6443 --token abcdef.0123456789abcdef \
--discovery-token-ca-cert-hash sha256:1234...
Что ты получаешь и что берёшь на себя. Получаешь - абсолютный контроль: любая версия, любые флаги apiserver, любой CNI, шифрование etcd, свои сертификаты, размещение на своём железе (важно для требований по данным в РФ). Берёшь - всё: бэкапы etcd (snapshot save и проверка восстановления, не на бумаге), ротацию сертификатов раз в год (kubeadm certs check-expiration спасает от молчаливого протухания), обновления строго по миноруам без прыжков, HA-схему с тремя мастерами и кворумом etcd. Это полноценная работа платформенной команды.
kops - инструмент уровнем выше: он управляет и инфраструктурой тоже (создаёт ВМ, ASG, балансировщики), исторически силён на AWS. Думай о нём как о self-hosted с автоматизацией железа, но управление control plane по сути всё равно на тебе.
Deckhouse: готовая платформа поверх Kubernetes для РФ
Между "голым kubeadm" и "облачным managed" есть третий путь, очень популярный в России - Deckhouse от компании Flant. Это не отдельный дистрибутив "вместо Kubernetes", а платформа поверх апстримного Kubernetes: ты ставишь её на свои ВМ или bare-metal, а она приносит сразу собранный комплект - CNI, ingress/Gateway, мониторинг (Prometheus/Grafana), автоскейлинг узлов, политики безопасности, обновления - и управляет всем этим декларативно, как обычными ресурсами кластера.
Идея в том, что Deckhouse даёт managed-подобный опыт на своей инфраструктуре. Ты не отдаёшь control plane в чужое облако (важно, когда данные обязаны оставаться в твоём контуре), но и не собираешь весь стек руками из десятка Helm-чартов. Распространяется в редакциях: открытая Community Edition (CE), коммерческая Enterprise Edition (EE) с Istio service mesh, мультитенантностью, BGP, расширенной безопасностью, и есть сертифицированные security-редакции (CSE) для требований регуляторов. Ставится на публичные облака, OpenStack, vSphere и на голое железо.
Когда брать Deckhouse: есть своё железо или приватное облако, нужен предсказуемый продакшен без построения платформенной команды с нуля, важны РФ-сертификация и поддержка на русском. Когда не брать: тебе хватает публичного managed - тогда Deckhouse избыточен; или наоборот нужен ультратонкий контроль над каждым флагом apiserver - тогда платформа будет немного "своевольничать" своими дефолтами.
Лёгкие дистрибутивы: k3s, k0s и локальные kind/minikube
Отдельный класс - облегчённый Kubernetes для edge, IoT, dev и тонких узлов. Флагман - k3s от Rancher/SUSE. Это сертифицированный Kubernetes, упакованный в один бинарь меньше 100 МБ: control plane, kubelet, containerd - всё в одном процессе. Главная хитрость под капотом: по умолчанию k3s заменяет etcd на встроенный SQLite (для HA можно переключить на embedded etcd или внешнюю БД через слой kine). Запуск кластера - буквально одна команда:
Код: Выделить всё
curl -sfL https://get.k3s.io | sh -
k3s kubectl get nodes
Код: Выделить всё
NAME STATUS ROLES AGE VERSION
edge-01 Ready control-plane,master 30s v1.30.4+k3s1
k0s - идейный сосед: тоже один бинарь, но с упором на чистое отделение control plane от хост-системы (никаких зависимостей кроме ядра Linux) и гибкий выбор хранилища через kine. k3s выигрывает по размеру комьюнити, ARM-документации и экосистеме Rancher; k0s - там, где важна изоляция от ОС хоста.
Для чисто локальной разработки бери kind (Kubernetes in Docker - кластер из контейнеров, отлично для CI и тестов многоузловых сценариев) или minikube (одна ВМ, дружелюбен к новичкам). Это инструменты для ноутбука, не для прода - не путай.
Критерии выбора: дерево решений на практике
Сведём в работающий алгоритм, а не в абстрактные "зависит от задачи":
- Нет платформенной команды, данные можно в публичное облако -> managed (Yandex Managed Kubernetes, VK Cloud). Дефолт для 80% случаев.
- Данные обязаны жить в своём контуре, но строить платформу с нуля не хочешь -> Deckhouse на своём железе/приватном облаке.
- Нужен тотальный контроль над версиями и флагами, есть кому это эксплуатировать -> self-hosted kubernetes на kubeadm (или kops, если хочешь автоматизацию инфры).
- Edge, IoT, тонкий узел, филиал, CI -> k3s/k0s.
- Ноутбук разработчика, локальные тесты -> kind/minikube.
Типичные грабли и антипаттерны
- "Возьмём kubeadm, это же бесплатно". Бинарь бесплатный, эксплуатация - нет. Без человека на дежурстве self-hosted превращается в протухшие сертификаты и невосстановимый etcd. Самый дорогой "бесплатный" Kubernetes.
- Зональный мастер в проде. Дешевле на бумаге, но обслуживание одной зоны провайдером кладёт твой control plane. Для прода - только региональный/HA-мастер.
- k3s в большой продакшен на десятки узлов. SQLite-бэкенд по умолчанию не для этого. Либо переключай на embedded etcd/внешнюю БД, либо бери полноценный кластер.
- minikube/kind как стейджинг. Они не воспроизводят сеть, балансировщики и поведение облака. То, что работает в kind, может не работать в managed - стейджинг должен быть как прод.
- Vendor lock-in через проприетарные аннотации. Если завязал манифесты на специфичные аннотации балансировщика одного облака, переезд в другое будет болью. Держи переносимое ядро, провайдер-специфику изолируй (Kustomize-оверлеи).
- Подними k3s на любой Linux-ВМ одной командой из урока. Выполни kubectl get nodes и найди суффикс +k3s1 и роль control-plane,master - убедись, что мозг и узел совмещены.
- Запусти kubectl get pods -n kube-system и посмотри, что k3s принёс из коробки: Flannel, Traefik, local-path-provisioner, coredns.
- Если есть аккаунт Yandex Cloud - создай кластер командой yc managed-kubernetes cluster create (зональный мастер, чтобы не переплатить), подключись и сравни вывод get nodes: control-plane-узлов нет, у worker ROLES=<none>. Зафиксируй разницу подписи managed и k3s.
- Не забудь снести кластеры после лабы: yc managed-kubernetes cluster delete и k3s-uninstall.sh - чтобы не капал счёт.
- По какому полю вывода kubectl get nodes можно за секунду отличить managed-кластер от kubeadm-кластера и почему?
- Почему после kubeadm init узлы остаются в статусе NotReady и что нужно сделать?
- Чем хранилище состояния в k3s по умолчанию отличается от классического кластера и почему это ограничивает его в большом проде?
- В каком случае Deckhouse выигрывает у публичного managed, а в каком - проигрывает?
Ты не выбираешь "самый правильный Kubernetes" - ты выбираешь, сколько control plane и эксплуатации взять на себя. Managed (Yandex Managed Kubernetes, VK Cloud) - облако держит мозг, ты катишь приложения. Deckhouse - managed-опыт на своём железе для РФ-контура. Self-hosted на kubeadm - полный контроль ценой полной эксплуатации. k3s/k0s - один бинарь для edge и dev, kind/minikube - для ноутбука. Считай TCO в человеко-часах, а не только счёт провайдера, и держи манифесты переносимыми. Дальше в курсе мы возьмём конкретную платформу и пойдём вглубь - сети, безопасности и GitOps.
