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

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

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

Обычные KaaS-сервисы — только основа. Много ручной работы

KaaS — это «ванильный» Kubernetes в облаке провайдера. Пользователь KaaS самостоятельно управляет большей частью компонентов кластера. Также пользователь сам отвечает за обновление узлов: пересоздает виртуальные машины из обновленных образов, предоставленных провайдером. Установка и обслуживание сторонних решений, которые требуются для полноценной работы production-кластера, — тоже на пользователе.

Deckhouse — всё, что нужно. Полностью автоматизировано

Deckhouse — это полнофункциональная платформа, которая, кроме «ванильного» Kubernetes, включает дополнительные модули для мониторинга, балансировки трафика, автомасштабирования, безопасного доступа и не только. Модули преднастроены, интегрированы друг с другом и готовы к работе. Управление всеми компонентами кластера и платформы, а также их обновление полностью автоматизированы.

А ещё это

Нет привязки к поставщику

Deckhouse не зависит от провайдера облачной инфраструктуры. Кластер можно «переносить» между облаками разных поставщиков.

Гибридная инфраструктура

Deckhouse поддерживает гибридную инфраструктуру для K8s. Кластеры можно создавать в облаках разных поставщиков и управлять ими как единой инфраструктурой.

Единый API управления в любом облаке

Пользователь Deckhouse управляет Kubernetes через API самого Kubernetes, а не через API провайдеров, который у каждого свой. Для этого используется механизм Custom Resources.

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

Самоуправляемость

Большинство облачных провайдеров в рамках 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
Техподдержка
Провайдер
включена в контракт, но не входит в стоимость ресурсов и оплачивается отдельно
Пользователь
Флант
включена в контракт

* «Кирпичи»: элементы облака, например VPC, виртуальный маршрутизатор, сетевая политика и пр.
«Стройка»: установка и настройка всех элементов и их взаимосвязей по API или через веб-интерфейс.

** «Кирпичи»: платформа мониторинга, системное ПО, рекомендованные настройки. «Стройка»: установка, настройка и обслуживание ПО.

*** «Кирпичи»: новые версии системного ПО, новые примеры настроек. «Стройка»: обновление ПО и настроек.

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

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

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

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

  • В любое время.
  • В заданные временные окна (скоро).
  • После подтверждения пользователем.

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

Обновление компонентов
KaaS
Deckhouse Platform
Зона ответственности
Простой
Зона ответственности
Простой
Control Plane:
etcd, controller-manager, scheduler, API server, cloud-controller-manager
Провайдер
Нет
Deckhouse
Нет
CNI
Пользователь
Возможен
Deckhouse
Нет
CSI
Пользователь
Возможен
Deckhouse
Нет
Узлы
Пользователь
Да*
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.

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

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

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

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

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

  • Резервные узлы (standby instances).
    Кроме стандартного преднастроенного автоскейлинга, можно использовать резервные узлы (standby instances). Это ВМ, которые находятся в «горячем резерве» в дополнение к рабочим ВМ. Количество резервных узлов выбирает пользователь. Например, если доля резервных составляет 10%, при автоскейлинге с 10 до 50 рабочих узлов количество резервных увеличивается с 1 до 5.
  • Резервные узлы повышают устойчивость кластера при резком росте нагрузки: ВМ уже работают и, при необходимости, добавляются в кластер мгновенно. В то время как для добавления обычных ВМ требуется 2-3 минуты, что может быть критичным для некоторых сервисов.
  • Прерываемые ВМ
    Deckhouse поддерживает прерываемые ВМ (spot/preemptible VM’s), которые стоят дешевле, чем обычные и заказываются по итогам «аукциона». У таких ВМ более низкий уровень отказоустойчивости.
  • Равномерное распределение ВМ между зонами
    Для повышения отказоустойчивости есть возможность распределить узлы одного кластера по нескольким зонам без потери производительности.

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

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

Поддержка cilium
скоро

  • cilium — сервис, который повышает производительность, наблюдаемость и безопасность сетевой инфраструктуры Kubernetes. Особенности cilium:
    • высокая производительность и низкая задержка;
    • гибкая и быстрая масштабируемость кластера вплоть до 5000 узлов;
    • эффективная балансировка трафика;
    • прозрачное взаимодействие между кластерами;
    • продвинутые политики сетевого доступа;
    • дополнительная криптозащита и многое другое.
  • Deckhouse предлагает официальную поддержку сетевой инфраструктуры K8s на базе cilium.
Мы используем cookies
Продолжая использовать наш сайт, вы даете согласие на обработку файлов cookie. Подробнее