Теперь, когда Kubernetes выиграл войны за оркестровку контейнеров, все основные поставщики облачных услуг предлагают управляемые услуги Kubernetes для своих клиентов. Управляемые службы Kubernetes предоставляют и управляют плоскостью управления Kubernetes, набором служб, которые обычно выполняются на главных узлах Kubernetes в кластере, созданном непосредственно на виртуальных или физических машинах. Хотя десятки поставщиков получили статус сертифицированного Kubernetes от Федерации облачных вычислений, что означает, что их предложение или реализация Kubernetes соответствует согласованному интерфейсу, детали между предложениями могут различаться. Это изменение может быть особенно актуальным для управляемых сервисов Kubernetes, которые часто будут поддерживать различные функции и опции для своих плоскостей и узлов управления кластером.

Мы подробно рассмотрели текущие функции и ограничения управляемых услуг Kubernetes от трех крупнейших поставщиков облачных услуг: Amazon Elastic Kubernetes Service (EKS), Microsoft Azure Kubernetes Service (AKS) и Google Kubernetes Engine (GKE). Мы надеемся, что, представляя эту информацию последовательно, как нынешние пользователи Kubernetes, так и потенциальные пользователи могут выбрать подходящие варианты или получить обзор текущего состояния управляемых Kubernetes.
Несмотря на то, что мы затрагиваем такие важные темы, как доступность версий, параметры сети и безопасности, а также накладные расходы на управление, мы не отталкиваемся от различий в цене и производительности. Вся информация была актуальной по состоянию на 10 февраля 2020 года.

Общая информация

Amazon EKS Microsoft AKS Google GKE Kubernetes
Поддерживаемые версии Kubernetes
  • 1.14 (по умолчанию)
  • 1,13
  • 1,12
  • 1.17 ( превью )
  • 1.16 ( превью )
  • 1,15
  • 1.14 (по умолчанию)
  • 1,13
  • 1.16 ( быстрый канал — бета )
  • 1,15
  • 1,14
  • 1.13 (по умолчанию)
  • 1,18 ( альфа )
  • 1,17
  • 1,16
  • 1,15
# поддерживаемых минорных версий ≥3 + 1 устарела 3 2-3 3
Дата выхода оригинальной GA Июнь 2018 Июнь 2018 Август 2015 Июль 2015 (Kubernetes 1.0)
CNCF Kubernetes соответствие да да да да
Последняя версия, сертифицированная CNCF 1,14 1,14 1,14
Мастер обновления Инициация пользователем; пользователь также должен вручную обновить системные службы, работающие на узлах (например, kube-proxy, coredns, AWS VPC CNI) Инициация пользователем Автоматически обновляется во время обслуживания кластера; может быть инициировано пользователем
Процесс обновления узла
  • Неуправляемые группы узлов: все инициируемые пользователем и управляемые
  • Группы управляемых узлов: инициируемые пользователем; EKS будет сливать и заменять узлы
Инициация пользователем; AKS будет сливать и заменять узлы Автоматически обновляется (по умолчанию; может быть отключен) во время обслуживания кластера; может быть инициировано пользователем; GKE истощает и заменяет узлы
Запуск контейнера Docker Moby Docker
  • Докер (по умолчанию)
  • containerd
  • Linux: Docker, containerd, cri-o, rktlet, любая среда выполнения, реализующая интерфейс Kubernetes CRI (интерфейс среды выполнения контейнера)
  • Windows: Docker EE-basic 18.09
Варианты высокой доступности master/ control plane Плоскость управления развернута в нескольких зонах доступности В документах Azure не указываются меры избыточности для плоскости управления
  • Зональные / многозонные кластеры: единая плоскость управления
  • Региональные кластеры: реплики плоскости управления в нескольких зонах
поддерживает
Master (control plane) SLA 99,9% 99,5%
  • Зональные кластеры: 99,5%
  • Региональные кластеры: 99,95%
SLA с финансовой поддержкой да нет нет
Стоимость $0,10 / час (USD) за кластер + стандартные затраты на экземпляры EC2 и другие ресурсы Стандартные затраты на виртуальные машины узлов и другие ресурсы Стандартные затраты на машины GCE и другие ресурсы
Поддержка GPU Да (NVIDIA); пользователь должен установить плагин устройства в кластере Да (NVIDIA); пользователь должен установить плагин устройства в кластере Да (NVIDIA); пользователь должен установить плагин устройства в кластере Поддерживается с плагинами устройства
Логи основного компонента Необязательно, по умолчанию отключено; Отправляются в AWS CloudWatch Необязательно, по умолчанию отключено; Отправляются в Azure Monitor Необязательно, по умолчанию включено; Отправляются в Stackdriver
Метрики производительности контейнера Необязательно, по умолчанию отключено; Отправляются в AWS CloudWatch Container Insights Необязательно, по умолчанию отключено; Отправляются в Azure Monitor ( предварительный просмотр ) Необязательно, по умолчанию включено; Отправляются в Stackdriver
Мониторинг узла Нет поддержки со стороны Kubernetes; в случае сбоя экземпляра узла группа автоматического масштабирования AWS пула узлов заменит его Нет Авто-восстановление узла включено по умолчанию

Комментарии

Интересно, что все три провайдера предлагают довольно унифицированный набор поддерживаемых версий Kubernetes, в дополнение, по крайней мере, некоторой степени поддержки некоторых более поздних функций Kubernetes, таких как контейнеры Windows и графические процессоры.

Наиболее заметное различие касается фактического управления, которое различные провайдеры делают для своих управляемых услуг. Здесь GKE явно играет ведущую роль, предлагая автоматические обновления для мастеров и узлов, а также обнаружение и исправление нездоровых узлов. Обновления EKS и AKS требуют, по крайней мере, некоторой степени ручной работы (или, запрограммированной клиентом автоматизации), особенно на EKS. Кроме того, ни EKS, ни AKS не предлагают какого-либо специализированного узла мониторинга состояния или восстановления. Клиенты AWS могут создавать настраиваемые проверки работоспособности для выполнения определенной степени мониторинга работоспособности узлов и автоматической замены клиентов для кластеров EKS, но AKS не предлагает сопоставимых функций для своих виртуальных машин.

Соглашения об уровне обслуживания для control plane управления Kubernetes также имеют некоторые удивительные различия. EKS остается единственным из трех провайдеров, которые берут за своих мастеров $ 0,10 / кластер / час. Эта сумма составит незначительную часть общей стоимости для всех, кроме самых маленьких кластеров, но обеспечивает то, что другие провайдеры не предлагают: SLA с финансовой ответственностью. Хотя возмещение штрафов за SLA почти никогда не сравнится с потерей потенциальной производительности или дохода, понесенного во время сбоя поставщика, предложение опубликованных штрафов может принести большую степень уверенности, в серьезности поставщика, надежности и времени безотказной работы.

Еще один интересный момент данных, а точнее его отсутствие, касается высокой доступности основных компонентов AKS. В документах Azure прямо не указано, использует ли AKS control plane управления кластером со встроенной избыточностью. Это очень любопытное упущение, потому что клиенты с собственными соглашениями об уровне обслуживания для своих приложений, размещенных на AKS, как правило, хотят и должны иметь возможность подтвердить, что сервисы и облачная инфраструктура, на которую они полагаются, также спроектированы для обеспечения аналогичной надежности.

Хотя узлы и ноды, работающие в кластере Kubernetes, могут пережить перебои control plane и ее компонентах, даже кратковременные прерывания могут быть проблематичными для некоторых рабочих нагрузок. В зависимости от затронутых компонентов плоскости управления сбойные модули могут не переноситься по расписанию или клиенты могут не иметь возможности подключиться к API кластера для выполнения запросов или управления ресурсами в кластере. Если кластер etcd, который используется control plane для хранения текущего состояния кластера и его развернутых ресурсов, дает сбой, теряет кворум (при условии, что он был развернут как кластер высокой доступности) или испытывает серьезное повреждение или потерю данных, кластер Kubernetes может стать невосстановимым.

Ограничения обслуживания

Лимиты на аккаунт (AWS), подписку (AKS) или проект (GKE), если не указано иное.

Лимиты, для которых клиент может запросить увеличение, отмечены звездочкой (*).

EKS AKS GKE Кубернетес (по состоянию на v1.17)
Максимально кластеров 100 / регион * 100 50 / зона + 50 региональных кластеров
Максимальное количество узлов в кластере Управляемые группы узлов: 1000 * (Формула: максимальное количество узлов на группу узлов * максимальное количество групп узлов на кластер)
  • 1000
  • 100 (наборы доступности VM)
  • 400 (сеть кубенет)
  • 800 (VM Scale Sets)
  • 5000
  • 1000 при использовании входного контроллера GKE
5000
Максимальное количество узлов на пул / группу узлов Группы управляемых узлов: 100 * 100 1000
Максимальное количество пулов / групп узлов в кластере Группы управляемых узлов: 10 * 10 Не задокументировано
Максимальное количество pods на узел
  • Linux: Зависит от типа экземпляра узла : ((количество IP-адресов на Elastic Network Interface — 1) * количество ENI) + 2
  • Windows: количество IP-адресов на ENI — 1
  • 110 (сеть кубенет)
  • 30 (Azure CNI, по умолчанию)
  • 250 (Azure CNI, максимально., Настраивается во время создания кластера)
110 100 (рекомендуемое значение, настраивается)

Комментарии

Хотя большинство из этих ограничений довольно просты, пара — нет.

В AKS абсолютное максимальное количество узлов, которое может иметь кластер, зависит от нескольких переменных, в том числе от того, находится ли узел в наборе состояний виртуальных машин или в наборе доступности, и использует ли сеть кластера kubenet или Azure CNI. Даже тогда еще не ясно, какое число имеет абсолютный приоритет для определенных конфигураций.

Между тем, в EKS планирование максимального количества модулей, которое может быть запланировано на узле Linux), требует некоторых исследований и расчетов. Кластеры EKS используют AWS VPC CNI для кластерной сети. Этот CNI размещает модули непосредственно в сети VPC с помощью ENI (Elastic Network Interfaces), виртуальных сетевых устройств, которые могут быть подключены к экземплярам EC2. Различные типы экземпляров EC2 поддерживают как разное количество ENI, так и разное количество IP-адресов (по одному на модуль) для каждого ENI.

Чтобы определить, сколько модулей конкретного типа экземпляра EC2 может работать в кластере EKS, вы должны получить значения из этой таблицы и вставить их в следующую формулу: ((# IP-адресов на Elastic Network Interface — 1) * # ENI ) + 2

Поэтому большой экземпляр EC2 c5.12x, который может поддерживать 8 ENI с 30 адресами IPv4 каждый, может вместить до ((30 — 1) * 8) + 2 = 234 модуля. Обратите внимание, что очень большие узлы с максимальным количеством запланированных модулей будут очень быстро поглощать блок CIDR / 16 IPv4 в кластере VPC.

Пределы модулей для узлов Windows легче вычислить, но они также намного более ограничены в количестве модулей, поддерживаемых в EKS. Здесь используйте формулу # IP-адресов для ENI — 1. Тот же экземпляр c5.12xlarge, который может запустить до 234 модулей в узле Linux, может выполнять только 29 модулей в качестве узла Windows.

Сетевая безопасностью

EKS AKS GKE Kubernetes
Сетевой плагин / CNI AWS VPC CNI Вариант между кубенетом или Azure CNI kubenet кубенет (по умолчанию; можно добавить CNI)
Kubernetes RBAC Требуется
  • Включено по умолчанию
  • Должен быть включен во время создания кластера
  • Включено по умолчанию
  • Может быть включен в любое время
Сетевая политика Kubernetes
  • Не включен по умолчанию
  • Calico можно установить вручную в любое время
  • Не включен по умолчанию
  • Должен быть включен во время создания кластера
  • kubenet: Calico
  • Azure CNI: Calico или политика Azure
  • Не включен по умолчанию
  • Может быть включен в любое время
  • Calico
  • Не включен по умолчанию
  • CNI, реализующий API сетевой политики, может быть установлен вручную
Поддержка PodSecurityPolicy Контроллер PSP установлен во всех кластерах с разрешающей политикой по умолчанию (v1.13 +) PSP может быть установлен в любое время ( предварительный просмотр ) PSP может быть установлен в любое время Контроллер доступа PSP должен быть включен как флаг kube-apiserver
Частный или публичный IP-адрес для кластера API Kubernetes
  • Общедоступный по умолчанию
  • Частный адрес необязательно
  • Общедоступный по умолчанию
  • Частный адрес необязательно ( предварительный просмотр )
  • Общедоступный по умолчанию
  • Частный адрес необязательно
Публичные IP-адреса для узлов
  • Неуправляемые группы узлов: необязательно
  • Группы управляемых узлов: обязательно
нет нет
Передача «от одного к другому», зашифрованная облаком нет нет нет нет
Межсетевой экран для кластера Kubernetes API Опция белого списка CIDR Опция белого списка CIDR Опция белого списка CIDR
Доступная только для чтения корневая файловая система на узле Не поддерживается Не поддерживается
  • COS: да
  • Ubuntu: нет
  • Windows: нет
Поддерживается

Комментарии

Сетевые и защитные функции и конфигурации кластеров Kubernetes часто тесно переплетаются, поэтому мы собрали их вместе.

В целом, EKS делает все возможное, чтобы основные средства контроля безопасности Kubernetes были стандартными в каждом кластере. И наоборот, AKS усложняет управление безопасностью, требуя включения RBAC и сетевых политик во время создания кластера.

Все три провайдера теперь развертывают с включенным по умолчанию RBAC Kubernetes, что является большой победой в части безопасности. EKS даже делает RBAC обязательным, как и для поддержки Pod Security Policy, которая, хотя и поддерживается двумя другими провайдерами, требует подписки для каждого кластера.

С другой стороны, ни один из провайдеров в настоящее время не включает поддержку сетевой политики по умолчанию. EKS требует от клиента установки и управления обновлениями для Calico CNI самостоятельно. AKS предоставляет два варианта поддержки сетевой политики, в зависимости от типа сети кластера, но позволяет включить поддержку только во время создания кластера.

Все три облака теперь предлагают несколько вариантов ограничения сетевого доступа к конечной точке API Kubernetes кластера. Даже с учетом RBAC в Kubernetes и включенного безопасного метода аутентификации для кластера, оставляя сервер API открытым для всего мира, он по-прежнему остается незащищенным от неизвестных или будущих уязвимостей, что было замечено совсем недавно в исправленной уязвимости Billion Laughs , которая создала возможность атаки отказа сервиса неаутентифицированными пользователями. Применение белого списка CIDR или предоставление API частного, внутреннего IP-адреса, а не публичного адреса, также защищает от таких сценариев, как взломанные учетные данные кластера.

EKS представила группы управляемых узлов на re: Invent в декабре прошлого года. Хотя группы управляемых узлов удаляют значительную часть предыдущей работы, необходимой для создания и обслуживания кластера EKS, они имеют определенный недостаток для безопасности сети узлов: все узлы в группе управляемых узлов должны иметь общедоступный IP-адрес и должны иметь возможность отправлять трафик из VPC. Эффективное ограничение выходного трафика от узлов становится более сложным. Хотя внешний доступ к этим общедоступным адресам может быть защищен с помощью надлежащих правил групп безопасности и сетевых ACL-списков, они по-прежнему представляют серьезный риск, если клиент неправильно настраивает или не ограничивает сетевые элементы управления VPC кластера. Этот риск можно несколько смягчить, разместив узлы только в частных подсетях.

Контейнерные образы сервисов

EKS AKS GKE
Служба репозитория образов ECR (реестр контейнеров Elastic) ACR (реестр контейнеров Azure) GCR (Реестр контейнеров Google)
Поддерживаемые форматы
  • Docker Image Manifest V2, схема 1
  • Docker Image Manifest V2, схема 2
  • Open Container Initiative (OCI)
  • Docker Image Manifest V2, схема 1
  • Docker Image Manifest V2, схема 2
  • Open Container Initiative (OCI)
  • Docker Image Manifest V2, схема 1
  • Docker Image Manifest V2, схема 2
  • Open Container Initiative (OCI)
Безопасность доступа
  • Разрешения, управляемые AWS IAM
  • Разрешения могут применяться на уровне хранилища
  • Конечная точка сети по умолчанию общедоступна
  • Конечная точка сети может быть ограничена определенными VPC
  • Разрешения, управляемые Azure RBAC
  • Может применяться на уровне хранилища ( предварительный просмотр )
  • Конечная точка сети по умолчанию общедоступна
  • Конечная точка сети может быть ограничена определенными виртуальными сетями ( предварительный просмотр )
  • Разрешения, управляемые GCP IAM
  • Разрешения могут применяться только на уровне реестра
  • Конечная точка сети по умолчанию общедоступна
  • Доступ к сети для реестров GCR может быть ограничен конкретными VPC с периметрами обслуживания.
Место хранения S3 buckets Не задокументировано GCS buckets
Безопасность хранения
  • Доступ к сегменту можно защитить с помощью разрешений S3 или AWS IAM.
  • Доступ к конечной точке базовой сети может быть ограничен определенными VPC
Не документировано (может не применяться)
  • Доступ к сегментам может быть защищен через GCP IAM, но некоторые разрешения применяются глобально ко всем сегментам в проекте.
  • ACL могут использоваться для управления разрешениями для отдельных объектов сегмента. ( GCR не учитывает ACL объекта GCS, только разрешения bucket. )
  • Доступ к сети может быть ограничен с использованием периметра обслуживания
Поддерживает подпись образа нет да нет
Поддерживает неизменяемые теги образов да нет нет
Сервис сканирования образов Да ; Только пакеты ОС Да ( превью ); неясно, включены ли библиотеки языка приложений во время выполнения Да ; Только пакеты ОС
Реестр SLA 99,9%; финансовая ответственность 99,9%; финансовая ответственность Неизвестно

Комментарии

Все три облачных провайдера предлагают аналогичные услуги по регистрации образов контейнеров. Добавление в ACR поддержки подписи образов позволяет пользователям устанавливать и подтверждать подлинность и целостность своих образов. Поддержка ECR для неизменяемых тегов образов помогает пользователям полагать, что использование одного и того же тега image: приведет к развертыванию одной и той же сборки образа контейнера каждый раз.

Все три службы реестра также допускают некоторую степень контроля доступа. Однако степень контроля варьируется. ECR и ACR поддерживают ограниченный контроль доступа к уровню хранилища, который не поддерживается GCR. Кроме того, поскольку управление доступом к реестру GCR напрямую зависит от разрешений для bucket Google Cloud Storage, поддерживающей этот реестр, ограничение доступа к корзине хранения с помощью периметра службы может нарушить доступ к bucket GCS в других проектах GCP , в том числе с другой стороны.

Примечания о данных и источниках

Информация в этом посте должна рассматриваться снимком этих сервисов Kubernetes на момент публикации. В частности, поддерживаемые версии Kubernetes будут регулярно меняться. Функции, которые в настоящее время находятся в режиме предварительного просмотра (терминология Azure) или бета-версии (терминология GCP), помечены как таковые и могут измениться, прежде чем станут общедоступными. В настоящее время AWS не имеет соответствующих функций предварительного просмотра, перечисленных в их документации EKS.

Все данные в таблицах взяты из официальной онлайн-документации поставщика (kubernetes.io в случае Kubernetes с открытым исходным кодом), которая в некоторых случаях дополняется проверкой запущенных кластеров и запросами API служб. Часть этой информации, особенно для поддерживаемых версий Kubernetes, может относиться к регионам США; доступность может отличаться в других регионах. Значения для Kubernetes с открытым исходным кодом опускаются, если они либо относятся к управляемой службе, либо зависят от того, как и где развернут самоуправляемый кластер.

Мы также не пытаемся сравнивать цены в большинстве случаев. Цены на ресурсы, даже для одного поставщика, могут сильно отличаться в зависимости от региона, и даже если мы придумали стандартный размер кластера выборки и рабочую нагрузку, соотношения затрат могут быть не пропорциональны для другой конфигурации. В частности, обратите внимание, что некоторые дополнительные функции, такие как ведение журнала, конечные точки частных сетей для служб и сканирование образов в контейнерах, могут повлечь дополнительные расходы в некоторых облаках.

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

Если вам нужны точные цифры, выполнение ваших собственных тестов для сравнения различных вычислений, хранилищ и сетевых параметров каждого провайдера, в дополнение к тестированию со стеком приложений, обращайтесь [email protected]