Глобальные и региональные cloud-провайдеры предоставляют услуги Kubernetes as a service (KaaS). Можно ли сравнивать Deckhouse Platform с KaaS? По ряду причин — нет. Отметим ключевые.
Важно: далее мы сравниваем KaaS только с частью Deckhouse — в тех аспектах, где функциональность Kubernetes-сервисов и нашей платформы пересекаются.
Обычные KaaS-сервисы — это только основа. Много ручной работы.
KaaS — это «ванильный» Kubernetes в облаке провайдера. Пользователь KaaS самостоятельно управляет большей частью компонентов кластера. Также пользователь сам отвечает за обновление узлов: пересоздает виртуальные машины из обновленных образов, предоставленных провайдером. Установка и обслуживание сторонних решений, которые требуются для полноценной работы production-кластера, — все это тоже на пользователе.
Полная автоматизация
Deckhouse — это полнофункциональная платформа, которая, кроме «ванильного» Kubernetes, включает дополнительные модули для мониторинга, балансировки трафика, автомасштабирования, безопасного доступа и не только, которые преднастроены, интегрированы друг
с другом и готовы к работе.
Гибридная инфраструктура
Deckhouse поддерживает гибридную инфраструктуру для K8s. Кластеры можно создавать в облаках разных поставщиков и управлять ими как единой инфраструктурой.
Нет привязки к поставщику
Deckhouse не зависит от провайдера облачной инфраструктуры. Кластер можно переносить между облаками разных поставщиков.
Единый API управления
в любом облаке
Пользователь Deckhouse управляет Kubernetes через API самого Kubernetes, а не через API провайдеров, который у каждого свой. Для этого используется механизм Custom Resources.
Большинство облачных провайдеров в рамках managed-услуг управляют только компонентами Control Plane («управляющего слоя»): поддерживают и обновляют ПО для etcd, controller-manager, API server и т. д. Софтом, который относится к узлам K8s, а также всеми дополнительными модулями управляет пользователь. Такая модель обслуживания называется «Общая ответственность» (Shared responsibility); примеры: AKS, GKE, AWS.
Deckhouse сам управляет всеми компонентами Kubernetes и платформы: настраивает, обновляет и поддерживает их актуальную конфигурацию.
| КОМПОНЕНТЫ КЛАСТЕРА, ДРУГИЕ ФУНКЦИИ, ТЕХПОДДЕРЖКА | KAAS Базовые элементы | Процесс эксплуатации | DECKHOUSE PLATFORM Базовые элементы | Процесс эксплуатации |
|---|---|---|---|---|
| Control Plane: etcd, controller-manager, scheduler, API server, cloud-controller-manager | Провайдер | Провайдер | Deckhouse | |
| CNI (container network interface) | Провайдер | Пользователь | Deckhouse | |
| CSI (container storage interface) | Провайдер | Пользователь | Deckhouse | |
| Cluster-autoscaler | Провайдер | Пользователь | Deckhouse | |
| Узлы | Провайдер | Пользователь | Deckhouse | |
| Сетевая инфраструктура* | Провайдер | Пользователь | Deckhouse | |
| Мониторинг** | Провайдер | Пользователь | Deckhouse | |
| Обновление*** | Провайдер | Пользователь | Deckhouse | |
| Дополнительные модули | Пользователь | Пользователь | Deckhouse | |
| Техподдержка | Провайдер**** | Пользователь | Flant включена в контракт |
|
* Базовые элементы: элементы облака, например VPC, виртуальный маршрутизатор, сетевая политика и пр. Процесс эксплуатации: установка и настройка всех элементов и их взаимосвязей по API или через веб-интерфейс.
** Базовые элементы: платформа мониторинга, системное ПО, рекомендованные настройки. Процесс эксплуатации: установка, настройка и обслуживание ПО.
*** Базовые элементы: новые версии системного ПО, новые примеры настроек. Процесс эксплуатации: обновление ПО и настроек.
**** Включена в контракт, но не входит в стоимость ресурсов и оплачивается отдельно.
Облачные провайдеры поддерживают фоновые обновления без простоя только для некоторых компонентов Control Plane. Остальные элементы кластера обновляет пользователь, и провайдер не гарантирует бесперебойную работу контейнеров.
Deckhouse обновляет «на лету» не только Control Plane (и все его составляющие), но и все компоненты K8s, запущенные в контейнерах, а также весь софт на узлах. Ядро Linux и несовместимые обновления среды запуска контейнеров (container runtime) Deckhouse обновляет также автоматически, но с простоем, который пользователь может контролировать.
Для обновления компонентов Deckhouse доступны 5 каналов с разным уровнем стабильности — от экспериментального Alpha до самого надежного Rock Solid. Пользователь может менять каналы обновлений.
| КОМПОНЕНТЫ КЛАСТЕРА, ДРУГИЕ ФУНКЦИИ, ТЕХПОДДЕРЖКА | KAAS Зона ответственности | Простой | DECKHOUSE PLATFORM Зона ответственности | Простой |
|---|---|---|---|---|
| Control Plane: etcd, controller-manager, scheduler, API server, cloud-controller-manager | Провайдер | Нет | Deckhouse | Нет |
| CNI (container network interface) | Пользователь | Возможен | Deckhouse | Нет |
| CSI (container storage interface) | Пользователь | Возможен | Deckhouse | Нет |
| Nodes | Пользователь | Да* | Deckhouse | Нет** |
| Cluster-autoscaler | Пользователь | Возможен | Deckhouse | Нет |
| Сетевая инфраструктура | Пользователь | Возможен | Deckhouse | Нет |
* Узлы пересоздаются, контейнеры переезжают на новые узлы.
** Кроме ядра Linux и несовместимых обновлений container runtime.
У каждого облачного провайдера свои средства управления ресурсами облака и K8s: API, CLI-утилиты, веб-интерфейс. Пользователь управляет облаком, кластером и всей связанной инфраструктурой средствами провайдера. Тот же kubectl можно использовать только для непосредственной работы с контейнерами: создание, запуск, удаление и т. п. Чтобы, например, добавить узлы в кластер, удалить их или обновить системное ПО, приходиться пользоваться интерфейсом управления провайдера.
У Deckhouse все управление Kubernetes, а также дополнительными компонентами и низкоуровневой инфраструктурой построено через API самого Kubernetes. При этом можно использовать любые стандартные средства: kubectl, Helm, GitOps-утилиты типа werf или Argo CD.
Deckhouse предлагает ряд возможностей, которые облачные провайдеры либо не поддерживают, либо поддерживают частично.
Пользователь может выбирать самый свежий релиз K8s или любой из четырех предыдущих.
Deckhouse предлагает несколько вариантов установки Control Plane (схем размещения) для обеспечения высокой доступности. Схемы отличаются разной степенью надежности:
С помощью опции Feature Gates пользователь Deckhouse может включать и выключать отдельные функции компонентов Kubernetes, в том числе экспериментальные: alpha, beta и т. д. Deckhouse поддерживает все функции, указанные в документации Kubernetes.
Кластер может быть развернут одновременно на «железных» серверах и на виртуальных машинах (ВМ). При этом Deckhouse умеет автоматически масштабировать «железный» кластер с помощью ВМ. Это удобно, когда, например, нужно быстро добавить вычислительные мощности, а запасного сервера нет.
У большинства KaaS-провайдеров доступ к кластеру Kubernetes можно организовать только через средства аутентификации самого провайдера. То есть, если для доступа к кластеру используется, например, внешний сервис аутентификации LDAP, при переходе на KaaS прямая «стыковка» K8s и LDAP будет уже невозможна.
Deckhouse избавлена от этой проблемы благодаря реализации двух функций при доступе к API server:
Deckhouse предлагает официальную поддержку сетевой инфраструктуры K8s на базе Cilium.
Cilium — сервис, который повышает производительность, наблюдаемость и безопасность сетевой инфраструктуры Kubernetes.
Особенности Cilium:
Кроме стандартного преднастроенного автоскейлинга, можно использовать резервные узлы (standby instances). Это ВМ, которые находятся в «горячем резерве» в дополнение к рабочим ВМ. Количество резервных узлов выбирает пользователь. Например, если доля резервных составляет 10%, при автоскейлинге с 10 до 50 рабочих узлов количество резервных увеличивается с 1 до 5.
Резервные узлы повышают устойчивость кластера при резком росте нагрузки: ВМ уже работают и при необходимости добавляются в кластер мгновенно, в то время как для добавления обычных ВМ требуется 2–3 минуты, что может быть критичным для некоторых сервисов.
Deckhouse поддерживает прерываемые ВМ (spot/preemptible VM’s), которые стоят дешевле, чем обычные, и заказываются по итогам «аукциона». У таких ВМ более низкий уровень отказоустойчивости.
Для повышения отказоустойчивости есть возможность распределить узлы одного кластера по нескольким зонам без потери производительности.