Что такое k3s и чем он отличается от обычного Kubernetes

Что такое k3s: короткий ответ

k3s представляет собой сертифицированный CNCF (Cloud Native Computing Foundation) дистрибутив Kubernetes, который команда Rancher, сейчас часть SUSE, упаковала в один исполняемый файл. Внутри работают те же компоненты, что и в обычном кластере: API-сервер, планировщик, контроллеры и kubelet. Поэтому kubectl, Helm и ваши YAML-манифесты работают без изменений. Разница в упаковке и в наборе по умолчанию. На одном узле вместо etcd используется SQLite. Из сборки убраны устаревшие функции и встроенные драйверы облаков и дисков. Сеть, DNS, ingress и балансировщик уже лежат внутри и поднимаются одной командой.

Название расшифровывается просто. Kubernetes стилизуют как k8s: десять букв, восемь из них скрыты цифрой. Авторы хотели дистрибутив «вдвое меньше по памяти», то есть слово из пяти букв, и получили k3s. Никакого отдельного проекта «k3s-кубернетес» не существует: это Kubernetes, собранный иначе.

Что лежит внутри одного бинарника

Документация docs.k3s.io описывает k3s так: «Lightweight Kubernetes. Easy to install, half the memory, all in a binary of less than 100 MB». По состоянию на сентябрь 2026 года стабильный канал (stable) отдаёт версию v1.36.4+k3s1, канал latest уже v1.37.0+k3s1. Номер до знака + это версия upstream Kubernetes, суффикс k3s1 это номер сборки дистрибутива. По нему проще всего понять, насколько k3s отстаёт от основного проекта: обычно на один минорный релиз или не отстаёт вовсе.

В файл упакованы:

• containerd и runc в роли среды выполнения контейнеров. Docker не нужен и по умолчанию не ставится.
• Flannel в роли CNI (container network interface), то есть сети между подами. По умолчанию это VXLAN на UDP-порту 8472.
• CoreDNS для DNS внутри кластера.
• Traefik в роли ingress-контроллера. Через ServiceLB он получает порты 80 и 443 на каждом узле.
• ServiceLB (ранее Klipper-lb), который делает Service типа LoadBalancer рабочим на голом VPS без облачного балансировщика.
• local-path-provisioner, который выдаёт PersistentVolume из каталога на локальном диске узла.
• Kube-router в роли контроллера сетевых политик, Metrics Server, Helm-controller и утилиты вроде iptables и socat.

Traefik, ServiceLB и остальные надстройки отключаются флагом --disable, а Flannel заменяется через --flannel-backend=none, если вы хотите поставить Calico. Именно так поступают при укреплении одноузлового кластера k3s, когда лишний открытый порт хуже, чем лишний флаг.

Что k3s убирает из upstream Kubernetes и что оставляет

Убрано две группы вещей. Первая: устаревшие, альфа- и не включённые по умолчанию функции. Если ваш манифест опирается на feature gate, который в upstream ещё не дошёл до беты, в k3s его может не оказаться. Вторая: встроенные (in-tree) драйверы облачных провайдеров и хранилищ. В обычном Kubernetes они и так объявлены устаревшими в пользу CSI (container storage interface) и внешних cloud-controller-manager, k3s просто не тащит их код в бинарник. На VPS вы их и не использовали бы: там нет ни AWS EBS, ни GCE PD, к которым эти драйверы подключаются.

Оставлено всё, что видит клиент. API (application programming interface, интерфейс, через который kubectl разговаривает с кластером) совпадает с upstream той же версии: те же группы ресурсов, те же Deployment, StatefulSet, Ingress и ConfigMap, те же CRD (custom resource definitions). Helm-чарт, написанный под «настоящий» Kubernetes, ставится в k3s тем же helm install. Оператор, который вы нашли на OperatorHub, применяется тем же kubectl apply. GitOps-инструменты вроде Argo CD и Flux не отличают k3s от кластера в облаке. В этом и смысл сертификации CNCF: проект прошёл тот же набор конформанс-тестов, что и managed-кластеры у крупных провайдеров.

Одно отличие заметно на уровне сети. Агент k3s сам поднимает websocket-туннель к серверу, и сервер обращается к kubelet через этот туннель. Порт 10250 при этом всё равно слушается для метрик, и документация просит открыть его между узлами. Если у вас всплывают ошибки kubelet на порту 10250, первое, что стоит проверить: firewall между узлами.

Хранилище: SQLite по умолчанию, etcd по желанию

Обычный Kubernetes хранит состояние кластера в etcd, распределённой базе, которая хочет минимум три узла и быстрый диск. k3s на одном сервере вместо этого пишет в файл SQLite через прослойку Kine, которая переводит запросы API-сервера в SQL. Документация прямо говорит: «SQLite cannot be used on clusters with multiple servers». То есть один сервер и сколько угодно агентов работают на SQLite, а второй сервер уже требует другого хранилища.

Варианта два. Встроенный etcd включается флагом --cluster-init при первом запуске, и тогда серверов можно сделать три или пять для отказоустойчивости. Внешняя база (PostgreSQL, MySQL, MariaDB или внешний etcd) подключается через --datastore-endpoint. На одном VPS ни то, ни другое не нужно: SQLite не требует отдельного процесса и не ест память под кворум, которого у вас всё равно нет.

Требования к серверу по документации

Документация k3s на странице требований называет такие минимумы: для серверного узла 2 ядра и 2 ГБ памяти, для агента 1 ядро и 512 МБ. Это минимумы, при которых сам k3s стартует. Запас под вашу нагрузку считайте отдельно. Цифры «сколько k3s занимает в простое» здесь намеренно не приводятся: они зависят от версии, от включённых компонентов и от того, что вы задеплоили. Если нужно число, измерьте его на своём сервере командой free -m до и после sudo systemctl start k3s.

Поддерживаемые системы, по той же странице: Ubuntu и Debian, RHEL с CentOS и Fedora, SUSE с openSUSE, Raspberry Pi. Единственное жёсткое требование к ОС: современное ядро и смонтированные cgroups. Перед покупкой тарифа под контейнеры полезно сначала подобрать размер VPS под типовые задачи, а потом уже решать, на чём эти задачи запускать.

k3s против kubeadm, microk8s, minikube и kind

Четыре инструмента, с которыми k3s путают чаще всего, и чем каждый из них отличается.

kubeadm. Официальный инструмент upstream для сборки кластера из отдельных пакетов: kubeadm init, потом ставите CNI сами, ingress сами, балансировщик и класс хранилища тоже сами, а etcd работает как отдельный процесс. Результат ближе всего к тому, что вы получите у облачного провайдера, и лучше всего подходит для изучения устройства Kubernetes. Цена: больше памяти и больше ручных шагов, каждый из которых можно выполнить неправильно. На VPS с 4 ГБ kubeadm работает, но тесно.

microk8s. Дистрибутив Canonical, поставляется как snap. По идее очень близок к k3s: один пакет, компоненты включаются командой microk8s enable dns ingress. Главные различия: зависимость от snapd, который вне Ubuntu приходится ставить отдельно, а на Alpine его нет вовсе, и dqlite вместо SQLite и etcd. На Ubuntu это рабочая альтернатива. На любой другой системе k3s ставится проще.

minikube и kind. Оба созданы для локальной разработки на ноутбуке. minikube поднимает кластер внутри виртуальной машины или Docker-контейнера. kind (Kubernetes in Docker) запускает узлы как Docker-контейнеры и рассчитан на CI и тесты. Ни тот, ни другой не предполагают, что кластер переживёт перезагрузку хоста и будет обслуживать реальных пользователей. На VPS их ставят по ошибке, когда ищут «маленький Kubernetes» и открывают первую ссылку в поиске.

k3s. Один бинарник, systemd-сервис, который переживает перезагрузку, SQLite вместо etcd, набор компонентов уже внутри. Авторы делали его для edge-устройств, для CI, для Raspberry Pi и для маленьких серверов. Одиночный VPS попадает ровно в эту нишу. Второй узел добавляется одной строкой с токеном, поэтому дорога к нескольким узлам не требует переустановки.

Docker Compose или k3s на одном VPS: как решить

Вопрос, который стоит за поиском «k3s это», почти всегда звучит иначе: «нужен ли мне Kubernetes вообще». Честный ответ для одного VPS на 2 или 4 ГБ, где живут несколько сервисов: не нужен. Docker Compose поднимает те же контейнеры одним файлом и не держит в памяти API-сервер с контроллерами. Ошибки в нём читаются из одного docker compose logs. Подробный разбор с примерами есть в сравнении Docker Compose против Kubernetes.

k3s оправдывает себя, когда вам нужен сам API Kubernetes. Признаки, что это ваш случай:

• Приложение, которое вы хотите поставить, распространяется как Helm-чарт или оператор, а Compose-файла у него нет.
• Вы хотите GitOps: репозиторий с манифестами, из которого Argo CD или Flux сами применяют изменения.
• Вам нужны CronJob, HorizontalPodAutoscaler или сетевые политики, которых в Compose нет.
• Вы планируете второй узел в обозримом будущем и не хотите переезжать с Compose на Kubernetes посреди работы.

Если ни один пункт не про вас, ставьте Compose и не тратьте память на управляющий слой. Если подходят хотя бы два, k3s будет самым дешёвым способом получить полный API на одной машине, и пошаговая инструкция, как установить k3s на один VPS, проведёт через установку, kubeconfig и первый деплой.

Порт 6443 и другие порты, которые нельзя открывать наружу

API-сервер k3s слушает TCP 6443 на всех интерфейсах. Через этот порт kubectl управляет кластером, и через него же агенты присоединяются к серверу по токену. Наружу его открывать нельзя. Сам по себе он требует сертификат или токен, но любая ошибка в RBAC (role-based access control, система прав в Kubernetes) или утёкший kubeconfig превращают открытый 6443 в полный доступ к серверу. Управляйте кластером через SSH-туннель или через VPN, а в firewall оставьте 6443 закрытым для всего, кроме адресов ваших узлов.

Порты, которые перечисляет документация: 6443/tcp для API, 10250/tcp для kubelet, 8472/udp для Flannel VXLAN, 2379 и 2380/tcp только при встроенном etcd, 51820 и 51821/udp только при Flannel в режиме WireGuard. Про VXLAN документация пишет отдельно: «The VXLAN port on nodes should not be exposed to the world as it opens up your cluster network to be accessed by anyone». На одном узле ни один из этих портов не нужен никому, кроме самого узла. Проверьте, что реально слушается:

sudo ss -ltnp | grep -E ':(6443|10250)\b'

Здоровый вывод показывает процесс k3s-server на *:6443 и на *:10250. Дальше ваша задача сделать так, чтобы до них не доходили пакеты извне. Это уже область укрепления одноузлового кластера k3s: firewall, отключение лишних компонентов, ограничение прав в kubeconfig и ротация токена.

Как выглядит установка, чтобы было с чем сравнивать

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

curl -sfL https://get.k3s.io | sh -
sudo k3s kubectl get nodes

Скрипт скачивает бинарник, создаёт systemd-сервис k3s и включает его, так что после перезагрузки кластер поднимается сам. Через минуту get nodes должен показать один узел со статусом Ready. Если статус NotReady держится дольше пары минут, смотрите sudo journalctl -u k3s -n 100: k3s пишет туда, какой компонент не стартовал и с какой ошибкой.

Вместе с бинарником ставятся kubectl, crictl, ctr и два скрипта: k3s-killall.sh останавливает всё, k3s-uninstall.sh удаляет кластер вместе с данными. Kubeconfig лежит в /etc/rancher/k3s/k3s.yaml, токен для присоединения агентов в /var/lib/rancher/k3s/server/node-token. Агент присоединяется так:

curl -sfL https://get.k3s.io | K3S_URL=https://<адрес-сервера>:6443 K3S_TOKEN=<токен> sh -

Обратите внимание на 6443 в K3S_URL: по этой причине порт должен быть доступен второму узлу, но не всему интернету.

FAQ

k3s считается полноценным Kubernetes или урезанной версией?

Полноценным. k3s проходит конформанс-тесты CNCF для той версии Kubernetes, которую содержит, и совпадает с upstream по API. Урезана только сборка: удалены альфа- и устаревшие функции, встроенные драйверы облаков и хранилищ, а etcd на одном узле заменён на SQLite. Всё, что видит kubectl, ведёт себя так же, как в кластере у облачного провайдера.

Будут ли работать Helm-чарты и обычные манифесты в k3s?

Да, без правок. Helm обращается к тому же API, что и kubectl, поэтому helm install ставит чарт в k3s так же, как в любой другой кластер той же версии. Единственное место, где чарт может рассчитывать на то, чего в k3s нет по умолчанию: класс хранилища и ingress-класс. В k3s они называются local-path и traefik, и обычно достаточно указать их в values.yaml.

Сколько памяти нужно серверу под k3s?

Документация называет минимум 2 ядра и 2 ГБ для серверного узла и 1 ядро с 512 МБ для агента. Это порог запуска. Под нагрузку считайте отдельно. Реальное потребление зависит от версии и от того, что вы задеплоили, поэтому измеряйте его на своём сервере вместо того, чтобы верить чужим цифрам.

Когда на VPS лучше выбрать Docker Compose вместо k3s?

Когда у вас один сервер на 2 или 4 ГБ, несколько сервисов и нет нужды в API Kubernetes. Compose не держит в памяти управляющий слой, и его ошибки читаются из одного лога. k3s стоит выбирать, если приложение поставляется только как Helm-чарт или оператор, или если второй узел появится в ближайшие месяцы.

Можно ли позже добавить узлы в кластер k3s, который стоит на одном VPS?

Агенты добавляются в любой момент одной командой с K3S_URL и K3S_TOKEN, и SQLite для этого менять не нужно. Второй сервер (в отличие от агента) требует встроенного etcd: его включают флагом --cluster-init при первом запуске, а переход с SQLite на etcd позже потребует остановки кластера и миграции данных.