Чем 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.
Самоуправляемость
Большинство облачных провайдеров в рамках 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.