k3s, Minikube или kind: какой лёгкий Kubernetes выбрать

Коротко

Все три дают рабочий Kubernetes API, но сделаны для разных задач:

• Minikube — локальный кластер для разработчиков с множеством драйверов и готовыми аддонами.
• kind (Kubernetes IN Docker) — кластеры, где узлы — это Docker-контейнеры; создаются и удаляются за считаные минуты, идеальны для CI.
• k3s — сертифицированный облегчённый дистрибутив Kubernetes в одном бинарнике; подходит для продакшена на небольших серверах, edge-устройствах и VPS.

Простое правило: ноутбук — Minikube или kind, CI — kind, VPS — k3s.

Сравнительная таблица

Локальная разработка

Minikube — самый дружелюбный вариант для ноутбука разработчика:

minikube start
minikube addons enable ingress
minikube service my-app

• Работает на Linux, macOS и Windows с драйверами Docker, Hyper-V, KVM или VirtualBox.
• Аддоны включают типовые компоненты одной командой.
• minikube tunnel даёт сервисам типа LoadBalancer доступный адрес.

kind легче, если Docker уже установлен и нужно несколько кластеров рядом. k3s нативно работает только на Linux; на macOS и Windows обычно используют k3d, который запускает k3s внутри Docker.

Тестирование в CI

kind создавался именно для этого. Типичный пайплайн:

kind create cluster --name ci
kind load docker-image my-app:test --name ci
kubectl apply -f k8s/
kubectl wait --for=condition=available deployment/my-app --timeout=120s
kind delete cluster --name ci

• kind load docker-image загружает локально собранный образ в кластер без registry.
• Версию Kubernetes можно зафиксировать через образ узла — это удобно для проверки обновлений.
• k3d — хорошая альтернатива, если прод работает на k3s и вы хотите, чтобы CI ему соответствовал.

Minikube тоже работает в CI, но обычно он тяжелее и стартует медленнее, чем kind.

Небольшой продакшен-кластер на VPS

Из трёх вариантов реалистичен только k3s:

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

• Одна команда ставит сервер с containerd, сетью Flannel, Traefik ingress и простым балансировщиком.
• Дополнительные серверы и агенты подключаются по токену.
• Один сервер по умолчанию использует встроенное хранилище SQLite; для высокой доступности запускают несколько серверов со встроенным etcd или внешней базой.
• Помните о базовых вещах: бэкапы хранилища, обновления ОС, файрвол, TLS-сертификаты и мониторинг — на вас.

Ограничения сети, о которых стоит знать

• Minikube: сервисы доступны с хоста через minikube service, minikube tunnel или port-forward; с других машин по умолчанию — нет.
• kind: порты узлов находятся внутри Docker. Чтобы открыть их на хосте, добавьте extraPortMappings в конфиг кластера или используйте kubectl port-forward. Для сервисов LoadBalancer нужен дополнительный компонент, например MetalLB или cloud-provider-kind.
• k3s: ServiceLB публикует сервисы LoadBalancer на IP узлов, что удобно на VPS, но облачного балансировщика перед ними нет. Продумайте, как трафик попадает на узлы и что будет при отказе одного из них.

Когда переходить на managed Kubernetes

Присмотритесь к EKS, GKE, AKS или managed Kubernetes у локального облачного провайдера, если:

• нужна высокая доступность control plane, а поддерживать её самим нет возможности;
• команда тратит заметное время на обновления, бэкапы etcd и отказы узлов;
• нужны облачные балансировщики, автомасштабирование узлов и интеграция с управляемыми базами;
• требования комплаенса предполагают аудируемую инфраструктуру.

Если один VPS с Docker Compose всё ещё справляется с нагрузкой, Kubernetes вам, возможно, пока не нужен.