Сегодня состоялся долгожданный публичный 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, который:
Работает на любой инфраструктуре. Задача становится особенно критичной с учётом разнообразия клиентов. Ведь у одних — bare metal-серверы и виртуальные машины, у других — публичные облачные провайдеры, у третьих — частное облако или вообще какая-то комбинация. Кстати, разве не эту ли возможность — запускать в любой инфраструктуре — нам обещали как одну из самых главных фич Kubernetes?.. Кажется, даже не все успели заметить, как облачные провайдеры со своими managed-решениями «забрали» эту особенность у пользователей K8s.
Предоставляет всё необходимое для запуска реальных приложений. Не базовый конструктор «собери [и допили] сам», а полноценную обвязку из тех фич, которые действительно нужны для работы и эксплуатации приложений. Подробнее о них будет дальше.
Полностью обслуживается. Все вопросы поддержки кластеров — обновления их компонентов, мониторинга и т. п. — решаются автоматически или кем-то из платформенной команды.
Наш внутренний продукт, позже названный Deckhouse (это имя было принято в конце 2019 года), стал ответом на такие потребности.
Что такое Deckhouse
Платформа, а не кластер
Чем же Deckhouse отличается от многих других вариантов использования Kubernetes? Для иллюстрации самого главного в этом понимании проведу хорошую аналогию от @distol:
Что такое «ванильный» Kubernetes? Это пустая квартира.
Достаточно ли её для того, чтобы действительно жить? Как-то жить в ней, конечно, можно… (Да, не у всех одинаковые представления о комфортной жизни.) Но обычно нам всё-таки нужно эту квартиру заполнить. Мебелью и другими бытовыми принадлежностями.
Deckhouse — это обставленная всем необходимым для жизни квартира, с детально продуманной эргономикой и всеми инженерными коммуникациями.
В таком смысле нам кажется более подходящим слово платформа, и поэтому основной продукт нового проекта называется Deckhouse Platform.
К этой же категории решений относится, например, OpenShift от Red Hat. Подобные платформы иногда путают с managed-сервисами вроде GKE и AKS, но это не корректно. Последние не предлагают комплексное решение — платформу: они предлагают вам неплохой фундамент и голые стены, но не закрывают важные вопросы, такие как мониторинг, безопасность и т. д.
Целостное решение
Если отбросить этот принципиальный момент и всё же минимально погрузиться в детали отличия такой платформы от популярных managed-решений, то легко увидеть следующее:
Политика облачных провайдеров — это совместная, разделяемая ответственность (shared responsibility): AWS, GKE, AKS. Её суть в позиции «бери и делай» в то время, как позиция у платформ вроде Deckhouse — «бери и пользуйся».
Deckhouse Platform не зависит от инфраструктуры и предлагает полностью идентичные кластеры + единые подходы к их настройке и управлению (на любой инфраструктуре).
Для обновления узлов Kubernetes провайдеры предлагают пересоздавать виртуальные машины, а в Deckhouse это делается «наживую» в подавляющем большинстве случаев. (Исключения случаются только тогда, когда требуется обновить ядро Linux и подобные системные компоненты.)
У провайдеров могут быть дополнительные возможности, однако их число очень ограничено и, как правило, завязано на их инфраструктуру, а не стандарты 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.
При этом все 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.
Редакции 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. А также:
Подписывайтесь на Twitter проекта, чтобы следить за обновлениями.
По любым вопросам, связанным с работой платформы, можно писать в русскоязычный Telegram-чат (есть и чат на английском).
Будем признательны за поддержку проекта на GitHub: поставьте звёздочку!
P.S.
Читайте также в нашем блоге:
«Как правильно сделать Kubernetes» (обзор и видео доклада);
«Как мы обновляли Kubernetes 1.16 до 1.19… с удовольствием».
