У нас есть Managed Kubernetes: рассказываем с опозданием на пару месяцев

В облаке Beget появился Managed Kubernetes: управляющий контур обслуживаем мы, на вашей стороне остаются worker-ноды и всё, что на них работает. Сервис сейчас в публичной бете.

Строго говоря, бету мы открыли пару месяцев назад — и до Хабра руки дошли только сейчас. Зато есть приятный побочный эффект: за это время сервис успел обрасти тем, о чём просили первые пользователи, так что рассказываем сразу про актуальную версию, а не про день релиза.

Кто за что отвечает

При самостоятельной установке Kubernetes на вас ложится всё: развернуть control plane, настроить сеть, обновлять компоненты, следить за состоянием кластера и поднимать его после сбоев. В managed-варианте эта часть уходит платформе. Мы разворачиваем и поддерживаем управляющий контур — master-ноды, etcd, API-сервер, настраиваем сеть кластера и маршрутизацию трафика, выполняем обновления в выбранный вами момент и из коробки показываем графики нагрузки на master-ноды и worker-группы.

На вашей стороне остаются worker-ноды и всё, что на них работает. Из панели при этом настраивается:

• Конфигурация управляющего контура — 1 master-нода для разработки и тестов или 3 в отказоустойчивой конфигурации для production.
• Worker-группы — конфигурация нод, количество, метки и ограничения. Группы удобно делить по типу нагрузки и масштабировать независимо.
• Балансировщики нагрузки — external и internal, создаются стандартными манифестами Kubernetes. Алгоритмы round_robin и least_connections , пропускная способность 1 Гбит/с в каждую сторону. На время беты бесплатны — тарифицировать начнём после её завершения.
• Аддоны — мониторинг, сертификаты, сетевые плагины и другие компоненты ставятся в несколько кликов.

Подключение — стандартное: скачиваете kubeconfig из панели и работаете через консольную утилиту kubectl . Кластер живёт внутри проекта: изолированная сеть и контроль доступа на уровне проекта.

Сколько стоит

Тарификация посуточная и складывается из двух частей: управляющий контур и ресурсы worker-нод. На время публичной беты на инфраструктуру действуют сниженные промоцены.

Worker-ноды — по фактической конфигурации:

Каждая worker-нода получает публичный IP — 150 ₽/мес. Это обязательная часть конфигурации, отказаться от неё нельзя, так что закладывайте её в расчёт на каждую ноду.

Для примера: dev-кластер из одной ноды 2 vCPU / 4 ГБ RAM / 40 ГБ NVMe обойдётся в 120 + 490 + 280 + 150 = 1 040 ₽/мес. , плюс рубль за управляющий контур.

Что фиксируется при создании

Важный практический совет: берите CIDR с запасом . Если планируете рост кластера, лучше сразу /16, а не /24.

Почему так: регион размещения и сетевые диапазоны — адреса сервисов и подов, маску подсети узлов — через панель изменить нельзя. Расширить их потом можно только через обращение в поддержку.

Stateful-нагрузки: пока осторожно

Диски нод не являются внешними. При пересоздании ноды данные на её диске удаляются безвозвратно. Поэтому строить на текущей версии сервиса хранилища данных мы не рекомендуем — под базы лучше взять отдельные облачные MySQL/PostgreSQL , под объекты S3-хранилище .

Ограничение временное: сетевые диски уже в работе и выйдут в ближайшее время — после этого persistent-нагрузки в кластере станут полноценным сценарием.

Как начать

1. В панели управления создайте кластер: имя, регион, конфигурация control plane, версия Kubernetes и релизный канал, сетевые диапазоны, worker-группы.
2. Скачайте kubeconfig.
3. kubectl get nodes — и дальше всё как обычно.

Документация

Руководство проведёт от создания кластера до настройки балансировщиков:

1. Kubernetes (K8s) — обзор сервиса
2. Основы Kubernetes — кластер, ноды, поды, сервисы
3. Создание и настройка кластера
4. Подключение к кластеру и работа с kubectl
5. Управление кластером
6. Сеть и балансировщик нагрузки
7. Лимиты, квоты и ограничения

Что изменилось за время беты

Всё перечисленное ниже выросло из вопросов и просьб первых пользователей.

Отказоустойчивость переключается в панели

Конфигурация управляющего контура больше не фиксируется при создании: переключение с 1 master-ноды на 3 и обратно доступно из панели управления. Можно начать с базового контура на тестах, включить отказоустойчивость, когда проект выходит в production, и выключить обратно, если кластер снова стал тестовым.

Метки с любым префиксом

Раньше метки (labels) задавались только с префиксом node-role . Теперь доступен любой префикс, кроме внесённых в наш блэклист. Подробности — в разделе про worker-группы .

Релизные каналы

Появился выбор стратегии автоматического обновления версии кластера:

• Стабильный — проверенная версия, не новее чем на 2 минорных версии от последней. Ниже риск сбоев после обновления.
• Сбалансированный — версия не старше 1 от последней минорной. Свежее «Стабильного», но с меньшим риском, чем «Актуальный».
• Актуальный — самая последняя доступная версия Kubernetes. Новые возможности появляются раньше, но версия менее обкатана.

Окна технического обслуживания

Теперь вы сами решаете, когда мы можем проводить работы с кластером: в любое время или в заданном окне.

Ручное обновление версии

Обновить кластер с одной версии на другую можно самостоятельно, не дожидаясь автоматики. Из свежего в списке доступных версий — Kubernetes 1.36.

Два новых аддона

Kyverno — управление политиками. Позволяет описывать политики безопасности и соответствия требованиям как обычные декларативные ресурсы Kubernetes: отдельный язык политик учить не нужно.

Envoy Gateway — контроллер Gateway API на базе Envoy Proxy. Через него публикуют HTTP, HTTPS, gRPC, TCP и UDP-сервисы, настраивают маршрутизацию по доменам и путям, управляют TLS-сертификатами и применяют политики трафика: rate limiting, retries, security. Всё стандартными ресурсами Kubernetes, без ручной конфигурации Envoy.

Фактически это современная замена ingress-контроллера: Gateway API пришёл на смену классическому Ingress и даёт более гибкую модель с разделением зон ответственности — кто настраивает саму точку входа в кластер, а кто описывает маршруты для своего сервиса.

Ждём обратную связь

Бета продолжается, и режим работы прежний: вы рассказываете, чего не хватает, — мы изучаем, оцениваем и докручиваем.

Так что создавайте кластер, разворачивайте на нём свои проекты, тестируйте под нагрузкой — и делитесь впечатлениями. Каких фич не хватает в managed Kubernetes? Что показалось неудобным? Где документация не отвечает на вопрос?

Пишите в комментариях или заходите в наш чат в Telegram — там можно обсудить сервис с коллегами по цеху и с сотрудниками Beget напрямую.