Kubernetes оптимизация на разходите: Karpenter, KEDA и VPA (2026)

Актуализирано: 31 май 2026 г.

Оптимизацията на разходите за Kubernetes се постига чрез комбинация от три практики: автоматично мащабиране на nodes с Karpenter, мащабиране на pods спрямо реален трафик с KEDA и точно калибриране на CPU/memory requests с Vertical Pod Autoscaler (VPA). В средно по размер production cluster тази комбинация намалява инфраструктурните разходи с 40–70%, без да влошава SLO-тата. В това ръководство показвам как съм внедрявал тези инструменти в реални клъстери през 2025–2026 г. и какви грешки да избегнете (повярвайте ми, направил съм повечето от тях).

• Karpenter v1.x (GA от октомври 2024) избира тип EC2 instance динамично и стартира нови nodes за под 60 секунди, тоест 2–3× по-бързо от Cluster Autoscaler.
• KEDA 2.16 (януари 2026) поддържа 70+ scaler-а, включително scale-to-zero за Deployments. Това е нещо, което вграденият HPA просто не може да направи.
• Активирането на Spot instances чрез Karpenter NodePool с правилни disruption budgets дава 60–90% икономия за stateless работни натоварвания.
• Pods без зададени requests струват средно 2.4× повече, отколкото правилно калибрираните според OpenCost benchmark данни за 2025 г.
• Bin packing efficiency под 50% означава, че плащате за неизползван capacity. Karpenter consolidation решава това автоматично.
• Комбинацията Karpenter + KEDA + VPA в recommendation режим е стандартът за FinOps в Kubernetes през 2026 г.

Защо Kubernetes клъстерите излизат по-скъпо от очакваното

По данни на CNCF FinOps Foundation от началото на 2026 г., 49% от организациите харчат поне 30% повече за Kubernetes, отколкото са планирали. Основните причини са три и са доста взаимосвързани.

Първо, разработчиците задават CPU и memory requests "на око", обикновено с голяма margin "за всеки случай". Когато Kubernetes scheduler гледа requests (а не реалното потребление), за да реши къде да сложи pod, тези раздути requests блокират capacity, който никой не използва. Това е най-честата причина за нисък bin packing efficiency.

Второ, дефолтният Cluster Autoscaler избира nodes от предварително дефинирани node groups. Това означава, че ако имате node group с m5.xlarge инстанции и pod, който иска 200m CPU и 256Mi памет, ще получите цял m5.xlarge с 4 vCPU и 16 GiB памет за този единствен pod. Фрагментация по дефиниция.

Трето, HPA (Horizontal Pod Autoscaler) мащабира спрямо CPU или memory, които често не са правилният signal. Опашка със 100 000 неизпратени съобщения в Kafka не вдига CPU, докато consumer-а не започне работа. Резултатът? Под-мащабиране при peak и над-мащабиране при idle.

Преди да минем към инструментите, помислете и за разпределението на разходите между екипите. Подробно описание има в нашето ръководство за тагване на облачни ресурси за cost allocation. Без правилни labels не може да измерите ROI на оптимизациите по-долу.

Karpenter: интелигентно мащабиране на nodes

Karpenter е node autoscaler за Kubernetes, разработен от AWS и open-sourced през 2021 г. От версия 1.0 (октомври 2024) е GA и продакшън-готов. За разлика от Cluster Autoscaler, който избира от предефинирани node groups, Karpenter гледа pending pods и стартира оптималния EC2 instance type директно, обикновено за под 60 секунди.

Защо това спестява пари? Защото вместо да платите цяла m5.4xlarge, защото във вашия node group няма нищо по-малко, Karpenter може да стартира c6g.large, ако точно това трябва на pending pod. През 2026 г. Karpenter поддържа AWS, Azure (alpha) и подготовка за GCP.

Ето минимален NodePool манифест за production cluster с микс от On-Demand и Spot:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: general-purpose
spec:
  template:
    metadata:
      labels:
        workload-tier: general
    spec:
      requirements:
        - key: karpenter.k8s.aws/instance-category
          operator: In
          values: ["c", "m", "r"]
        - key: karpenter.k8s.aws/instance-generation
          operator: Gt
          values: ["5"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64", "arm64"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
      expireAfter: 720h
  limits:
    cpu: 1000
    memory: 1000Gi
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s
    budgets:
      - nodes: "10%"

Двата ключови параметъра са consolidationPolicy: WhenEmptyOrUnderutilized и budgets. Първият казва на Karpenter да консолидира недостатъчно използвани nodes (премества pods на по-малки nodes), а вторият ограничава колко nodes могат да бъдат disrupted едновременно. Това е критично за production, особено в peak часовете.

За пълно ръководство по Spot стратегии вижте нашия материал за Spot инстанции в AWS, Azure и GCP. Официалната Karpenter документация е достъпна в karpenter.sh/docs.

KEDA и event-driven мащабиране на pods

KEDA (Kubernetes Event-driven Autoscaling) разширява HPA с над 70 scaler-а: Kafka, RabbitMQ, AWS SQS, Azure Service Bus, PostgreSQL, Prometheus метрики и още много. Най-важната функция за оптимизация на разходите е scale-to-zero: когато няма работа, deployment-ът се свива до 0 pods. Вграденият HPA минимумът е 1.

За batch processing работни натоварвания, които текат по график или при event, scale-to-zero може да елиминира 60–80% от компютърните часове. Аз лично го внедрих върху order-processor pipeline миналата година и месечната сметка падна с близо 70%. Ето пример със SQS scaler:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: order-processor-scaler
spec:
  scaleTargetRef:
    name: order-processor
  minReplicaCount: 0
  maxReplicaCount: 50
  pollingInterval: 15
  cooldownPeriod: 120
  triggers:
    - type: aws-sqs-queue
      metadata:
        queueURL: https://sqs.eu-central-1.amazonaws.com/123456789/orders
        queueLength: "20"
        awsRegion: "eu-central-1"
        identityOwner: operator

Този конфиг казва на KEDA: за всеки 20 неизпратени съобщения, добави 1 pod, максимум 50, и след 120 секунди тишина свий до 0. Pollig-ът на 15 секунди значи, че реагирате под минута на спайкове.

KEDA срещу HPA: кога да изберете кое

Характеристика	HPA (вграден)	KEDA 2.16
Scale-to-zero	Не (минимум 1)	Да
Брой scaler-и	CPU, memory, custom	70+ (Kafka, SQS, Prometheus, и др.)
Event-driven scaling	Не директно	Да
Производителност на мащабиране	Бавна за burst трафик	Бърза (configurable pollingInterval)
Сложност на инсталация	Включен в Kubernetes	Helm chart, 1 команда
Production готовност	Да	Да (CNCF Graduated)

KEDA не замества HPA, той го разширява. Под капака KEDA генерира HPA обекти. Препоръката ми: HPA е достатъчен за класически stateless web сървъри с предвидим трафик, докато KEDA е задължителен за всичко, което се мащабира спрямо опашки, scheduled jobs или метрики извън Kubernetes.

Vertical Pod Autoscaler и right-sizing на requests

VPA автоматично препоръчва (и опционално прилага) оптимални CPU и memory requests, базирани на исторически данни от метриките на pod-овете. От опит: пускайте VPA в updateMode: "Off" (само recommendations) за първите няколко седмици, защото auto-mode рестартира pod-ове, за да приложи нови requests.

Пример за VPA в recommendation режим:

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: api-server-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  updatePolicy:
    updateMode: "Off"
  resourcePolicy:
    containerPolicies:
      - containerName: '*'
        minAllowed:
          cpu: 50m
          memory: 64Mi
        maxAllowed:
          cpu: 2
          memory: 4Gi
        controlledResources: ["cpu", "memory"]

След 7–14 дни проверете препоръките:

kubectl describe vpa api-server-vpa | grep -A 10 "Recommendation"

Типичните резултати, които виждам в production клъстери: екипите задават 500m CPU "за всеки случай", а реалното използване е 30–80m. След прилагане на VPA препоръки bin packing efficiency скача от 40% до 75%, и обикновено може да изключите 2–3 nodes от 10. Goldilocks от Fairwinds е удобен dashboard върху VPA recommendations за лесна визуализация. Допълнително четене за по-широката картина имате в нашето ръководство за right-sizing на облачни ресурси.

Как да използвате Spot instances в Kubernetes безопасно

Spot инстанциите дават 60–90% отстъпка, но могат да бъдат прекъснати с 2-минутно предизвестие. За stateless работни натоварвания (web frontend, API gateways, batch workers) това е напълно приемливо, защото Kubernetes ще пресъздаде pod-ове на друг node.

Препоръчителна архитектура за хибриден клъстер:

1. System workloads на On-Demand: kube-system, ingress controllers, monitoring stack, по 1–2 малки nodes с taints, които не приемат app pods.
2. Stateful workloads на On-Demand: бази данни, message brokers, отделен NodePool с taint workload-type=stateful:NoSchedule.
3. Stateless app workloads на Spot: 80% от capacity-то, отделен NodePool, който приема всичко без специфични toleration-и.

Karpenter автоматично разпределя Spot заявките между instance types за намаляване на interruption rate. През 2026 г. AWS Spot Placement Score препоръчва диверсификация в поне 6 instance types на 3 AZ, и Karpenter NodePool изисквания трябва да позволяват точно това.

Инсталирайте също AWS Node Termination Handler като DaemonSet, за да реагирате на rebalance recommendation events преди реалното прекъсване. Печелите допълнително време за graceful drain, което в моя опит е спасявало доста чувствителни batch jobs.

Мониторинг на разходите с Kubecost и OpenCost

Не може да оптимизирате нещо, което не измервате. Честно, това е основното правило в FinOps. OpenCost е CNCF-graduated open-source проект (от 2024 г.) за разпределяне на Kubernetes разходи по namespace, deployment, label или pod. Kubecost е комерсиалното разширение със UI и multi-cluster federation.

След инсталация (1 Helm команда) получавате:

• Cost per deployment: точна стойност в USD за CPU, memory, storage, network и LoadBalancer на ниво pod.
• Efficiency score: съотношението requested срещу used ресурси, основният KPI за right-sizing.
• Idle costs: колко плащате за неизползван capacity (overprovisioned nodes).
• Savings recommendations: автоматични предложения за right-sizing, abandoned PVCs и unutilized LoadBalancers.

Свържете данните за пълна FinOps картина с нашето ръководство за AWS Cost Explorer, Budgets и Cost Anomaly Detection. OpenCost разходите се експортират към AWS CUR за централизирано отчитане.

Чести грешки при оптимизация на Kubernetes

Топ грешки, които виждам в одити:

• Pods без resource requests изобщо: Scheduler ги слага навсякъде, VPA няма базова стойност за recommendations. Винаги задавайте requests, дори да са грешни, защото VPA ще ги коригира после.
• Memory limits = requests: Memory е incompressible. Ако pod удари limit, OOMKiller го убива веднага. Memory limits трябва да са 1.5–2× от requests за безопасност.
• Karpenter без disruption budgets: Без budgets, consolidation може да убие 50% от nodes наведнъж по време на peak трафик. Винаги задавайте budgets: nodes: "10%" минимум.
• VPA на pods с HPA на CPU: Двата ще се сбият. VPA качва request, HPA вижда нисък CPU usage и сваля replicas, после VPA рестартира за нов request. Използвайте VPA само за memory, HPA за CPU/реплики, или преминете изцяло на VPA off mode + manual apply.
• Spot за state-чувствителни workloads: Никога не пускайте etcd, бази данни, Redis с persistence на Spot. Една interruption по време на write може да загуби данни.

Често задавани въпроси

Колко може да спестя с Karpenter спрямо Cluster Autoscaler?

Типичните икономии са 20–40% само от по-добър bin packing и възможността Karpenter да избира оптимални instance types за всеки workload. Когато добавите Spot integration и consolidation, общите икономии достигат 60–80%.

Сигурен ли е Karpenter за production?

Да, Karpenter v1.0 е GA от октомври 2024 г. и се използва в production от компании като Adobe, Anthropic, Snap и AWS самата. Препоръчвам започване с консервативни disruption budgets (10%) и постепенно отпускане след натрупване на оперативен опит.

Каква е разликата между KEDA и HPA?

HPA мащабира базирано на метрики на pod-овете (CPU, memory, custom metrics) и минимум 1 replica. KEDA разширява HPA с 70+ external scaler-а (Kafka, SQS, Prometheus и др.) и поддържа scale-to-zero. KEDA не замества HPA, той го генерира под капака.

Кога да използвам VPA вместо HPA?

VPA коригира размера на индивидуални pods (вертикално мащабиране); HPA добавя още pods (хоризонтално). За web сървъри с предвидим трафик използвайте HPA. За batch jobs, ML inference с фиксиран брой реплики и right-sizing на legacy приложения използвайте VPA в recommendation режим.

Може ли да използвам Spot instances за всички pods?

Не. Spot инстанциите могат да бъдат прекъснати с 2-минутно предизвестие. Stateful workloads (бази данни, etcd, message brokers с persistence) трябва да работят на On-Demand. Stateless workloads (API, web, batch workers) са идеалните кандидати за Spot, типично 70–80% от capacity на production клъстер.

Кой е най-добрият инструмент за мониторинг на Kubernetes разходи през 2026 г.?

OpenCost (open-source, CNCF graduated) е стандартът. За multi-cluster federation, advanced reporting и enterprise SSO препоръчвам Kubecost (комерсиалното разширение). И двата работят на всички cloud providers и експортират данни към AWS CUR, Azure EA и GCP BigQuery.