Представляем Kubernetes-платформу Deckhouse. Теперь в Open Source и для всех

Сегодня состоялся долгожданный публичный Open Source-релиз нашей платформы для автоматизации обслуживания кластеров Kubernetes — Deckhouse. Этому предшествовало три с половиной года внутренней разработки и эксплуатации платформы на многочисленных и весьма разнообразных проектах. Сейчас с помощью Deckhouse мы обслуживаем в production более 170 кластеров (3500+ узлов), в которых развернуто около 3000 приложений. Deckhouse — это квинтэссенция нашего опыта в эксплуатации Kubernetes-кластеров и кульминация всей связанной с этим производственной деятельности последних лет.

Мы начали выдавать ранний доступ к платформе и демонстрировать её возможности ещё в мае, на конференции HighLoad++. Уже более 300 человек смогли самостоятельно попробовать Deckhouse. Пришло время поделиться нашим опытом автоматизации Kubernetes с более широким сообществом!

Как и почему появился Deckhouse

Проект Deckhouse зародился внутри «Фланта» естественным образом. Увидев в Kubernetes огромный потенциал для удобного сопровождения инфраструктуры, мы приняли его за стандарт и, набираясь нужного опыта, стали разворачивать в нём всё больше приложений: и своих (dogfooding — это очень про нас), и клиентских.

Стремительно набирался опыт по эксплуатации Kubernetes-кластеров, появлялись сопутствующие лучшие практики — всё это требовало стандартизации. Помимо совсем очевидных на то причин (IaC, автоматизация…) важен и такой нюанс: сопровождением у нас занимаются инженеры из разных команд внутри компании, а создаваемые подходы и решения актуальны для всех. Переизобретать то, что уже сделано коллегами, — путь в никуда.

Аккумуляция лучших практик началась в рамках будущего Deckhouse. В его разработке сначала участвовали SRE/DevOps-инженеры разных команд, а со временем — выделенная команда. Такая передача всех платформенных задач по Kubernetes в новое подразделение позволила инженерам других команд полностью забыть об этом слое проблем. Все они получили в своё вооружение Kubernetes, в котором уже есть всё нужное и который «просто работает». Команды отныне смогли сфокусироваться на других задачах, более приближенных к потребностям разработчиков и бизнеса наших клиентов.

О каких проблемах наши инженеры хотели/смогли забыть? Нужен был Kubernetes, который:

1. Работает на любой инфраструктуре. Задача становится особенно критичной с учётом разнообразия клиентов. Ведь у одних — bare metal-серверы и виртуальные машины, у других — публичные облачные провайдеры, у третьих — частное облако или вообще какая-то комбинация. Кстати, разве не эту ли возможность — запускать в любой инфраструктуре — нам обещали как одну из самых главных фич Kubernetes?.. Кажется, даже не все успели заметить, как облачные провайдеры со своими managed-решениями «забрали» эту особенность у пользователей K8s.

2. Предоставляет всё необходимое для запуска реальных приложений. Не базовый конструктор «собери [и допили] сам», а полноценную обвязку из тех фич, которые действительно нужны для работы и эксплуатации приложений. Подробнее о них будет дальше.

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

Наш внутренний продукт, позже названный Deckhouse (это имя было принято в конце 2019 года), стал ответом на такие потребности.

Что такое Deckhouse

Платформа, а не кластер

Чем же Deckhouse отличается от многих других вариантов использования Kubernetes? Для иллюстрации самого главного в этом понимании проведу хорошую аналогию от @distol:

• Что такое «ванильный» Kubernetes? Это пустая квартира.

• Достаточно ли её для того, чтобы действительно жить? Как-то жить в ней, конечно, можно… (Да, не у всех одинаковые представления о комфортной жизни.) Но обычно нам всё-таки нужно эту квартиру заполнить. Мебелью и другими бытовыми принадлежностями.

• Deckhouse — это обставленная всем необходимым для жизни квартира, с детально продуманной эргономикой и всеми инженерными коммуникациями.

В таком смысле нам кажется более подходящим слово платформа, и поэтому основной продукт нового проекта называется Deckhouse Platform.

К этой же категории решений относится, например, OpenShift от Red Hat. Подобные платформы иногда путают с managed-сервисами вроде GKE и AKS, но это не корректно. Последние не предлагают комплексное решение — платформу: они предлагают вам неплохой фундамент и голые стены, но не закрывают важные вопросы, такие как мониторинг, безопасность и т. д.

Что покрывают возможности Deckhouse Platform

Целостное решение

Если отбросить этот принципиальный момент и всё же минимально погрузиться в детали отличия такой платформы от популярных managed-решений, то легко увидеть следующее:

1. Политика облачных провайдеров — это совместная, разделяемая ответственность (shared responsibility): AWS, GKE, AKS. Её суть в позиции «бери и делай» в то время, как позиция у платформ вроде Deckhouse — «бери и пользуйся».

2. Deckhouse Platform не зависит от инфраструктуры и предлагает полностью идентичные кластеры + единые подходы к их настройке и управлению (на любой инфраструктуре).

3. Для обновления узлов Kubernetes провайдеры предлагают пересоздавать виртуальные машины, а в Deckhouse это делается «наживую» в подавляющем большинстве случаев. (Исключения случаются только тогда, когда требуется обновить ядро Linux и подобные системные компоненты.)

4. У провайдеров могут быть дополнительные возможности, однако их число очень ограничено и, как правило, завязано на их инфраструктуру, а не стандарты cloud native-индустрии.

Последний пункт для наглядности проиллюстрируем на нескольких примерах:

• Обновление кластера в EKS? Вот как выглядит официальная инструкция. Каждый «сторонний» компонент, т. е. объект мебели в нашей квартире (вплоть до CNI, CoreDNS и т. п.), требует отдельной заботы и понятных последствий. В Deckhouse для этой операции достаточно обновить одну строку с версией Kubernetes.

• Интеграция с внешними провайдерами для аутентификации и авторизации (LDAP, GitHub…)? Конечно, есть рецепт… Но немыслимо сравнивать эту схему с конфигом из нескольких строк для Deckhouse.

• Каковы подходы к масштабированию приложений по кастомным метрикам у провайдеров? Сложная схема с дополнительными компонентами, ответственность за которую при любых изменениях и обновлениях останется, конечно, на вас. Как вы догадались, в Deckhouse всё иначе.

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

Технологический фундамент

В основе Deckhouse Platform — upstream-версия Kubernetes и Open Source-компоненты, являющиеся стандартом в cloud native-экосистеме. Платформа интегрирует их между собой и дополняет «ядро» всем необходимым для production-окружений, сводя к минимуму ручные манипуляции.

Что же это за стандартные компоненты? Привычные для cloud native-сообщества проекты, такие как CoreDNS, cert-manager, nginx, Prometheus + Grafana, dex, Istio и т.п. (Более полный их список можно найти в документации, а ниже мы ещё расскажем об основных фичах на их основе.)

Решения на основе этих проектов были «приготовлены» для конечных пользователей в виде модулей платформы Deckhouse. Это означает, что конфигурации для всех них продуманы, они между собой интегрированы и постоянно обновляются (в таком режиме, что пользователю не нужно об этом думать). Управление настройками модулей осуществляется через определение простых Custom Resources. Эти ресурсы спроектированы с философией минимализма и предоставляют минимум параметров, а значит — и минимум возможности ошибиться.

Модули в Deckhouse Platform реализованы с помощью двух Open Source-инструментов, разработанных во «Фланте» и представленных широкому сообществу более двух лет назад: shell-operator (апрель'19) и addon-operator (июнь'19).

• shell-operator позволяет создавать скрипты*, которые запускаются при наступлении определенных событий в кластере Kubernetes.

• addon-operator предназначен для автоматического управления Kubernetes-модулями, которые созданы с помощью shell-operator.

* В прототипах большинства модулей мы использовали Bash-скрипты, потому что так было проще (быстрее) всего. Когда прототипы доказали свою пригодность, мы переписали их на язык Go, код которого проще читать, поддерживать и тестировать.

NB: Кстати, shell-operator и addon-operator используются и вне Deckhouse. Например, нам известно про проекты на их основе в Adobe, KubeSphere и Confluent.

Особенности Deckhouse Platform

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

1. Не зависит от инфраструктуры

Как уже отмечалось, создавать K8s-кластеры можно на любой инфраструктуре: на железе, в виртуалках, в облаках. И ключевой момент в том, что кластеры получаются одинаковыми. Это означает, что у них идентичны:

• версия Kubernetes (с точностью до последнего бита);

• подходы к управлению кластером и API для управления им;

• механика работы ключевых подсистем: балансировки трафика, Cluster Autoscaler, мониторинга, аутентификации и авторизации;

• и все прочие доступные/используемые модули.

В контексте поддержки публичных облачных провайдеров важно заметить, что на данный момент в них не используются managed-решения (EKS, GKE, AKS…), а вместо этого задействованы обычные виртуальные ресурсы, на которых мы устанавливаем свой дистрибутив. Именно это позволяет гарантировать абсолютную идентичность кластеров, не зависеть от особенностей и ограничений провайдеров — например, от отсутствия возможности настройки OIDC или ограничения на количество Pod’ов на один узел. Это же позволяет обеспечивать полную техническую поддержку и настоящие гарантии.

NB. Однако мы не исключаем возможность использования и managed-решений от провайдеров — ведь уже сейчас можно поставить Deckhouse в существующий кластер. В будущем также планируем реализовать — как один из вариантов — возможность установки с использованием managed control plane от провайдеров.

Поддерживаемые облака в настоящий момент:

• Amazon AWS;

• Microsoft Azure;

• Google Cloud Platform;

• Яндекс.Облако;

• OpenStack (как свои инсталляции, так и облачные провайдеры, которые его используют — например, OVH Cloud);

• VMware vSphere (аналогично OpenStack).

Список будет пополняться в соответствии со спросом от пользователей.

2. Дает все необходимое для обслуживания production-кластера

Среди функций, встроенных в Deckhouse Platform:

• мониторинг на базе cloud native-проектов, охватывающий полный цикл, т.е.:

  • сбор — готова огромная коллекция экспортеров с ограничением доступа только авторизованным сборщикам и проработан способ сбора метрик из пользовательских приложений;

  • хранение — детализированное и longterm-хранилища на основе Prometheus (с кешированием запросов и адаптацией дисков под объём данных);

  • интерпретацию — широкая коллекция полезных алертов, позволяющих своевременно узнавать о проблемах;

  • визуализацию метрик — богатый каталог панелей для Grafana, значительно ускоряющих диагностику, т.к. они позволяют не просто смотреть на метрики, а делать drill-down и добираться до корня проблем;

• Ingress-контроллер (на основе NGINX Ingress Controller) для приёма пользовательского трафика. Он обладает полной поддержкой как работы через внешние балансировщики (облачные или независимые), так и работы напрямую с пользователями. При этом техническое обслуживание контроллеров происходит бесшовно;

• автоматическое горизонтальное (HPA) и вертикальное (VPA) масштабирование приложений с простой (в отличие от «ванильного» Kubernetes) возможностью использовать все доступные в Prometheus метрики, а не только CPU и RAM;

• аутентификация пользователей через любых внешних провайдеров (OIDC, LDAP, Google, GitHub…) с элементарной настройкой (на базе dex) и гибкое ограничение доступа для пользователей с преднастроенными ролями, которые подойдут большинству;

• сбор прикладных логов с помощью Vector и отправка в выбранное вами хранилище;

• service mesh на базе Istio с исчерпывающими возможностями по observability и управлению трафиком. Предусмотрена удобная возможность объединять кластеры в федерацию или мультикластер, а также бесшовное обновление версий control plane;

• а также: веб-панель Kubernetes dashboard, управление SSL-сертификатами с помощью cert-manager, доступ в кластер по OpenVPN, управление доступом к приложениям (в нескольких вариантах), готовая система priority классов и descheduler.

Пример одного из dashboard'ов, встроенных в Deckhouse

При этом все Docker-образы модулей, основанных на стороннем ПО, не используются как есть, а пересобираются идемпотентно на базе проверенных образов Alpine, Ubuntu и т. д. То есть:

• при сборке образов системных компонентов версии стороннего ПО фиксируются и обновляются по мере развития платформы;

• обновление базовых образов и основанных на них компонентов происходит централизованно, что гарантирует оперативное закрытие отдельных CVE (Common Vulnerabilities and Exposures).

Более полный список модулей и их настроек можно найти в документации.

3. Упрощает работу с K8s — NoOps-подход

Во «Фланте» для обслуживания 170+ кластеров достаточно двух инженеров. Это возможно благодаря тому, что большинство компонентов платформы управляются автоматически:

• системное ПО — ядро, CRI (container runtime interface);

• базовый софт Kubernetes ПО — kubelet, control plane, etcd, их сертификаты;

• компоненты платформы Deckhouse.

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

4. Разворачивает кластеры за 8 минут

Готовый к работе Kubernetes-кластер можно развернуть всего за 8 минут с помощью пары команд в CLI. Для каждого облачного провайдера есть преднастроенные конфигурации. Документация по всем модулям доступна на русском и английском языках.

5. Гарантирует SLA 99,95%

Благодаря NoOps-подходу и тщательному тестированию перед выпуском нам удалось добиться высокой надежности платформы. Даже без прямого доступа к инфраструктуре клиента мы можем предоставить SLA на уровне 99,95% (а с прямым доступом — еще выше). Для мониторинга SLA есть отдельный компонент контроля ключевых подсистем, информационная страница status page, на которой можно отслеживать текущее состояние сервиса, и подробный dashboard.

Status page с информацией о доступности компонентов Deckhouse

Редакции Deckhouse Platform

Deckhouse — проект с открытым исходным кодом. Поучаствовать в его развитии на GitHub может любой желающий. У платформы есть две редакции: бесплатная Community Edition (CE) и коммерческая Enterprise Edition (EE). CE-версия платформы выложена на GitHub под свободной лицензией Apache 2.0.

• Deckhouse CE включает основную функциональность платформы, в том числе возможность развертывания в публичном облаке и на bare-metal. Подходит для тех, кто хочет попробовать Deckhouse Platform полностью самостоятельно, то есть без вендорской поддержки.

• Deckhouse EE включает дополнительные возможности, такие как развертывание на OpenStack и VMware vSphere, Istio service mesh и продвинутые фичи для bare metal-кластеров, а также различные варианты подписки с поддержкой «Фланта». Исходный код EE-версии тоже открыт, но не как Open Source, а только для ознакомительных целей (коммерческий). Enterprise-версию Deckhouse можно рассматривать как альтернативу Red Hat OpenShift, Platform9 и т. п.

Тем, кто хотел бы доверить полное обслуживание и поддержку Kubernetes «Фланту», также доступна услуга Managed Deckhouse. Она основана на Enterprise-версии платформы Deckhouse и подразумевает, что вся ответственность за работу K8s-инфраструктуры ложится на плечи нашей команды.

Попробовать

Начните с быстрого старта. Это пошаговая инструкция по установке Deckhouse Platform на выбранную инфраструктуру: уже существующий кластер, bare metal-сервер, Yandex.Cloud, AWS, GCP, Azure, OpenStack.

Также мы выдаем токены для 30-дневного доступа к редакции EE.

Узнать больше

Познакомиться с возможностями разных версий платформы можно на сайте Deckhouse. А также:

P.S.

Читайте также в нашем блоге:

Adblock test (Why?)