EKS vs GKE vs AKS - оценка Kubernetes в облаке

Теперь, когда 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 года.

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

Комментарии

Интересно, что все три провайдера предлагают довольно унифицированный набор поддерживаемых версий 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), если не указано иное.

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

Комментарии

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

В 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.

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

Комментарии

Сетевые и защитные функции и конфигурации кластеров 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 кластера. Этот риск можно несколько смягчить, разместив узлы только в частных подсетях.

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

Комментарии

Все три облачных провайдера предлагают аналогичные услуги по регистрации образов контейнеров. Добавление в 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]