AWS Fargate предлагает для Kubernetes довольно прямую сделку: команда описывает pod, а отдельные worker-ноды, их патчи и планирование ёмкости исчезают из ежедневной рутины. В модели serverless Kubernetes AWS один pod получает собственную изолированную среду выполнения — подход, который меняет привычное представление о кластере как о наборе постоянно работающих серверов.
Архитектуру этого механизма разбирает The New Stack. Главное отличие Fargate от обычного запуска workload в Amazon EKS не в том, что Kubernetes перестаёт быть Kubernetes: разработчик всё так же работает с манифестами, namespace и pod’ами. Меняется граница ответственности. Пользователь задаёт, какие workload должны попасть в Fargate, а AWS берёт на себя инфраструктуру, на которой они фактически стартуют.
В традиционном EKS pod сначала должен найти место на одной из worker-нод. Команде приходится выбирать типы инстансов, считать запас ресурсов, обновлять образы узлов, следить за autoscaler и разбираться, почему в очередной раз не сошлись requests, limits и реальная загрузка. С Fargate путь другой: при создании подходящего pod платформа направляет его на выделенную вычислительную среду. Идея «один pod — один node» здесь важна не как маркетинговая формула, а как модель изоляции и планирования.
Первой точкой на этом пути становится admission-обработка. Kubernetes получает запрос на создание pod и должен определить, относится ли он к настройкам Fargate. Для этого используются правила, связывающие namespace и при необходимости метки workload с профилем запуска. Если pod соответствует профилю, он не ждёт места среди обычных EC2-нод: дальнейшее развёртывание идёт через инфраструктуру Fargate. Если не соответствует — остаётся в привычном мире self-managed или managed node group.
Такое разделение особенно полезно там, где в одном кластере живут разные по характеру сервисы. Например, критичные или нестандартные workload могут работать на обычных узлах с нужными daemonset, агентами и тонкой настройкой ОС. Небольшие API, фоновые задачи, внутренние инструменты или сервисы с нерегулярной нагрузкой можно вынести в Fargate. Это не отменяет проектирование кластера, но заметно сокращает число серверных решений, которые приходится принимать ради нескольких pod’ов.
Выделенная среда для каждого pod также влияет на сетевую модель. Pod получает собственную сетевую идентичность в виртуальной сети AWS, а не делит её с несколькими соседями на общей worker-ноде. Для безопасности это означает более чёткую границу между workload: меньше зависимости от конфигурации общего хоста и меньше причин считать, что изоляция контейнера автоматически равна изоляции приложения. При этом сеть, IP-адреса и правила доступа никуда не исчезают — просто их нужно планировать уже как ресурс для pod’ов, а не только для узлов.
У serverless-подхода есть и вполне земные ограничения. Fargate не является универсальной заменой нодам: он не подходит для сценариев, которым нужны привилегированный доступ, специфические системные агенты, плотная упаковка множества контейнеров на одном хосте или особенно тонкий контроль над окружением. Плата за отказ от управления серверами — меньшая свобода в выборе низкоуровневых настроек. Для команд, которые уже эффективно эксплуатируют большие node group, экономический эффект тоже стоит считать, а не принимать на веру.
Практический вывод для российских команд, работающих с AWS или строящих похожую платформенную модель в других облаках, прост: serverless Kubernetes AWS стоит оценивать не как «Kubernetes без DevOps», а как другой контракт между приложением и инфраструктурой. Операционная нагрузка смещается от обслуживания нод к настройке профилей, сетевой адресации, прав доступа и наблюдаемости. Чем больше managed-сервисы берут на себя жизненный цикл вычислений, тем острее становится вопрос: какие части Kubernetes-команды действительно должны оставаться в зоне контроля компании, а какие разумнее превратить в услугу.
