Вчера компания Amazon Web Services объявила о полноценном запуске своего облачного сервиса на базе Kubernetes — EKS (Amazon Elastic Container Service for Kubernetes). Впервые он был анонсирован в ноябре прошлого года (вскоре после того, как AWS присоединилась к стоящему за Kubernetes фонду CNCF), но тогда он имел статус предварительного доступа. Что скрывается за EKS?


Amazon EKS — это готовый к использованию Kubernetes, развёрнутый и управляемый в облачном окружении AWS. Можно говорить о EKS как о managed service (или hosted service). Этот рынок (для Kubernetes) достаточно нов, однако он уже значительно шире, чем всем известные Google Kubernetes Engine (GKE) и Azure Kubernetes Service (AKS), т.к. насчитывает как минимум более десятка официально «задокументированных» предложений от крупных и не очень ИТ-компаний (включая Red Hat, IBM, Oracle, Pivotal и т.п.).

Как и в прошлый раз, в анонсе Amazon с особой гордостью отмечается, что (по официальной статистике CNCF) «AWS является ведущим окружением для Kubernetes», поскольку 57 % из компаний, использующих Kubernetes, размещают свои кластеры в облаке Amazon. Эти данные — результат опроса более 550 представителей сообщества Kubernetes, посетивших конференцию KubeCon + CloudNativeCon North America (в декабре 2017 года). Подобные цифры в CNCF регулярно получают на своих крупных мероприятия, и процент AWS стабильно растёт. Стоит только уточнить, что этот процент — результат множественной выборки (т.е. те же пользователи K8s в своём большинстве одновременно работают и с другими платформами).

Ключевые фичи в EKS, как и стоило ожидать, относятся к интеграции с другими облачными сервисами/возможностями AWS. Вот их список:

1. Multi-AZ — высокая доступность Kubernetes control plane (точнее, kube-apiserver и etcd), который и является собственно hosted, т.е. размещённым на мощностях AWS и обслуживаемым автоматически: узлы сами замещаются в случае падений, а также автоматически патчатся/обновляются. Доступность же достигается благодаря распределённости control plane по трём Availability Zones в AWS.
2. Использование Heptio Authenticator для аутентификации, что обеспечивает интеграцию с AWS Identity and Access Management (т.е. можно использовать роли из IAM).
3. Поддержка разных способов балансировки нагрузки для маршрутизации трафика: AWS Network Load Balancer, AWS Application Load Balancer, Elastic Load Balancer.
4. Использование томов Amazon Elastic Block Store (EBS) для хранения данных в Kubernetes (PersistentVolumes).
5. Возможность использования DNS-записей из Route 53 для сервисов, размещённых в кластерах Kubernetes.
6. Поддержка автомасштабирования — AWS Auto Scaling.
7. Плагин к CNI для использования сетевых интерфейсов Elastic Network Interfaces в кластерах.

Среди прочих интеграций EKS с сервисами AWS можно отметить поддержку AWS PrivateLink и AWS CloudTrail (для логов).

В FAQ проекта заявляется, что в сервисе запущена «последняя версия Open Source-версии Kubernetes, благодаря чему вы можете использовать все существующие плагины и инструменты от сообщества Kubernetes». В другом вопросе уточняется, что на данный момент поддерживается только версия Kubernetes 1.10.

В простейшей детализации авторы так представляют архитектуру EKS:



А так — алгоритм использования EKS:



Как же всё-таки попробовать EKS в действии, можно увидеть из анонса Amazon EKS, где приводится пошаговая инструкция (со скриншотами) по созданию кластера Kubernetes, а также в документации AWS — там подготовлен 30-минутный tutorial «Deploy a Kubernetes Application».

На данный момент Amazon EKS доступен только для американских регионов US East (N. Virginia) и US West (Oregon), а его распространение на другие ожидается «очень скоро», хотя в таблице сервисов по регионам этой услуги пока нет.

Наконец, в Amazon утверждают, что вносят изменения в upstream кодовой базы самого Kubernetes и связанных проектов (включая упомянутый Heptio Authenticator, а также Virtual Kubelet). Однако в этом случае статистика явно не на их стороне: среди сколь-нибудь значимых лидеров по числу коммитов в кодовую базу Kubernetes компании нет. С другой стороны, один только этот факт позволяет спокойно реагировать на прогнозы о будущем Kubernetes вроде этого.