Чем Deckhouse отличается от Amazon EKS, GKE, AKS и других Kubernetes-сервисов

Глобальные и региональные cloud-провайдеры предоставляют услуги Kubernetes as a service (KaaS). Можно ли сравнивать Deckhouse Platform с KaaS? По ряду причин — нет. Отметим ключевые.

Важно: далее мы сравниваем KaaS только с частью Deckhouse — в тех аспектах, где функциональность Kubernetes-сервисов и нашей платформы пересекаются.

Deckhouse will soon be able to work “on top of” EKS, AKS, GKE, and other KaaS platforms

Больше, чем кластер

Обычные 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 или через веб-интерфейс.
** Базовые элементы: платформа мониторинга, системное ПО, рекомендованные настройки. Процесс эксплуатации: установка, настройка и обслуживание ПО.
*** Базовые элементы: новые версии системного ПО, новые примеры настроек. Процесс эксплуатации: обновление ПО и настроек.
**** Включена в контракт, но не входит в стоимость ресурсов и оплачивается отдельно.

Уже заинтересовались Deckhouse?

Бесшовное автоматическое обновление

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

Deckhouse обновляет «на лету» не только Control Plane (и все его составляющие), но и все компоненты K8s, запущенные в контейнерах, а также весь софт на узлах. Ядро Linux и несовместимые обновления среды запуска контейнеров (container runtime) Deckhouse обновляет также автоматически, но с простоем, который пользователь может контролировать.

Для обновления компонентов Deckhouse доступны 5 каналов с разным уровнем стабильности — от экспериментального Alpha до самого надежного Rock Solid. Пользователь может менять каналы обновлений.

Подробнее

Возможные режимы обновления ядра и container runtime

  • В любое время
  • После подтверждения пользователем
  • В заданные временные окна (скоро)
КОМПОНЕНТЫ КЛАСТЕРА,
ДРУГИЕ ФУНКЦИИ,
ТЕХПОДДЕРЖКА
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.

Простота и удобство

KaaS: свой проприетарный API у каждого провайдера

У каждого облачного провайдера свои средства управления ресурсами облака и K8s: API, CLI-утилиты, веб-интерфейс. Пользователь управляет облаком, кластером и всей связанной инфраструктурой средствами провайдера. Тот же kubectl можно использовать только для непосредственной работы с контейнерами: создание, запуск, удаление и т. п. Чтобы, например, добавить узлы в кластер, удалить их или обновить системное ПО, приходиться пользоваться интерфейсом управления провайдера.

Deckhouse: единый, знакомый API в любом облаке

У Deckhouse все управление Kubernetes, а также дополнительными компонентами и низкоуровневой инфраструктурой построено через API самого Kubernetes. При этом можно использовать любые стандартные средства: kubectl, Helm, GitOps-утилиты типа werf или Argo CD.

Дополнительные опции

Deckhouse предлагает ряд возможностей, которые облачные провайдеры либо не поддерживают, либо поддерживают частично.

Не менее 5 версий Kubernetes

Пользователь может выбирать самый свежий релиз K8s или любой из четырех предыдущих.

Гибкое управление Control Plane

Deckhouse предлагает несколько вариантов установки Control Plane (схем размещения) для обеспечения высокой доступности. Схемы отличаются разной степенью надежности:

  • 1 виртуальная машина (ВМ);
  • кластер из 3 ВМ — в одной или в разных зонах;
  • кластер из 5 ВМ: 3 — для etcd и 2 — для scheduler, API server, cloud-controller-manager.

Управление Feature Gates (скоро)

С помощью опции Feature Gates пользователь Deckhouse может включать и выключать отдельные функции компонентов Kubernetes, в том числе экспериментальные: alpha, beta и т. д. Deckhouse поддерживает все функции, указанные в документации Kubernetes.

Гибридные кластеры

Кластер может быть развернут одновременно на «железных» серверах и на виртуальных машинах (ВМ). При этом Deckhouse умеет автоматически масштабировать «железный» кластер с помощью ВМ. Это удобно, когда, например, нужно быстро добавить вычислительные мощности, а запасного сервера нет.

Возможность внешней аутентификации и авторизации

У большинства KaaS-провайдеров доступ к кластеру Kubernetes можно организовать только через средства аутентификации самого провайдера. То есть, если для доступа к кластеру используется, например, внешний сервис аутентификации LDAP, при переходе на KaaS прямая «стыковка» K8s и LDAP будет уже невозможна.

Deckhouse избавлена от этой проблемы благодаря реализации двух функций при доступе к API server:

Поддержка Cilium

Deckhouse предлагает официальную поддержку сетевой инфраструктуры K8s на базе Cilium.

Cilium — сервис, который повышает производительность, наблюдаемость и безопасность сетевой инфраструктуры Kubernetes.

Особенности Cilium:

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

Расширенные возможности автоматического масштабирования

Резервные узлы (standby instances).

Кроме стандартного преднастроенного автоскейлинга, можно использовать резервные узлы (standby instances). Это ВМ, которые находятся в «горячем резерве» в дополнение к рабочим ВМ. Количество резервных узлов выбирает пользователь. Например, если доля резервных составляет 10%, при автоскейлинге с 10 до 50 рабочих узлов количество резервных увеличивается с 1 до 5.

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

Прерываемые ВМ

Deckhouse поддерживает прерываемые ВМ (spot/preemptible VM’s), которые стоят дешевле, чем обычные, и заказываются по итогам «аукциона». У таких ВМ более низкий уровень отказоустойчивости.

Равномерное распределение ВМ между зонами

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

Готовы начать?

Оставьте свои данные, и наш менеджер свяжется с вами

Отправляя форму, вы соглашаетесь с Политикой конфиденциальности.