Kubernetes на AWS EKS — счёт вырос в 3 раза за квартал, ищем где утечка

[envoywizard]

Ситуация: 8 месяцев назад запустили EKS-кластер, начинали с $2,000/мес. Сейчас $6,400/мес, функциональность почти не изменилась. Продакт говорит что трафик вырос в полтора раза, но не в три же. Разработчики пожимают плечами. Начали копать — в AWS Cost Explorer всё свалено в кучу. С чего начать разбор?

[Omoto]

Классическая история. Первое что надо сделать — включить Cost Allocation Tags на уровне кластера. Зайди в EKS → Tags, проставь теги типа team, service, environment на все node groups. Потом в Cost Explorer можно будет разбить по тегам. Без этого ты слепой. На будущее: теги ставить с самого начала, потом очень дорого догонять.

[seniorwarlock]

По моему опыту главные источники неожиданных расходов на EKS: 1) NAT Gateway — трафик между AZ платный ($0.01/GB), и если поды в разных AZ гоняют между собой много данных, это копится быстро. 2) LoadBalancer на каждый сервис — у нас была команда которая создавала Service type=LoadBalancer направо-налево, каждый стоит ~$18/мес просто за существование. 3) PersistentVolumeClaim которые никто не удалил после удаления деплоя — висят и тикают.

[seniorsamurai]

Советую поставить Kubecost (есть бесплатный tier) или OpenCost. Они разбивают расходы по неймспейсам, деплойментам, даже по отдельным подам. У нас за первую неделю после установки Kubecost нашли $800/мес «потерянных» ресурсов: staging-namespace который никто не использовал полгода, три LoadBalancer от удалённых сервисов, и job который каждую ночь поднимал жирный под на 15 минут и не освобождал PVC.

[Tcraw62981]

Ещё одна частая причина — overprovisioning requests/limits. Если у тебя requests.cpu=500m на поде а реально используется 50m, нода всё равно считается занятой на 500m и Cluster Autoscaler поднимает новую ноду. Команда: kubectl top pods --all-namespaces | sort -k3 -rn — покажет реальное потребление. Сравни с kubectl get pods -o json | jq '.items[].spec.containers[].resources'. Расхождение больше 3x — тревожный сигнал.

[spaegree]

Мы делали аудит EKS примерно в похожей ситуации. Итог: 31% расходов — неиспользуемые ресурсы, 24% — избыточный NAT-трафик (починили топологией affinity чтобы поды одного сервиса попадали в одну AZ), 18% — on-demand ноды там где можно было Spot. После оптимизации упали с $5k до $2.8k/мес примерно за месяц работы. Spot Instances для stateless workload — это первое что надо включить, экономия 60-70%.

[seniorwarlock]

Насчёт Spot: с 2025 года AWS рекомендует использовать Karpenter вместо Cluster Autoscaler. Karpenter умнее подбирает типы инстансов, лучше работает со Spot, и быстрее реагирует на изменение нагрузки. Если ещё на старом CA — рассмотрите миграцию, у нас это дало ещё -15% к счёту просто за счёт лучшего bin-packing.

[vovan99]

Из недавнего аудита у себя добавлю пункт, который тут не прозвучал: CloudWatch Logs. Кто-то включил debug-уровень в одном сервисе, Fluent Bit честно лил всё в CloudWatch — и ingestion вышел дороже нод, на которых этот сервис крутился. Отфильтруйте в Cost Explorer сервис CloudWatch отдельной строкой, у EKS-кластеров это регулярно второй-третий источник сюрпризов. Заодно проверьте EBS: если тома ещё на gp2, перевод на gp3 даёт минус 20% по дискам вообще без усилий.

[teatree]

@Tcraw62981, ручное сравнение kubectl top с requests работает, но на полусотне деплойментов превращается в пытку. Goldilocks — обёртка над VPA в режиме рекомендаций — делает то же самое автоматом и рисует по каждому контейнеру: вот request, вот реальный p95, вот рекомендация. Мы по его данным срезали requests примерно на 40%, и Autoscaler перестал держать две лишние ноды просто «на всякий случай».

[torcher]

@spaegree, с affinity в одну AZ аккуратнее — вы же этим режете отказоустойчивость: уйдёт зона, ляжет весь сервис целиком. Мы ту же проблему NAT-трафика решали через topology aware routing: реплики остаются размазаны по зонам через topologySpreadConstraints, но трафик между сервисами роутится внутри своей AZ. Межзонные гигабайты упали почти так же, как у вас, а HA не пострадала.