Безумный кот

Всем привет 😇

Сегодня для нас (Beget) важный день — мы вошли в эпоху шифрования клиентских данных в Managed Kubernetes 💻

Сам релиз получился не самым большим по объёму:
• В компании появился полноценный KMS.
• Все данные пользователей в ETCD зашифрованы.

Для нас это большой шаг в сторону действительно безопасной Managed Kubernetes платформы 😈

Теперь шифрование данных — не отдельная опция и не дополнительная настройка, а часть платформы по умолчанию 😎

Пересматривал старые фотографии и наткнулся на это ☹️

Почти всем этим работам уже около 10 лет. Когда-то интернет-провайдинг занимал довольно большую часть моей жизни.

Как хорошо, что я оттуда ушел, но осталась приятная ностальгия 🤪

Всем доброго утра ☀️

Мы продолжаем улучшать Managed K8S 💻 в Beget.com.

Сегодня зарелизили сразу несколько связанных функций вокруг механики автоматического обновления кластеров.

😱 В предыдущем посте я писал, что мы обновили список доступных версий Kubernetes. За последние две недели через новый механизм мы успели обновить уже около 200 кластеров.

И здесь есть важный момент: у каждой компании и команды свой подход к обновлениям. Кто-то стремится всегда использовать максимально свежую версию Kubernetes. Кто-то предпочитает оставаться на предыдущем миноре с последними патчами. А кому-то важнее консервативность и проверенная временем версия.

😈 Поэтому теперь можно выбрать канал обновления:
• Actual — последняя доступная версия Kubernetes
• Balance — минус одна минорная версия от актуальной
• Stable — минус две минорные версии от актуальной

Вместе с каналами появились окна обновления. Можно указать, когда кластер разрешено обновлять, чтобы изменения не приезжали в неудобное для вашей команды время.

☹️При этом мы понимаем, что обновления Kubernetes для многих — болезненная история.

😱Но варианта «не обновляться вообще» мы сознательно не оставили. Кластер можно удерживать максимум на две минорные версии ниже актуальной. Патч-релизы в рамках выбранной минорной версии при этом будут устанавливаться автоматически.

Новый механизм уже прошёл проверку примерно на 200 кластерах и показал хорошие результаты.

Как всегда, будем рады обратной связи: чего вам не хватает в механике обновлений и что хотелось бы увидеть следующих релизах?

Так же запоздалая статья на хабре про услугу Managed K8S 😎

😘 Всем привет

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

Мы у себя в Beget вводим практику, в рамках которой стараемся сильно не отставать от upstream Kubernetes и регулярно актуализировать доступные версии.

На днях обновили патчи для 1.34/1.35 и добавили новую минорную версию — Kubernetes 1.36.

🎼 CHANGELOG
• Manifest-Based Admission Control — provider policy можно держать вне Kubernetes API, и tenant cluster-admin не сможет её удалить.
• User Namespaces GA — дополнительная изоляция контейнеров и multi-tenant кластеров.
• External SA Token Signer — проще строить trust между Kubernetes и внешним IAM/KMS.
• Mixed Version Proxy — безопаснее rolling upgrade control plane.
• Server-side sharded List/Watch — шаг к масштабированию больших кластеров и тяжёлых операторов.
• Workload-aware scheduling — gang scheduling / PodGroup для AI, batch и HPC.

☹️ Лично для нас одна из самых интересных фич — Manifest-Based Admission Control.
В Managed Kubernetes пользователю обычно хочется оставить полноценный cluster-admin, но при этом у команды, которая обслуживает платформу, есть свои инфраструктурные задачи.

Например, нужно вывести ноду из эксплуатации, а пользователь настроил:
PDB maxUnavailable: 0

или Pod'ы с:
tolerations: operator=Exists

В результате стандартный drain может стать невозможным или перестать работать так, как ожидает провайдер.

🤪 Раньше подобные ограничения можно было реализовать через admission webhook/policy внутри самого кластера, но cluster-admin при желании может их удалить или изменить.
Manifest-Based Admission Control позволяет задавать admission-конфигурацию статически на стороне kube-apiserver, вне обычных объектов Kubernetes API.

То есть можно оставить пользователю полноценный cluster-admin, но при этом сохранить небольшой набор инфраструктурных правил, необходимых для безопасного обслуживания кластера.

😈 Для Managed Kubernetes это очень интересный фундамент

😠 Поэтому в ближайшее время мы обновим все кластеры до Kubernetes 1.35, а после стабилизации 1.37 начнем постепенно двигаться к переходу на 1.36

Этот функционал также даст нам возможность запустить отдельный стрим — маркетплейс ограничений.

Идея простая: собрать набор готовых политик и ограничений, которые уже считаются хорошей практикой в индустрии и закрывают типовые вопросы безопасности.

Пользователь сможет выбрать нужный набор ограничений под свой кластер, а мы — применять их на уровне платформы так, чтобы они не конфликтовали с обычным cluster-admin 😎

Всем привет)

Есть вопросы: есть ли у вас потребность в механизме кастомной настройки пользовательских ВМ в Kubernetes-кластере?

Что-то похожее на Machine Config Operator в OpenShift: через кастомные ресурсы можно описать необходимые изменения на уровне ОС — конфиги, пакеты, systemd-сервисы и т. п.

При этом конфигурация применяется ко всем ВМ в нужной группе, а новые ВМ сразу создаются уже с этими настройками.

Насколько такой механизм был бы вам полезен и какие сценарии вы бы через него решали?

Второй вопрос есть ли потребность в выборе конкретного дистрибутива для ВМ?

Всем привет 😱

Managed K8S от beget.com, который развивается нами семимильными шагами, снова немного подрос.

Завезли две полезные функции 🤪
😈 Изменение конфигурации кластера уже после его создания.
🙃 Ручное обновление Kubernetes с версии A -> B.

Вроде бы базовые вещи, но для нас это первый шаг к более интересным механикам:
• Менять количество и размер master-нод уже на работающем кластере.
• Сделать обновления управляемыми, и уже скоро автоматическими.

Мы автоматизируем всё до чего достанем, поэтому делаем большой упор на автоматизированные процессы, что бы наши инженеры тратили все свои силы на развите стабильной платформы, а не поддержку 😎

Не успели начать рабочую неделю, а уже можно идти раскупоривать винчик и читать книжку 🤪

Интернет всё. Мелькает информация, что легла ММТС-9 — одна из крупнейших точек обмена трафиком. Вместе с ней прилегло множество сервисов, и список пока только растёт.

Держим кулачки за тех, у кого сейчас из-за этого Ж в мыле)

Всем доброго времени суток 😉

В Kubernetes-кластерах Beget произошли изменения:


Для тех, кто ещё не знаком с нашей архитектурой, коротко расскажу, как всё устроено.

Для каждого клиента создаём отдельный standalone-кластер Kubernetes на выделенных виртуальных машинах. При этом используем подход Kubernetes-in-Kubernetes: на одной ВМ одновременно работают два кластера.

Зачем нужна такая конструкция?

Она решает две ключевые задачи:

👀Скрывает управляющие узлы от конечного пользователя.
🤪Позволяет управлять жизненным циклом клиентского кластера.

Архитектура состоит из двух уровней:

😇 Infra-кластер находится под нашим управлением: мы его обслуживаем, обновляем и изменяем конфигурацию.

😈 Client-кластер принадлежит клиенту, но его компоненты работают внутри Infra-кластера как DaemonSet.

Такая схема позволяет:

• автоматизировать работу с сертификатами;
• управлять системой аддонов;
• реактивно изменять конфигурацию клиентских кластеров;
• централизованно управлять их жизненным циклом.
• и тп.

В последнее время мы уделили особое внимание безопасности и постарались закрыть максимум опасных сценариев.

Что изменилось в Infra ☹️

• В кластерах больше не хранится чувствительная информация, способная скомпрометировать клиентский кластер. Все секреты вынесены в централизованное хранилище с минимальными правами доступа.

• Для каждого кластера генерируются отдельные секреты со сложными паролями.

• Серверные интерфейсы компонентов Infra-кластера защищены mTLS и авторизацией Kubernetes.

• И вишенка на торте — мы описали около 227 сетевых политик Cilium для точечного контроля каждого сетевого потока из кластера, в кластер или через него и включили Host Firewall (default deny)

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

Практики, успешно обкатанные на нашей инфраструктуре, будем постепенно переносить и в клиентские кластеры, чтобы защищать их не только с нашей стороны, но и со стороны пользовательских нагрузок 😎

От себя добавлю, что мы постепенно движемся к выходу из беты. В ближайших планах — долгожданная поддержка RBD и S3 🤪

Параллельно формируем каталог аддонов, которые можно будет устанавливать в кластеры. Поэтому хочется узнать ваше мнение.

Есть два вопроса:

— Какие аддоны вы хотели бы видеть в списке доступных для установки?

— Какая модель вам кажется предпочтительнее?
• Мы берем аддоны на полное сопровождение: разворачиваем и обслуживаем их сами, а вы платите фиксированную абонентскую плату.
• Аддоны устанавливаются непосредственно в ваш кластер и используют ресурсы ваших нод.

Разумеется, речь не идет о базовых компонентах, необходимых для работы кластера, — они, как и сейчас, будут устанавливаться на клиентские ноды.

Будет интересно услышать ваши идеи и пожелания 😎

Бывают ситуации, когда базовых возможностей Kubernetes уже недостаточно – например, нужно подключить мониторинг, организовать хранение данных, добавить сетевые плагины и управление сертификатами.

Для этих и других задач могут пригодиться аддоны – готовые компоненты, которые избавляют от ручной настройки сервисов, помогая ускорить развертывание и сопровождение кластера.

Уже сейчас вы можете подключить K8s у нас и использовать такие аддоны:

🔹 Cilium – CNI-плагин, который обеспечивает сетевое взаимодействие между подами, сервисами и внешним трафиком, а также сетевую безопасность;
🔹 CoreDNS – позволяет сервисам находить друг друга по DNS-именам внутри кластера;
🔹 Konnectivity-agent – обеспечивает защищенный канал связи между worker-нодами и control plane;
🔹 Cert-manager – автоматически выпускает и продлевает TLS-сертификаты;
🔹 Cert-manager CSI Driver – передает сертификаты в приложения через Kubernetes Volume;
🔹 Kube-state-metrics – экспортирует данные о состоянии объектов Kubernetes;
🔹 Metrics Server – собирает метрики использования CPU и памяти;
🔹 Prometheus Node Exporter – экспортирует системные метрики нод: CPU, память, диск и сеть;
🔹 Prometheus Process Exporter – собирает метрики отдельных процессов на узлах;
🔹 Trust Manager – централизованно управляет доверенными сертификатами в кластере;
🔹 VictoriaMetrics Operator – разворачивает и управляет VictoriaMetrics в K8s.

Мы продолжаем развивать Kubernetes и хотим учесть ваше мнение: пожалуйста, пройдите опрос ниже, выбрав аддоны, которые могут быть полезны для ваших задач, а если нужного варианта нет – расскажите о нем в комментариях.

Ваше мнение поможет нам сделать Kubernetes удобнее.

#Kubernetes #K8s #аддоны #инфраструктура #облако #Beget #BegetCloud #опрос