Администратор стоит перед домашним сервером или тремя виртуалками в облаке, держит в голове список сервисов для селф-хостинга и задаётся одним вопросом. Какой дистрибутив Kubernetes выбрать, чтобы не утонуть в конфигах, но и не получить игрушку, которая через полгода упрётся в потолок. Вариантов хватает, четыре из них стали фактическим стандартом: K3s от SUSE, K0s от Mirantis, MicroK8s от Canonical и kubeadm как официальный апстрим-инструмент от самой команды Kubernetes.
У каждого своя философия, свои компромиссы и свой характер. Выбор напоминает подбор инструмента в гараже - молоток и дрель вроде оба решают задачу крепления, но работают совершенно по-разному. Стоит разобраться в деталях, прежде чем тянуться к первой попавшейся кнопке Install.
Базовая география четырёх дистрибутивов и что ими вообще движет
K3s появился в 2019 году как ответ Rancher на проблему запуска Kubernetes на слабом железе. Один бинарник меньше 100 МБ, встроенный контроллер ingress (Traefik), собственный механизм сервисного балансировщика (ServiceLB), легковесное хранилище на SQLite по умолчанию вместо тяжеловесного etcd. Кластер поднимается одной командой, которая скачивает скрипт и запускает его. Именно такая простота сделала K3s де-факто стандартом для домашних лабораторий, Raspberry Pi и edge-развёртываний.
K0s от Mirantis пошёл похожим путём, но выбрал минимализм. Ванильный Kubernetes без дополнений, упакованный в один бинарник, без зависимостей от хостовой ОС кроме ядра Linux. Никакого встроенного ingress, никакого сетевого балансировщика из коробки. Пользователь сам решает, какой CNI, какое хранилище, какой контроллер трафика ему нужен. Подход для тех, кто хочет контроль, а не магию.
MicroK8s от Canonical делает ставку на удобство и экосистему. Устанавливается через snap одной командой, и с той же лёгкостью включаются аддоны: microk8s enable dns ingress metallb prometheus. Система зависит от snap, что для одних плюс, для других серьёзный минус. Но для Ubuntu-пользователя MicroK8s остаётся самым быстрым способом получить рабочий кластер с мониторингом, дашбордом и сертификатами.
Kubeadm стоит особняком. Это не дистрибутив, а инструмент официальной команды Kubernetes для разворачивания ванильных кластеров. Именно его рекомендуют тем, кто готовится к сертификации CKA, хочет разобраться в устройстве Kubernetes изнутри или планирует строить инфраструктуру без привязки к конкретному вендору. Ценой такого контроля становится объём ручной работы, kubeadm ничего не делает сам помимо инициализации кластера.
Потребление ресурсов и что происходит на слабом железе
Этот вопрос становится первым, когда под кластер отведено не десять серверов, а три мини-ПК на Intel N100 или пара Raspberry Pi. Цифры различаются не драматично, но достаточно, чтобы повлиять на выбор для ограниченных сред.
В свежих тестах на чистой виртуалке с 1 ГБ памяти картина складывается примерно такая. K0s держится в районе 400 - 600 МБ оперативы на idle-мастере, что делает его лидером по экономичности среди трёх "лайтвейтных". K3s при старте съедает около 650 - 700 МБ, потому что тащит за собой Traefik, ServiceLB и несколько других встроенных контроллеров. MicroK8s располагается рядом, 700 - 750 МБ в стандартной конфигурации, чуть меньше если отключить HA. Kubeadm в минимальной сборке с containerd и Calico обычно занимает 800 - 900 МБ на мастере, хотя итог сильно зависит от выбранного набора компонентов.
На устройствах с 1 ГБ памяти все три "лёгких" варианта начинают спотыкаться, как только на них пытаются развернуть реальные приложения. Практический минимум для комфортной работы - 2 ГБ RAM и 2 CPU-ядра на ноду, а для мастера серьёзного HA-кластера лучше 4 ГБ и больше. Тесты показывают, что K3s в режиме idle потребляет заметно больше CPU, чем MicroK8s и K0s, что становится важным фактором при длительной работе на аккумуляторе или на машинах с пассивным охлаждением.
Установка и первые минуты жизни кластера
Разница в установке отражает философию каждого дистрибутива.
K3s ставится одной строкой, и через тридцать секунд у администратора уже работающий кластер:
curl -sfL https://get.k3s.io | sh -
После этого доступны kubectl через /usr/local/bin/k3s kubectl и готовый kubeconfig в /etc/rancher/k3s/k3s.yaml. Добавление воркера сводится к получению токена с мастера и запуску ещё одной однострочки на рабочей ноде. Встроенный ingress, балансировщик и storage-класс работают сразу, без дополнительных настроек.
K0s предпочитает декларативный подход через k0sctl - отдельную утилиту для оркестрации установки. Конфиг кластера описывается в YAML-файле, где перечисляются хосты, их роли и параметры:
k0sctl init --k0s > k0sctl.yaml
k0sctl apply --config k0sctl.yaml
На выходе получается полноценный кластер, но без ingress-контроллера, без LoadBalancer, без storage-провайдера. Это осознанный выбор разработчиков - пусть пользователь сам установит то, что ему нужно.
MicroK8s ставится через snap и включает аддоны командами:
sudo snap install microk8s --classic
sudo microk8s enable dns ingress metallb hostpath-storage
Элегантная система аддонов включает MetalLB, Prometheus, Grafana, Cert-Manager, Knative и ещё десятки компонентов одной командой. Цена удобства - привязка к snap со всеми его особенностями, от автоматических обновлений до работы с confinement.
Kubeadm показывает, из чего состоит Kubernetes на самом деле. Установка включает целый список шагов:
- Установка контейнерного рантайма (containerd или CRI-O) с настройкой cgroup-драйвера
- Настройка системы (загрузка модулей br_netfilter, overlay, включение форвардинга)
- Добавление репозитория Kubernetes и установка kubeadm, kubelet, kubectl нужной версии
- Инициализация control-plane командой kubeadm init с параметрами сети и сервисного CIDR
- Установка CNI (Calico, Cilium, Flannel) через отдельный манифест
- Присоединение воркеров командой kubeadm join с токеном
- Развёртывание ingress-контроллера, MetalLB или любого другого LoadBalancer
- Настройка storage-класса с внешним провижнером
Каждый пункт документирован, но суммарно эта дорога длиннее, чем установка любого из лёгких вариантов. Вознаграждение - глубокое понимание, что происходит в кластере, и полная свобода выбора компонентов.
Высокая доступность и что значит "настоящий" production
Селф-хостинг редко требует пяти девяток, но одна упавшая мастер-нода в домашнем кластере всё равно означает остановку всех приложений, пока админ не починит её вручную. HA превращается из роскоши в полезную страховку.
K3s поддерживает HA через embedded etcd (начиная с версии 1.19) или внешнее хранилище вроде PostgreSQL, MySQL, etcd. Минимум три мастер-ноды, одна команда при инициализации, и кворум работает. Простота, которая радует. Внешняя БД полезна, если хочется разделить control-plane и data-plane.
K0s реализует HA через несколько control-plane нод с общим etcd. Конфиг k0sctl.yaml описывает все роли, kine-бэкенды или внешний etcd подключаются параметрами. Документация чистая, но пользователь должен сам понять, что ему нужно.
MicroK8s в HA-режиме добавляет минимум три мастера и использует dqlite - распределённую версию SQLite. Включение проще некуда:
microk8s add-node
На новой ноде выполняется выведенная команда join, и через несколько секунд кворум готов.
Kubeadm предлагает две схемы HA, stacked control-plane (когда etcd живёт на тех же нодах, что и API-сервер) или external etcd (когда кластер etcd вынесен отдельно). Ручная работа серьёзная: настройка load-balancer перед API-серверами (keepalived + haproxy, kube-vip, внешний железный балансировщик), корректная инициализация первого мастера с правильным --control-plane-endpoint, аккуратное присоединение остальных. Зато получается классический ванильный Kubernetes без сюрпризов.
Обновления, жизненный цикл и боли длительной эксплуатации
Первый запуск кластера - приятная часть. Дальше начинается сопровождение: обновления, ротация сертификатов, замена компонентов, миграция с версии на версию. Здесь дистрибутивы снова расходятся.
K3s обновляется либо повторным запуском install-скрипта с новой версией, либо через system-upgrade-controller, который умеет катить апдейты декларативно через кастомные ресурсы Plan. Красиво, предсказуемо, с rolling-обновлением нод по очереди.
K0s обновляется через k0sctl apply с новой версией в конфиге. Утилита сама дренирует ноды по очереди, обновляет бинарник, возвращает их в строй. Работает как часы, если сетевая связность между управляющей машиной и нодами не обрывается.
MicroK8s тянет обновления через snap автоматически, что одновременно плюс и минус. Минус - в том, что процесс может начаться не в самый удобный момент, если не ограничить snap refresh через конфигурационные параметры. Плюс - в том, что можно забыть про ручные апдейты вообще.
Kubeadm обновляется поэтапно через kubeadm upgrade plan и kubeadm upgrade apply на каждой ноде по очереди. Сертификаты продлеваются через kubeadm certs renew, ротация компонентов требует внимания, но документация подробная. Это ручной процесс, зато предсказуемый и хорошо изученный.
Когда какой дистрибутив действительно оправдан
Короткий дайджест, без расплывчатых формулировок вроде "зависит от задачи".
K3s хорош в трёх сценариях. Домашняя лаборатория на 1 - 5 нод, где хочется всё из коробки и быстрый старт. Edge-развёртывания на слабом железе, где Traefik и ServiceLB просто удобны. Небольшие продакшен-кластеры для конкретных приложений, где не нужны тонкие настройки. Минус - мнение разработчиков встроено в конфиг, и если хочется nginx-ingress вместо Traefik, придётся сначала отключать дефолты.
K0s становится правильным выбором, когда нужна чистота ванильного Kubernetes с минимальным футпринтом, но без ручной возни kubeadm. Подходит для edge-устройств с жёсткими требованиями к памяти, для CI-пайплайнов, для тех, кто ценит отсутствие "мнений" и единственный бинарник.
MicroK8s раскрывается на Ubuntu-машинах, где snap-экосистема ощущается родной. Встроенные аддоны превращают настройку мониторинга, ingress и сертификатов в тривиальную задачу. Прекрасный выбор для разработчика, которому нужен локальный кластер на ноутбуке, и для команд Ubuntu-админов, которые хотят минимум возни.
Kubeadm имеет смысл выбирать в двух случаях. Первый - обучение и подготовка к сертификации, потому что именно kubeadm стоит за большинством курсов и учебных сценариев. Второй - продакшен с требованиями к абсолютному контролю компонентов, когда организация строит собственный дистрибутив или хочет избежать любых вендорских особенностей. Для обычного селф-хостинга kubeadm обычно избыточен.
Несколько мыслей, которые редко озвучиваются в сравнениях
Большинство сравнений фокусируются на установке, но молчат про то, что происходит через год эксплуатации. Опыт показывает простую закономерность: дистрибутив, который легче всего поставить, не всегда легче всего поддерживать. K3s ставится за секунду, но смена ingress с Traefik на nginx превращается в квест. MicroK8s щедро включает аддоны, но их версии привязаны к жизненному циклу snap-канала. K0s даёт свободу, но ждёт, что пользователь знает, что хочет. Kubeadm честно говорит "вот конструктор, дальше сам".
Вторая мысль касается селф-хостинга как жанра. Домашний кластер - это не мини-копия корпоративной инфраструктуры, это экосистема с собственными приоритетами: низкое энергопотребление, простое резервное копирование, терпимость к перезагрузкам, дружелюбность к одному администратору. Выбирая дистрибутив, стоит честно ответить на вопрос, что важнее - быстрая настройка один раз или понимание, что происходит внутри каждый день.
Третья мысль о будущем. Экосистема Kubernetes движется в сторону большей модульности, Gateway API постепенно вытесняет Ingress, Cilium забирает долю у классических CNI, eBPF-инструменты меняют подходы к observability. Лёгкие дистрибутивы реагируют на эти изменения с разной скоростью. K3s и MicroK8s обычно первыми добавляют свежие возможности через аддоны, K0s держит более консервативную позицию, kubeadm получает поддержку новых фич одновременно с апстримом.
Идеального дистрибутива не существует, и это нормально. Для домашнего сервера с парой приложений подойдёт K3s или MicroK8s, для edge-девайсов с нехваткой памяти стоит присмотреться к K0s, для обучения и чистого опыта работы с Kubernetes есть kubeadm. Правильный вопрос - не "какой лучший", а "какой лучше для моих конкретных задач". Ответ становится очевидным, как только администратор начинает перечислять свои реальные требования: сколько нод, какое железо, какие приложения, кто будет сопровождать. Всё остальное уже детали, которые каждый из четырёх инструментов умеет решить, просто разными способами.
Канал сайта в Telegram
Канал сайта на YouTube