VPS для Kubernetes и k3s

Kubernetes на арендованных виртуальных серверах собирают по двум причинам: управляемый кластер у облачного провайдера обходится дороже, а для учёбы, домашней лаборатории или небольшого продакшена хочется полного контроля над версиями и настройками. Но кластер — это не один сервер, а несколько узлов с разными ролями, и экономия на одном из них обычно ломает весь кластер. В таблице выше собраны тарифы на KVM от 2 ядер и 4 ГБ памяти у хостеров с API, чтобы узлы можно было создавать скриптом или из Terraform.

k3s или kubeadm

k3s — облегчённый дистрибутив одним бинарным файлом. По документации серверному узлу хватает 2 ядер и 2 ГБ памяти, агенту — одного ядра и 512 МБ. Вместо etcd по умолчанию используется SQLite, а для отказоустойчивости можно включить встроенный etcd на трёх серверных узлах. Сеть Flannel, ingress Traefik и локальное хранилище ставятся сразу. Это лучший выбор для одного–трёх VPS, тестовых окружений и небольших проектов.

kubeadm разворачивает «ванильный» Kubernetes: отдельные компоненты control plane, etcd, сетевой плагин на ваш выбор (Calico, Cilium). Минимальные требования те же 2 ядра и 2 ГБ на машину, но на практике control plane с etcd спокойно работает от 4 ГБ. kubeadm берут, когда нужна полная совместимость с продакшеном, готовятся к сертификации CKA или хотят разобраться, как устроен кластер изнутри. Обновлять его дольше: версии поднимаются по одной минорной за раз.

Сколько узлов и каких

• Один узел — k3s на VPS с 4 ГБ памяти, где control plane и нагрузка живут вместе. Подходит для пет-проектов и стендов.
• Один мастер и 2–3 воркера — классическая схема для обучения и небольших сервисов. Мастеру 2–4 ГБ, воркерам — по реальной нагрузке, обычно 4–8 ГБ.
• Три control-plane узла — минимум для кворума etcd: кластер переживает потерю одного узла. Два мастера хуже одного, при падении любого из них кворума нет.

Считайте память с запасом: kubelet, container runtime, CNI, CoreDNS и агенты мониторинга съедают 0,5–1 ГБ на каждом узле ещё до ваших подов. Kubernetes вытесняет поды при нехватке памяти, поэтому задавайте requests и limits. kubeadm по умолчанию требует отключить swap.

etcd и диск

etcd записывает каждое изменение состояния кластера с синхронным сбросом на диск, и медленный fsync — частая причина «падающего» API и перевыборов лидера. Для control plane берите VPS на NVMe, а не HDD и не дешёвые тарифы с жёстким лимитом IOPS. Проверить диск можно утилитой fio с fdatasync: задержка в несколько миллисекунд — норма, десятки — повод сменить тариф. Делайте снапшоты etcd регулярно и храните их вне кластера.

Виртуализация, сеть, тома и балансировка

Kubernetes нужны собственное ядро, модули overlay и br_netfilter, cgroups и iptables или eBPF. На контейнерной виртуализации OpenVZ и LXC это почти всегда не работает, поэтому нужен VPS на KVM — те же требования, что и у Docker, только строже. Вложенная виртуализация (флаг vmx или svm в /proc/cpuinfo) понадобится, только если вы запускаете виртуальные машины внутри кластера через KubeVirt или Kata Containers; для обычных контейнеров она не нужна, и включают её не все хостеры.

Узлы лучше держать в одном дата-центре: между ними ходит трафик overlay-сети и etcd, а задержка в десятки миллисекунд заметно замедляет кластер. Если хостер даёт приватную сеть между VPS, пустите внутрикластерный трафик по ней. Наружу открывайте только API на 6443/TCP (лучше по белому списку IP) и порты ingress; порт VXLAN 8472/UDP и kubelet 10250 из интернета должны быть закрыты.

Управляемые кластеры сами выдают тома и внешние балансировщики, а на голых VPS этих сервисов нет, и сервис типа LoadBalancer навсегда останется в статусе Pending. Для входящего трафика обычно хватает ingress-контроллера на портах 80 и 443 одного или нескольких узлов; k3s для этого включает встроенный ServiceLB, а в kubeadm-кластере ставят MetalLB, если у хостера можно получить дополнительные IP. С томами проще всего начать с local-path — данные лежат на диске конкретного узла и пропадают вместе с ним. Если поду нужно переезжать между узлами вместе с данными, ставят распределённое хранилище вроде Longhorn, которое реплицирует тома по узлам; закладывайте под него отдельное место на диске каждого воркера и ещё 0,5–1 ГБ памяти.

Свой кластер или управляемый

Управляемый Kubernetes снимает с вас control plane, обновления и etcd, а платите вы в основном за воркеры и балансировщики. Свой кластер на VPS дешевле и гибче, но бэкапы etcd, обновления, сертификаты и мониторинг становятся вашей работой. Разумный компромисс для старта — k3s на нескольких VPS с почасовой оплатой: узлы можно пересоздавать, пробовать разные схемы и удалять лишнее, не переплачивая за месяц.