Блог Amazon Web Services

Переезд с самостоятельно развёрнутого Kubernetes на Amazon EKS: что следует принять во внимание

Оригинал статьи: ссылка (Matheen Raza, Business Development Manager; Aaron Miller, Senior Specialist Solutions Architect)

Введение

Мы каждый день общаемся с заказчиками, которые либо планируют миграцию на Amazon Elastic Kubernetes Service (Amazon EKS), либо уже находятся в процессе такой миграции. Иногда они начинают работу с Kubernetes, развернув его самостоятельно, но по мере увеличения количества рабочих нагрузок управление самой платформой Kubernetes становится всё более обременительным. В какой-то момент самостоятельное управление Kubernetes приводит к значительным операционным издержкам, которые не направлены на улучшение основных бизнес-приложений, а только отнимают у них необходимые людские ресурсы. По этой причине многие заказчики предпочитают передать задачу по управлению Kubernetes в AWS. Вот несколько причин, почему наши клиенты переезжают на Amazon EKS:

  • Управляемый control plane: поддержка высокодоступного control plane (или плоскости управления) для приложений в промышленной эксплуатации – это сложная задача. Наши заказчики часто замечают, что при росте количества рабочих нагрузок необходимые для этого трудозатраты отвлекают их от внедрения новой функциональности в основные бизнес-приложения.
  • Безопасность и соответствие требованиям: некоторые заказчики работают в регулируемых индустриях, и им необходима сертифицировать свои среды по таким стандартам как FedRAMP, HIPPA, PCI и другим. EKS полностью сертифицирован и соответствует требованиям этих стандартов, поэтому клиентам не нужно дополнительно проходить аудит control plane по ним.
  • Стоимость: клиенты, использующие Amazon EKS, платят за час работы кластера $0.10 (USD). Как правило, это меньше, чем потребуется на запуск высокодоступного и отказоустойчивого control plane на инстансах EC
  • Масштабируемость: используя глобальные масштабы AWS, заказчики могут развёртывать приложения и масштабировать их в соответствии со своими требованиями. Кроме того, по мере роста кластера, control plane в EKS будет соответствующим образом масштабироваться динамически.
  • Различные виды вычислительных мощностей: EKS предлагает два способа для развёртывания управляемых узлов в кластере. Заказчики могут выбрать управляемые группы узлов (managed node groups), в которых AWS управляет жизненным циклом рабочих узлов внутри VPC заказчика, либо AWS Fargate, который является сервисом для бессерверного запуска контейнеров. Управляемые группы узлов в EKS поддерживают различные способы запуска и архитектуры: например, спотовые инстансы, а также инстансы на базе Graviton и AMD. Они позволяют выбрать наиболее оптимизированные по цене вычислительные мощности для каждой рабочей нагрузки.
  • Надёжность и доступность: Amazon EKS предоставляет SLA в 99.95% времени безотказной работы. Для того чтобы добиться этого, control plane запускается в нескольких зонах доступности AWS, а сервис EKS автоматически обнаруживает и заменяет неработающие узлы в control plane и обеспечивает возможность запуска обновлений по требованию, которые осуществляются без простоев.

Итак, мы рассмотрели основные преимущества, а может быть, вы их уже знали, и теперь вы готовы к миграции рабочих нагрузок на Amazon EKS. На самом деле, такая миграция относительно проста. В Amazon EKS используются версии основной ветки разработки Kubernetes, поэтому если ваши приложения работают в Kubernetes, они также должны работать в Amazon EKS. Однако есть несколько отличий в архитектуре и реализации, которые вам необходимо изучить и заранее принять во внимание.

Планирование

Помимо планирования самого процесса миграции и учёта дополнительных зависимостей, есть несколько технических аспектов, которые клиенты должны предусмотреть, чтобы избежать неожиданностей во время миграции. Как мы уже упоминали, EKS использует основную версию Kubernetes, поэтому приложения, работающие на Kubernetes, должны работать на EKS без каких-либо изменений. Вот несколько ключевых технических аспектов, которые необходимо учесть во время миграции.

  • Версии Kubernetes: чтобы избежать любых несоответствий в API, планируйте миграцию рабочих нагрузок на ту же версию Kubernetes в EKS, которая используется в настоящий момент. Если вы используете версию, которая не поддерживается EKS, то обновления ваших существующих кластеров до актуальных версий Kubernetes может отнять много времени и, возможно, не требуется. В таком случае важно проверить список изменений, выявить устаревшие API и перестать использовать их после миграции.
  • Безопасность:
    • Аутентификация: EKS поддерживает интеграцию с IAM, в которой (1) пользователь или роль, которая создала кластер изначально, получает к нему полный администраторский доступ и (2) доступ другим пользователям и ролям предоставляется через ConfigMap aws-auth. Вы также можете предоставлять доступ к кластеру EKS с помощью аутентификации через провайдера идентификации OpenID Connect (OIDC), затем использовать Role и ClusterRole в Kubernetes, чтобы назначить права доступа на роль, и в конце привязать эти роли к учётным записям с помощью RoleBinding и ClusterRoleBinding.
    • Роли IAM для сервисных аккаунтов: приложениям в Kubernetes часто требуется доступ к AWS API, чтобы создавать новые ресурсы или работать с уже созданными. Для этого им необходимо предоставить соответствующие права доступа. Один из важнейших принципов безопасности – это принцип наименьших привилегий (least privilege principle). С помощью ролей IAM вы можете ограничить предоставление прав доступа для определённого сервисного аккаунта и пода, который этот аккаунт использует.
  • Сеть:
    • VPC CNI: Amazon EKS использует Amazon VPC CNI для работы с сетевыми возможностями VPC. VPC CNI назначает подам такой же IP-адрес внутри Kubernetes, какой они получают в самом VPC, что повышает прозрачность и возможности по мониторингу и отладке.
    • AWS Load Balancer Controller: для использования различной новой функциональности и возможностей тонкой настройки AWS предоставляет AWS Load Balancer Controller. Он поддерживает работу не только с сервисами Kubernetes, но и с ресурсами ingress и позволяет вам создавать балансировщики нагрузки Application Load Balancer (ALB) для веб-приложений.
  • Хранение данных
    • CSI-драйверы EBS/EFS/FSx: Kubernetes поддерживает рабочие нагрузки с сохранением состояния (stateful) с помощью ресурсов PersistentVolume (PV) и PersistentVolumeClaim (PVC). Изначально интеграция с сервисами для хранения данных Elastic Block Store (EBS) и Elastic File System (EFS) в Kubernetes была реализована с помощью Volume Plugin. Однако при таком подходе любые исправления и улучшения требовали внесения изменений в основную версию Kubernetes, что приводило к увеличению времени, требуемого для обновления. Для устранения этого недостатка был создан Container Storage Interface (CSI), который позволяет обновлять драйверы для систем хранения данных независимо от обновлений Kubernetes. AWS поддерживает CSI-драйверы для EBS, EFS и FSx for Lustre. В зависимости от ваших требований вы можете выбрать один из указанных сервисов для сохранения состояния ваших рабочих нагрузок.

Тестирование

Как правило, наши заказчики вначале тестируют работу самих приложений на новом кластере EKS, чтобы убедиться, что они работают корректно. Так как EKS сертифицирован как Kubernetes Conformant, вы можете быть уверены, что ваши приложения используют такие же API, как и в Kubernetes с открытым исходным кодом. После этого заказчики обычно тестируют интеграцию с инструментами от других вендоров, либо инструментов с открытым исходным кодом, чтобы убедиться, что их версии совместимы с EKS. Наконец, если требуется, заказчики проводят нагрузочное тестирование, чтобы понять, как EKS обрабатывает их паттерны пиковых нагрузок и масштабируется в соответствии с их требованиями. Кроме того, мы рекомендуем провести аудит безопасности и Well Architected Review, чтобы убедиться, что все настройки соответствуют лучшим практикам, а угрозы безопасности отсутствуют.

В это же время имеет смысл рассмотреть используемые инструменты, а также лучшие практики AWS по конфигурации кластера. Например, одна из них – это автоматизация как можно большего количества операций. Для развёртывания кластера распространённой практикой является подход «инфраструктура как код» (Infrastructure as Code, IaC), и здесь в EKS существует несколько вариантов:

  1. CloudFormation – это популярное решение, предоставляемое AWS, которым пользуются многие наши заказчики.
  2. eksctl – это официальные инструменты командной строки для EKS, которые позволяют описать конфигурацию в декларативном формате и используют CloudFormation для развёртывания кластера.
  3. AWS Cloud Development Kit (CDK) позволяет использовать возможности знакомых языков программирования для описания инфраструктуры.
  4. Решения от сторонних вендоров, например, Terraform, также хорошо подойдут для этой задачи.

После автоматизации создания кластера EKS вы можете использовать CI/CD-конвейер, чтобы разворачивать и тестировать ваши приложения на новом кластере.

Миграция

Есть несколько стратегий миграции. Иногда заказчики предпочитают создать резервную копию кластера, а затем восстановить её в новом кластере. Некоторые из них используют для резервного копирования решения от сторонних вендоров, таких как Velero и Druva. В других случаях заказчики просто перенаправляют свои CI/CD-конвейеры на новый кластер EKS.

Последний этап – это переключение и перевод конечных пользователей на новый кластер: вы можете использовать подход blue-green deployment и маршрутизацию по весам в Route 53 или любом другом решении для управления трафиком, чтобы постепенно перенести весь объём запросов на новый кластер и отключить старый.

Заключение

В этой статье мы рассмотрели высокоуровневую стратегию миграции. В каждом конкретном случае её необходимо согласовать с потребностями самой организации. Мы считаем, что Amazon EKS предлагает лучший опыт работы с Kubernetes для компаний, которые запускают рабочие нагрузки в больших масштабах. При тщательном планировании можно уменьшить риски и перенести приложения без влияния на рабочие нагрузки в промышленной среде. Наши заказчики, такие как New Relic, запланировали и успешно завершили миграцию приложений за короткий промежуток времени. С помощью EKS такие клиенты как Snap, Lyft, HSBC и Delivery Hero передали трудоёмкую задачу по управлению кластерами Kubernetes в AWS и смогли сосредоточиться на обеспечении наилучшего опыта для своих пользователей.