Пока мы разрабатываем и запускаем своё приложение в Docker Desktop, всё довольно просто и понятно, но, когда приходит время разворачивать его в облаке, вопросов становится существенно больше. Развёртывание даже простого приложения из нескольких контейнеров приходится планировать заранее. Поэтому сегодня мы на примере Amazon Web Services разберем, какие есть варианты для запуска контейнеризированных приложений в облаке и (спойлер!) настроим кластер Kubernetes в AWS двумя разными способами.
Информация актуальна для тех, у кого уже есть подписка на сервисы AWS и для тех, кто верит, что ограничения на подписку новых пользователей не продлятся слишком долго.
Выбираем систему оркестрации
Арендуем сервер, ставим ОС и весь необходимый софт, а затем в него вручную переносим все наши контейнеры, используя виртуальные машины Amazon Elastic Compute Cloud (EC2). Такое решение будет хорошо работать, особенно, если вы прошли курс Kubernetes The Hard Way и хотите применить всё увиденное в реальном проекте. Запретить вам делать это, конечно, невозможно, но, если это ваш первый проект, советую повременить и понабивать шишки в тестовых средах или с какими-нибудь некритичными приложениями. Плюс, выбрав такой путь, мы лишаемся всех бонусов облака. Это будет такая креативная колокация, только сервер вы не купили и принесли в центр обработки данных (ЦОД), а взяли в аренду.
Дальнейший план наших действий будет зависеть от того, какую систему оркестрации мы выберем. В AWS их, по сути, две:
ECS (Elastic Container Service) – собственная разработка Amazon;
EKS (Elastic Kubernetes Service) – Kubernetes, адаптированный под AWS.
Конечно, систем оркестраций в природе существует куда больше: Swarm, Mesos, Nomad, Rancher, «Ваша_любимая_система», но в AWS, если не брать вариант с простым EC2, мы выбираем фактически между ECS и EKS. Особняком стоит OpenShift, но это история для отдельной статьи.
Также вы можете встретить упоминание ECR – Elastic Container Registry, но это просто хранилище образов контейнеров, похожее на Docker Hub, Harbor, Nexus и т.п. Это не принципиально, но нужно учитывать, что ECR – часть экосистемы AWS, а значит интегрировать его с EKS будет несколько проще и, возможно, дешевле.
Почему мы вообще говорим о системе оркестрации? Потому, что, если контейнеров у вас больше одного, вам потребуется инструмент, который будет управлять их запуском, масштабированием и прочими ежедневными задачами.
Как не ошибиться с выбором – смотрим на схеме:
Выбираем хостинг
После того, как вы определились с системой оркестрации, нужно выбрать тип хостинга. Есть два варианта:
В случае использования ECS с EC2 умный AWS сам поднимет необходимое количество виртуальных машин EC2, запустит на них необходимые сервисы:
среду запуска контейнера,
ecs-агент (для связи с control plane), а затем и ваши контейнеры.
Control plane окажется в зоне ответственности AWS, но вот управление виртуальными машинами EC2 ложится на ваши плечи. Вы будете их видеть в консоли и сможете к ним подключиться, как к любой другой виртуальной машине, а в процессе работы добавлять или удалять дополнительные EC2 машины.
Если у нас есть желание отдать под управление AWS не только control plane, но и виртуальные машины, на которых будут запускаться контейнеры, то можно воспользоваться службой Fargate. В этом случае в конcоли AWS вы увидите не конкретные EC2 машины, а только количественные показатели задействованных ресурсов. Fargate анализирует параметры вашего контейнера: сколько ему нужно памяти, ядер, дискового пространства – и затем представляет серверные мощности под ваш конкретный запрос.
При этом, к серверу доступа вы не имеете. Это удобно, если у вас нет возможности или желания тратить время и силы на управление виртуальными серверами. Кроме этого, вы заплатите только за те ресурсы, которые используете, а когда потребуется масштабировать решение, вы легко сможете это сделать. Тогда как в варианте с EC2 придётся заплатить за всю виртуальную машину.
ECS довольно хорошо интегрируется с другими сервисами AWS: IAM, балансировка, cloudwatch и т.п. Однако, хорошо это или плохо, но стандартом оркестрации де-факто сейчас является Kubernetes, поэтому и в AWS есть своя реализации этого решения под названием EKS.
Выбираем между EKS и ECS
EKS и ECS обе управляют control plane, однако есть несколько важных отличий. При выборе между ними нужно учитывать следующее:
ECS:
проста в настройках и подойдет для более простых приложений или самого начала работы с контейнерами;
скорее всего, выйдет дешевле;
работает только в AWS, а значит, миграция в ECS будет проблематичной;
если вам что-то не понравится, то мигрировать куда-то ещё будет так же сложно.
EKS:
использует тот же API, что и любой другой K8s, и если вы уже имели опыт работы с ним, то не придётся изучать всё с нуля;
open source! (Мы же всё ещё любим open source?);
относительно легко будет мигрировать с аналогичных решений в Google cloud, Azure или Digital ocean, потому что там ровно такой же K8s;
общая распространённость решения тоже важный момент, есть у кого спросить, если что-то пойдёт не так.
Детали ясны, но чем конкретно EKS лучше обычного bare metal варианта?
Во-первых, EKS за вас развернет control plane со всеми необходимыми сервисами, которые есть на Master Node. Ответственных за миграцию специалистов можно будет обрадовать – Kubernetes the hard way пока можно отложить до лучших времён.
Во-вторых, созданные таким образом Master Node (т.е. каждый ее компонент) будет реплицироваться через зоны доступности в вашем выбранном регионе, а это значит обеспечит высокую доступность и отказоустойчивость из коробки. Это крайне удобно, потому что обеспечение отказоустойчивости Kubernetes – не такая простая задача, как может показаться на первый взгляд: к каждому сервису control plane требуется свой подход.
Обеспечиваем отказоустойчивость
Итак, как будем обеспечивать отказоустойчивость? К Master Node нужно подключить Worker Node, где будут запускаться ваши контейнеры, на этом этапе опять появляется несколько вариантов. Worker Node – это обычные EC2 серверы, которые вы подключите к Master Node, как это делается на любом другом кластере Kubernetes.
Первый вариант — это использовать обычные EC2 виртуальные машины, которые мы будем сами устанавливать, обновлять и управлять.
Второй — так называемые Nodegroup, которые за вас будут создавать и удалять конкретные инстансы EC2 в зависимости от потребностей, а также устанавливать туда необходимые компоненты для работы с Kubernetes, но конфигурировать их придётся всё равно вам.
Третий вариант – это использовать Fargate, аналогично тому, как это было предложено в ECS. В этом случае, всю заботу о выделении ресурсов возьмет на себя AWS.
При этом важно помнить, что на каком-то одном варианте в случае EKS останавливаться не придётся. Какие-то контейнеры можно запускать на EC2, а какие-то в Fargate.
Вариант развёртывания предстоит выбирать архитектору системы самостоятельно. Каждый из них, как мы видим имеет свои достоинства и недостатки. В следующий статье мы рассмотрим, как разворачивать простой кластер Kubernetes на базе EKS.
Несмотря на то, что сервисы AWS пользуются большой популярностью благодаря обширному набору функций и сравнительной простоте развертывания, если вы временно не можете воспользоваться именно AWS, на отечественном рынке есть ряд альтернатив, например, ЯндексCloud, SberCloud, Облако Selectel, Облако Mail, которые можно использовать вместо AWS в ряде случаев. У вас есть опыт запуска контейнеров на одном из отечественных аналогов? Было бы интересно прочитать, как это делать на одном из упомянутых сервисов?
Материал подготовил руководитель группы защиты инфраструктурных ИТ-решений компании «Газинформсервис» Сергей Полунин, блог Сергея можно почитать по ссылке.
