Миграция с Kubernetes на AWS ECS Fargate: снижаем сложность и расходы через AWS CDK
Применение кластеров Kubernetes стало стандартом индустрии для масштабируемых микросервисных архитектур. Однако для инженеров и небольших команд эксплуатация полноценной платформы оркестрации часто превращается в источник постоянных накладных расходов. Время, которое должно тратиться на развитие продуктовой логики, уходит на обновление узлов, настройку Ingress-контроллеров, отладку CNI-сетей и управление контроллерами ресурсов.
Практический опыт миграции сервиса NetworkLessons демонстрирует, как замена Kubernetes на бессерверный контейнерный оркестратор AWS ECS Fargate в сочетании с декларативным описанием инфраструктуры через AWS CDK позволяет кардинально упростить эксплуатацию и одновременно ужать финансовые затраты на облачную инфраструктуру.
Накладные расходы на обслуживание Kubernetes в небольших продуктах
При внедрении Kubernetes команды рассчитывают получить универсальную платформу для быстрого развертывания. На практике происходит обмен сложности приложений на сложность инфраструктуры. В случае компактных продуктов с небольшим штатом инженеров эксплуатационная нагрузка кластера быстро перевешивает его преимущества:
- Необходимость регулярного обновления управляющих компонентов Control Plane и рабочих узлов Worker Nodes для закрытия уязвимостей безопасности.
- Выделение постоянных вычислительных ресурсов под системные компоненты (Infrastucture Pods, DaemonSets, системы мониторинга, сбора логов и CNI-плагины).
- Сложность описания развертываний через разрозненные YAML-манифесты или сложные Helm-чарты, требующие отдельной экспертизы.
- Финансовая неэффективность поддержания постоянно запущенных нод для тестовых сред и задач обработки по расписанию.
Переход на управляемые бессерверные контейнеры полностью снимает необходимость администрирования виртуальных машин, перекладывая задачи патчинга операционных систем и базового масштабирования узлов на инфраструктуру облачного провайдера.
Изоляция окружений через мультиаккаунтную модель AWS
В процессе миграции была фундаментально пересмотрена архитектура облачных учетных записей. Вместо запуска продуктовой и тестовой сред в разных пространствах имен (namespaces) одного кластера Kubernetes была внедрена строгая изоляция на уровне отдельных аккаунтов AWS Organization:
- Продуктовый аккаунт (
Production Account): содержит изолированные контейнеры ECS Fargate, базы данных Aurora PostgreSQL и критические хранилища S3. - Тестовый аккаунт (
Staging Account): служит для полноценной проверки изменений перед релизом и изолирован от продуктовой сети. - Управляющий аккаунт (
Management Account): содержит централизованное управление DNS-зонами в Route53, безопасный реестр контейнеров ECR и делегирует поддомены в соответствующие окружения.
Такое разделение полностью исключает возможность случайного влияния тестовых процессов на продуктивные данные и существенно упрощает финансовый аудит расходов по каждому отдельному окружению.
Переход на бессерверный оркестратор AWS ECS Fargate
Служба AWS ECS Fargate выполняет запуск контейнеров Docker без необходимости выделения и администрирования EC2-инстансов. Инженер определяет параметры задачи (Task Definition) с указанием точного объема vCPU и оперативной памяти, после чего оркестратор самостоятельно выделяет изолированные вычислительные мощности.
В отличие от Kubernetes, где фоновые периодические задачи (CronJobs) часто требуют постоянного присутствия запущенных узлов в кластере, в ECS Fargate задачи по расписанию запускаются как точечные Fargate Tasks. Контейнер стартует точно в момент наступления триггера EventBridge, выполняет обработку и мгновенно завершается, полностью прекращая списывание средств.
Управление состоянием баз данных при этом выносится в управляемые бессерверные сервисы типа AWS Aurora Serverless v2, обеспечивая динамическое масштабирование мощности без ручного вмешательства администратора.
Инфраструктура как код с использованием AWS CDK и TypeScript
Для управления всеми ресурсами платформы вместо декларирования разрозненных Terraform-файлов или YAML-схем был выбран современный инструментарий AWS Cloud Development Kit (CDK). AWS CDK позволяет описывать облачную инфраструктуру на полноценных языках программирования, таких как TypeScript.
Преимущества подхода AWS CDK:
- Использование строгой типизации TypeScript и полного автодополнения в IDE при объявлении облачных ресурсов.
- Возможность создания повторно используемых конструктов (Constructs) с заранее настроенными корпоративными правилами безопасности и тегирования.
- Декларативное объявление более 20 AWS Lambda-функций, баз данных Aurora, очередей SQS и правил маршрутизации в едином кодовом репозитории.
- Автоматическая генерация оптимизированных CloudFormation-шаблонов при компиляции.
Оптимизация затрат: расписание ресурсов и экономия на сетевых шлюзах
Переход на сочетание ECS Fargate и AWS CDK открыл широкие возможности для точечной оптимизации облачного бюджета:
- Автоматическая остановка тестовых сред: с помощью встроенного расписания CDK в тестовом аккаунте все контейнеры ECS Fargate и базы данных автоматически останавливаются в 19:00 и запускаются в 08:00 по рабочим дням, а также полностью выключаются на выходные. Это сократило совокупную стоимость тестового окружения более чем на 60%.
- Оптимизация сетевых шлюзов: в продуктовом аккаунте для обеспечения дублирования применяются стандартные AWS NAT Gateways. Для тестового аккаунта в CDK был создан альтернативный конструкт на базе минимального EC2-инстанса (NAT Instance), что вынесло из ежемесячного чека фиксированную плату за неиспользуемую полосу пропускания.
Безопасный деплой без постоянных ключей через GitHub Actions OIDC
Финал миграции заключался в автоматизации конвейера непрерывной интеграции и доставки (CI/CD). Для развертывания изменений из GitHub Actions полностью отказались от традиционного использования долгоживущих секретных ключей доступа AWS_ACCESS_KEY_ID и AWS_SECRET_ACCESS_KEY.
Настройка аутентификации через OpenID Connect (OIDC) позволяет CI/CD пайплайну GitHub Actions динамически запрашивать временные токены доступа к AWS IAM с строго ограниченными ролевыми правами на время выполнения шага деплоя. Это исключает риск утечки компрометирующих учетных данных из настроек репозитория и обеспечивает прозрачный аудит всех действий.
Итоговый результат миграции: ликвидация постоянных накладных расходов на администрирование кластера Kubernetes, повышение уровня безопасности и сокращение затрат на облако.