Managed Kubernetes против своего k3s: цена удобства в месяц

MAATRIX

Когда команда выбирает между managed Kubernetes и своим кластером на VPS, разговор обычно быстро скатывается к сравнению тарифов на вычислительные узлы — а это неверная точка сравнения. Узлы стоят примерно одинаково что там, что там, потому что это просто CPU, RAM и диск. Разница в цене — это control plane: в managed-варианте за него платят отдельно и каждый месяц, в self-hosted k3s его поднимаете и чините сами. Разберём честно, из чего складывается эта доплата, что она реально покупает и когда её платить бессмысленно.

Что вы на самом деле покупаете в managed Kubernetes

Control plane кластера — это API-сервер, etcd (или его аналог для хранения состояния), scheduler и controller-manager. Именно эти компоненты решают, куда поставить под, следят за состоянием кластера и отвечают на запросы kubectl. В managed-предложении провайдер берёт на себя:

• развёртывание control plane в отказоустойчивой конфигурации (обычно три реплики etcd в разных зонах доступности);
• резервное копирование etcd и восстановление при сбое;
• обновление версии Kubernetes на control plane без вашего участия;
• ротацию TLS-сертификатов между компонентами control plane;
• мониторинг здоровья API-сервера и автоматический рестарт при деградации.

Вы получаете доступ к API кластера — kubectl get nodes просто работает — но никогда не видите и не администрируете сами control-plane-узлы. Это принципиально другая модель ответственности по сравнению с обычным VPS, где вы администрируете всё сверху вниз.

Здесь и рождается доплата: провайдер эксплуатирует для вас три (иногда больше) отказоустойчивых узла control plane, но не выставляет их вам как отдельные VPS — вы платите за услугу «работающий API кластера», а не за железо под ней. Это и есть цена удобства, вынесенная в отдельную строку счёта поверх стоимости worker-узлов, которые вы всё равно оплачиваете как обычные вычислительные мощности.

Из чего складывается разница в счёте

Если сравнивать управляемый Kubernetes и самостоятельный k3s построчно, разница обычно набирается из нескольких статей, а не из одной:

Важный нюанс: сама по себе доплата за control plane у крупных managed-провайдеров обычно не главная статья расходов в абсолютных цифрах — гораздо больше денег уходит на managed-балансировщики, managed-диски с повышенными IOPS и трафик. Но именно доплата за control plane — это плата принципиально «за удобство», а не за ресурсы: вы платите не за вычисления, а за то, что кто-то другой не спит по ночам, если etcd теряет кворум.

Что реально закрывает эта доплата

Прежде чем экономить на control plane, стоит понимать, что именно вы берёте на себя, отказываясь от managed-варианта:

Отказоустойчивость etcd. etcd — это распределённая база данных с консенсусом по Raft. Для отказоустойчивости нужно нечётное число узлов (минимум три), размещённых так, чтобы отказ одной зоны не убил кворум. Если кворум потерян, кластер перестаёт принимать изменения — поды, которые уже запущены, продолжат работать, но задеплоить что-то новое или обработать сбой ноды вы не сможете, пока не восстановите etcd.

Своевременные обновления. Kubernetes выпускает минорные версии примерно раз в четыре месяца, и каждая версия поддерживается ограниченное время. Если control plane отстаёт на несколько минорных версий, апгрейд превращается в отдельный проект: нужно проходить версии последовательно, читать changelog на deprecated API, тестировать на стейджинге. Managed-провайдер обычно даёт хотя бы предупреждение о скором end-of-life версии и делает апгрейд управляемым процессом с одной кнопкой.

Ротация сертификатов. Внутри control plane компоненты общаются друг с другом по TLS с сертификатами, у которых есть срок действия (типично год). Просроченный сертификат — классическая причина внезапной недоступности кластера у тех, кто настроил control plane один раз и забыл о нём. В managed-варианте это не ваша забота.

SLA на доступность API. Большинство managed-провайдеров дают формальный SLA на доступность API-сервера кластера (обычно в терминах digits after the decimal point «девяток» доступности в месяц) с компенсацией при нарушении. Это не защищает от простоя ваших приложений, но защищает от ситуации «мы не можем задеплоить фикс, потому что API кластера лежит».

Если у вас в команде нет человека, который может внятно объяснить разницу между etcdctl snapshot save и etcdctl member list, эта доплата, скорее всего, окупается — вы покупаете экспертизу, которой нет внутри команды, а не абстрактное удобство.

k3s на своих VPS: тот же API, другая модель ответственности

k3s — это open-source дистрибутив Kubernetes от Rancher (сейчас часть SUSE), собранный в один бинарник и урезанный по сравнению с ванильным Kubernetes: убраны cloud-provider-специфичные интеграции, устаревшие alpha-фичи, вместо etcd по умолчанию используется встроенный SQLite (для single-node) или тот же etcd в кластерном режиме. API остаётся полностью совместимым — тот же kubectl, те же манифесты, те же CRD.

Поднять single-node k3s — вопрос одной команды:

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

Через минуту у вас рабочий control plane и worker в одном процессе на одной VPS. Это отличный вариант для разработки, стейджинга или небольшого прод-проекта, где простой control plane на несколько минут раз в год — не катастрофа.

Для отказоустойчивого прод-кластера нужен HA-режим с embedded etcd — минимум три узла с ролью server:

# первый server-узел, инициализирует кластер
curl -sfL https://get.k3s.io | sh -s - server \
  --cluster-init \
  --tls-san=k8s-api.example.com

# второй и третий server-узлы присоединяются к первому
curl -sfL https://get.k3s.io | K3S_TOKEN=<токен-с-первого-узла> sh -s - server \
  --server https://<ip-первого-узла>:6443 \
  --tls-san=k8s-api.example.com

Дальше worker-узлы (роль agent) присоединяются отдельной командой с K3S_URL и токеном. С этого момента вы — тот самый «managed-провайдер» для своего кластера: именно вы отвечаете за то, что было в предыдущем разделе — кворум etcd, обновления, сертификаты, бэкапы.

Сколько стоит self-hosted control plane на самом деле

Прямых расходов на control plane в self-hosted варианте формально нет — вы платите только за три VPS под server-роль (их можно взять минимальной конфигурации, control plane для небольшого кластера не требователен к ресурсам: 2 vCPU и 4 ГБ RAM на узел обычно достаточно для кластеров до нескольких десятков нод). Но «бесплатно» здесь означает «время инженера вместо счёта провайдера», и это время стоит посчитать:

• Бэкапы etcd. Нужно настроить регулярный снапшот и хранение вне кластера:

# ручной снапшот через k3s (embedded etcd)
k3s etcd-snapshot save --name backup-$(date +%Y%m%d)

# список снапшотов
k3s etcd-snapshot ls

В проде это должно быть по расписанию (systemd timer или cron) с выгрузкой в отдельное S3-совместимое хранилище — и кто-то должен раз в квартал реально проверять, что восстановление из снапшота работает, а не просто верить, что файл лежит.

• Обновления версии. k3s можно обновлять вручную (повторный запуск install-скрипта с INSTALL_K3S_VERSION) или через system-upgrade-controller, который катит апгрейд по кластеру узел за узлом с учётом drain. Настройка контроллера обновлений — разовая работа на несколько часов, но она должна быть сделана заранее, а не в момент, когда версия становится unsupported.

• Мониторинг кворума и алерты. Нужно знать о потере кворума раньше, чем об этом узнают пользователи — то есть завести метрики etcd (etcd_server_has_leader, задержки консенсуса) в Prometheus/Grafana и алерты в Telegram или почту.

• Сетевой слой снаружи. Без managed-балансировщика внешний доступ к сервисам организуется через MetalLB (в режиме L2 или BGP) или через ingress-контроллер на NodePort за внешним reverse-proxy. Это несколько часов настройки один раз, а не постоянные расходы, но требует понимания сетевой топологии.

Совокупно на поддержание HA k3s-кластера в адекватном состоянии команда с опытом тратит от нескольких часов в месяц (плановые проверки, обновления patch-версий) до заметно больше в месяцы мажорных апгрейдов. Если это время оценить по ставке инженера и сравнить с доплатой за managed control plane — иногда self-hosted выходит дороже по факту, просто эти расходы не видны в одном счёте.

Кому доплата оправдана, а кому — нет

Доплата за managed Kubernetes оправдана, если:

• в команде нет отдельного человека, который регулярно администрирует Kubernetes control plane (не путать с написанием манифестов — это другой навык);
• простой control plane критичен для бизнеса и обходится дороже ежемесячной доплаты за пару часов disruption;
• кластер большой и разнородный (десятки узлов, много namespace, несколько команд) — тогда операционная нагрузка на control plane растёт нелинейно;
• нужна формальная compliance-история (аудит доступа, SLA как часть договора с провайдером).

Self-hosted k3s экономически и технически разумнее, если:

• проект небольшой или средний, кластер из нескольких узлов, нагрузка предсказуема;
• в команде уже есть опыт с Kubernetes — тогда администрирование control plane не абстрактный риск, а понятная рутинная задача;
• важен полный контроль над версией Kubernetes, конфигурацией API-сервера, admission-контроллерами — managed-провайдеры часто ограничивают эти настройки;
• инфраструктура и так строится на собственных VPS (например, из соображений локации данных или стоимости) — тогда добавить k3s поверх уже администрируемых серверов дешевле, чем переезжать на managed-платформу целиком.

Промежуточный вариант тоже существует: часть команд держит staging и небольшие внутренние сервисы на self-hosted k3s, а прод с высокими требованиями к доступности — на managed control plane. Это разумный компромисс, если инженерное время ограничено, но не хочется полностью отказываться от практики.

Если вы ещё не уверены, что вашему проекту вообще нужен Kubernetes в каком-либо виде, стоит сначала честно ответить на этот вопрос — среди частых заблуждений разбор того, нужен ли Kubernetes каждому проекту, и отдельно — когда переход с docker compose на Kubernetes действительно оправдан. Если ответ «да, k3s», дальше пригодится пошаговая установка k3s на Ubuntu 24.04 и расчёт того, сколько RAM реально нужно под k3s на разных ролях узлов.

Частые вопросы