Контейнерные сервисы: ECS, EKS, GKE

2013 год, Docker 0.1. За неделю - тысячи звёзд на GitHub. Но запустить контейнер на ноутбуке и управлять тысячами контейнеров на сотнях серверов - это два разных вида работы. Amazon, Google и Microsoft потратили миллиарды, чтобы вторая задача не требовала отдельной команды в каждом стартапе.

• Netflix запускает тысячи сервисов через Amazon ECS и EKS - каждый rolling deployment без даунтайма управляется оркестратором
• Spotify перешёл на GKE в 2016 году и сократил время деплоя с 2 часов до 10 минут за счёт автоматизации управления контейнерами
• Airbnb использует Kubernetes для изоляции workload'ов: ML-пайплайны, API-серверы и batch-задачи делят одни узлы, не мешая друг другу

Проблема оркестрации: 1000 серверов

2013 год. Docker выпустил 0.1. За неделю GitHub засыпало звёздами. Разработчики получили новое: "работает на моём ноутбуке" наконец совпало с "работает в проде".

Но потом пришла реальность. Один контейнер запустить легко. А если их 5000 - на 300 серверах, с балансировкой трафика, health checks, rolling deployments, автомасштабированием под нагрузкой? Кто рестартует упавший контейнер в 3 ночи? Кто решает, на какой сервер положить следующий инстанс, чтобы не перегрузить хост?

**Оркестратор контейнеров** - система, которая автоматически размещает контейнеры по кластеру серверов, следит за их работоспособностью и масштабирует их количество под нагрузку.

Google решил эту проблему ещё в 2003 году - внутри у них был Borg, система управления рабочими нагрузками. За 10 лет они запустили через Borg миллиарды контейнеров. В 2014 году выпустили его публичную версию под именем Kubernetes.

Kubernetes быстро стал стандартом. Настолько быстро, что у каждого облачного провайдера появилась собственная managed-версия. AWS - EKS. Google - GKE. Azure - AKS. А AWS ещё и создал собственный оркестратор ECS - проще, чем K8s, но глубоко интегрированный в экосистему AWS.

AWS ECS: задачи, сервисы, кластеры

ECS - Elastic Container Service - это AWS-й ответ на вопрос "как запускать контейнеры, не изучая Kubernetes". Концепция простая, но словарь специфичный.

Три уровня абстракции ECS

**Task Definition** - это рецепт: какой образ запускать, сколько CPU и памяти нужно, какие переменные окружения, какие порты пробросить. Похоже на `docker run` флаги, но в JSON-формате. Одна Task Definition может порождать много запущенных Tasks.

**Task** - запущенный контейнер (или группа контейнеров), инстанс Task Definition. Задача выполняется и завершается - например, batch-обработка файла.

**Service** - механизм поддержания N запущенных копий Task. Если один контейнер упал - Service поднимет новый. Если нагрузка выросла - можно настроить Auto Scaling. Именно Services используются для stateless API и веб-серверов.

**Cluster** - логическое пространство, в котором живут Tasks и Services. Кластер не несёт серверов сам по себе - он лишь группирует ресурсы.

Fargate vs EC2 launch type

Это главный выбор при использовании ECS. **EC2 launch type**: AWS запускает Task на EC2-инстансах, которые находятся в вашем аккаунте. Нужно самому выбирать тип инстансов, управлять их количеством, патчить ОС. Больше контроля - больше забот.

**Fargate**: серверов не видно вообще. Описываешь Task - нужно 0.5 vCPU и 1 GB памяти. AWS сам находит где это запустить, изолирует на уровне VM, выставляет счёт поминутно. Оверхед на управление инфраструктурой - ноль.

Fargate дороже per-CPU-hour, чем EC2, но дешевле с учётом операционных расходов на управление узлами. Большинство новых сервисов стартуют на Fargate и переходят на EC2 только при специфических требованиях к производительности или стоимости.

OpenAI, Airbnb, Samsung - все они используют ECS или EKS в продакшне. Когда ChatGPT принимает запросы от 100 миллионов пользователей, за балансировкой трафика стоит именно такая инфраструктура: сотни Task Definition, тысячи запущенных Tasks, Auto Scaling который добавляет контейнеры быстрее, чем приходит трафик.

EKS, GKE и выбор managed K8s

Kubernetes - это не продукт, это стандарт. API одинаковый везде: Pod, Deployment, Service, Ingress. Разница между EKS, GKE и AKS - в том, что именно управляет control plane и насколько глубоко интегрирован с остальной облачной инфраструктурой.

EKS: Kubernetes на AWS

**Amazon EKS** запускает managed control plane - etcd, kube-apiserver, kube-scheduler, controller manager - на инфраструктуре AWS. Стоит это около 0.10 USD в час за кластер, плюс оплата рабочих узлов. Worker nodes - либо EC2, либо Fargate (тот же Fargate, что в ECS, только управляемый через K8s API).

EKS глубоко интегрирован с AWS: IAM через IRSA (IAM Roles for Service Accounts), Load Balancer через AWS Load Balancer Controller, хранилище через EBS/EFS CSI drivers. Если вся инфраструктура уже на AWS - EKS естественный выбор.

GKE Autopilot: Kubernetes без узлов

Google придумали GKE Autopilot - радикальный подход. Обычный GKE: управляешь node pool'ами, типами машин, количеством узлов. GKE Autopilot: узлов нет вообще. Описываешь Pod - Google выделяет под него ресурсы автоматически. Платишь только за запрошенные Pod'ами ресурсы, не за простаивающие узлы.

GKE Autopilot - это ответ Google на Fargate. Аналогичная идея: убрать из поля зрения инфраструктурный слой, оставить только workload-абстракцию. Google сделал это на уровне Kubernetes API, а не собственного оркестратора.

Managed vs self-managed: как выбирать

Self-managed Kubernetes (kubeadm, k3s, RKE2 на собственных серверах или bare-metal) имеет смысл в трёх случаях: специфические требования к безопасности (государственный сектор, финансы с air-gap требованиями), нестандартное железо (GPU-кластеры с особой топологией), или масштаб когда экономия на managed fee окупает команду SRE.

В остальных случаях счёт не в пользу self-managed. Control plane - сложная распределённая система: etcd требует тщательного бэкапа, обновления K8s - ювелирная работа, zero-downtime upgrade кластера из 200 узлов требует опытной команды. Managed-сервис снимает эту проблему за фиксированную плату.

Kubernetes scheduler - это bin packing solver: разместить N контейнеров на M узлах с учётом ресурсных запросов, affinity правил и taint/toleration. Та же задача, которую решает SGD при batch allocation в распределённом обучении - распределить вычислительную нагрузку оптимально по доступным ресурсам.

Ключевые идеи

• **ECS** - AWS-й оркестратор с тремя абстракциями: Task Definition (рецепт), Task (запущенный инстанс), Service (поддержание N копий)
• **Fargate** - serverless-слой для ECS и EKS: описываешь ресурсы контейнера, AWS сам выделяет инфраструктуру и поминутно выставляет счёт
• **EKS и GKE** - managed Kubernetes: control plane управляет провайдер, рабочие узлы - в вашем аккаунте (или вообще невидимы в GKE Autopilot)
• **Self-managed K8s** оправдан только при air-gap требованиях, специфическом железе или масштабе, где экономия превышает стоимость SRE-команды

Связанные темы

Оркестрация контейнеров - узловая точка облачной архитектуры, связанная с несколькими направлениями:

• Контейнеры и Docker — Базовая технология, которую оркестрируют ECS/EKS/GKE
• Serverless (Lambda) — Альтернативный подход к абстракции инфраструктуры
• Микросервисы в облаке — Типичный workload, для которого используют контейнерные сервисы
• Распределённые системы — Теоретическая основа для понимания K8s scheduler и consensus в etcd

Вопросы для размышления

• Когда имеет смысл использовать ECS вместо EKS, если оба работают на AWS?
• Fargate дороже EC2 на 20-30% по стоимости vCPU-hour. При каком сценарии Fargate всё равно выгоднее?
• Что происходит с запущенными контейнерами в ECS Service, если нода EC2 неожиданно падает?

Связанные уроки

• cloud-02 — Контейнеры и Docker - базис для оркестрации
• cloud-05 — Serverless и контейнеры - два полюса PaaS-спектра
• cloud-19 — Микросервисы в облаке строятся поверх ECS/EKS/GKE
• ds-01-intro — Распределённые системы - теоретическая основа K8s scheduler
• devops-04