بهینه‌سازی هزینه کوبرنتیز در ۲۰۲۶: راهنمای کاهش ۵۰٪ هزینه K8s

به‌روزرسانی: ۲۷ ژوئن ۲۰۲۶

بهینه‌سازی هزینه کوبرنتیز یعنی کاهش هزینه‌های محاسبات، ذخیره‌سازی و شبکه خوشه‌های K8s از طریق راست‌سایزینگ پادها، استفاده هوشمندانه از اسپات اینستنس‌ها، خودکارسازی مقیاس‌گذاری نودها با Karpenter و رصد مداوم با ابزارهایی مانند OpenCost و Kubecost. طبق گزارش FinOps Foundation و CNCF، حدود ۴۹٪ سازمان‌ها در سال ۲۰۲۵ افزایش هزینه غیرمنتظره در کوبرنتیز را تجربه کرده‌اند و راست‌سایزینگ همچنان بزرگ‌ترین فرصت صرفه‌جویی است. در این راهنما ۱۲ تکنیک اثبات‌شده برای کاهش تا ۵۰٪ هزینه‌های K8s را پوشش می‌دهم؛ همان روش‌هایی که سال گذشته روی یک خوشه تولیدی حدود ۸۰۰ نودی پیاده کردم و صورت‌حساب ماهانه را تقریباً نصف کرد.

• میانگین استفاده از CPU در خوشه‌های Kubernetes طبق گزارش Cast AI تنها حدود ۱۳٪ است؛ راست‌سایزینگ پادها به‌تنهایی می‌تواند ۳۰ تا ۵۰ درصد هزینه را کاهش دهد.
• Karpenter (نسخه پایدار ۱.۰ از اواخر ۲۰۲۴) جایگزین Cluster Autoscaler شده و با bin-packing هوشمند و انتخاب خودکار نوع اینستنس، تا ۵۰٪ صرفه‌جویی نسبت به ASG ایجاد می‌کند.
• اسپات اینستنس‌ها برای workloadهای stateless و دارای retry تا ۹۰٪ ارزان‌تر از On-Demand هستند؛ ترکیب آن با PodDisruptionBudget ایمن است.
• OpenCost (پروژه CNCF Incubating) استاندارد باز برای showback و chargeback خوشه‌های K8s است و با Kubecost رابط گرافیکی غنی‌تر دریافت می‌کند.
• تنظیم صحیح requests/limits، فعال‌سازی VPA در حالت Recommendation و حذف PV‌های یتیم سه اقدام سریع با ROI بالا هستند.
• تخصیص هزینه بر اساس namespace، label و tenant با استاندارد FOCUS 1.2 در ۲۰۲۶ سازگار شده است.

چرا هزینه کوبرنتیز از کنترل خارج می‌شود؟

هزینه کوبرنتیز در ۲۰۲۶ تبدیل به بزرگ‌ترین خط هزینه ابری برای بسیاری از شرکت‌های مهندسی شده است. سه دلیل اصلی پشت این رشد لجام‌گسیخته وجود دارد. اول، توسعه‌دهندگان معمولاً requests را خیلی محتاطانه (مثلاً ۲ vCPU برای سرویسی که عملاً ۰.۲ مصرف می‌کند) تعیین می‌کنند تا از OOMKill جلوگیری کنند؛ نتیجه این است که میانگین استفاده مفید CPU در خوشه‌های تولیدی طبق داده‌های ۲۰۲۵ شرکت Cast AI تنها حدود ۱۳٪ است. دوم، عدم وجود showback شفاف باعث می‌شود تیم‌ها هیچ بازخوردی درباره هزینه workload خود دریافت نکنند. سوم، نودهای On-Demand بزرگ به‌جای ترکیب هوشمند Spot و RI استفاده می‌شوند.

به‌علاوه، بسیاری از مهندسان پلتفرم با ذهنیت «قابلیت اطمینان به هر قیمت» کار می‌کنند و FinOps را مسئله‌ای جدا از طراحی پلتفرم می‌بینند. صادقانه بگویم، این بزرگ‌ترین اشتباه فرهنگی است که در ممیزی هزینه‌ها می‌بینم. هر ۱٪ کاهش در استفاده میانگین CPU یک خوشه ۱۰۰۰ نودی می‌تواند سالانه ده‌ها هزار دلار صرفه‌جویی ایجاد کند. برای درک بهتر مدل تعهدات ابری، توصیه می‌کنم مقایسه AWS Savings Plans و Reserved Instances را نیز مطالعه کنید، چون لایه نودهای پایدار خوشه باید با تعهد پوشش داده شود.

راست‌سایزینگ پادها با VPA و معیارهای واقعی

راست‌سایزینگ پادها (Pod Right-sizing) بزرگ‌ترین اهرم کاهش هزینه است. هدف این است که requests و limits با مصرف واقعی workload در طول ۷ تا ۱۴ روز اخیر هم‌خوانی داشته باشد. ابزار رسمی برای این کار Vertical Pod Autoscaler (VPA) است که در سه حالت Off (فقط توصیه)، Initial و Auto کار می‌کند. در محیط تولید، حالت Off (Recommendation) را شروع کنید تا توصیه‌ها را با تیم خود بازبینی کنید، سپس به Auto مهاجرت کنید.

یک نمونه VPA برای سرویس API:

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: api-service-vpa
  namespace: prod
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-service
  updatePolicy:
    updateMode: "Off"   # فقط توصیه؛ به Auto تغییر دهید پس از اعتبارسنجی
  resourcePolicy:
    containerPolicies:
    - containerName: '*'
      minAllowed:
        cpu: 50m
        memory: 128Mi
      maxAllowed:
        cpu: 2
        memory: 4Gi
      controlledResources: ["cpu", "memory"]

برای دیدن توصیه‌ها:

kubectl get vpa api-service-vpa -n prod -o yaml | yq '.status.recommendation'

قانون عملی: request را روی توصیه «target» قرار دهید، limit را روی «upperBound» (یا ۱.۵ برابر request برای workloadهای پرنوسان). برای workloadهای حساس به latency، limit CPU را تنظیم نکنید (این کار جلوی CFS throttling را می‌گیرد و در عمل تأخیر را کاهش می‌دهد).

چه workloadهایی برای VPA Auto مناسب نیستند؟

VPA Auto پاد را restart می‌کند تا منابع جدید را اعمال کند. برای StatefulSetهای دیتابیس، سرویس‌های singleton و workloadهای دارای session sticky از VPA Auto استفاده نکنید؛ به‌جای آن از حالت Recommendation و اعمال دستی در پنجره نگهداری استفاده کنید.

Karpenter و مقیاس‌گذاری هوشمند نودها

Karpenter پروژه‌ای متن‌باز از AWS است که در نوامبر ۲۰۲۴ به نسخه پایدار ۱.۰ رسید و حالا توسط Azure (AKS Karpenter Provider) و GCP نیز پشتیبانی می‌شود. تفاوت کلیدی با Cluster Autoscaler این است که Karpenter به‌جای کار با Auto Scaling Groupهای از پیش تعریف‌شده، نوع و اندازه نود را در لحظه بر اساس پادهای pending انتخاب می‌کند. نتیجه bin-packing بسیار بهتر و کاهش ۲۰ تا ۵۰ درصدی هزینه نود است.

نمونه NodePool که هم On-Demand و هم Spot را در خانواده‌های متنوع انتخاب می‌کند:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    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"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s
  limits:
    cpu: "1000"

ویژگی consolidationPolicy: WhenEmptyOrUnderutilized در نسخه ۱.۰ به‌صورت فعال نودهای کم‌استفاده را خاموش می‌کند و پادها را روی نودهای ارزان‌تر دوباره می‌چیند. این یک ویژگی به‌تنهایی می‌تواند ۱۵ تا ۲۵ درصد صرفه‌جویی اضافی نسبت به Cluster Autoscaler ایجاد کند.

استفاده ایمن از Spot/Preemptible برای کاهش ۷۰٪

اینستنس‌های Spot (AWS)، Spot VM (Azure) و Preemptible/Spot (GCP) تا ۹۰٪ ارزان‌تر از On-Demand هستند اما در هر زمان با اعلان ۲ دقیقه‌ای ممکن است قطع شوند. در ۲۰۲۶ تقریباً همه workloadهای stateless در K8s باید روی Spot اجرا شوند. کلید اجرای ایمن سه چیز است: تنوع نوع اینستنس، PodDisruptionBudget و node termination handler.

مثال PDB برای جلوگیری از قطع همزمان همه رپلیکاها:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-pdb
  namespace: prod
spec:
  minAvailable: 75%
  selector:
    matchLabels:
      app: api-service

برای workloadهایی که اصلاً نباید روی Spot اجرا شوند (مثل دیتابیس‌ها، Ingress controllerها)، از taint روی نودهای Spot و toleration معکوس استفاده کنید:

tolerations:
- key: "karpenter.sh/capacity-type"
  operator: "Equal"
  value: "spot"
  effect: "NoSchedule"

یک الگوی مفید که در پروژه آخرم به‌خوبی جواب داد: کنترل‌پلین، سرویس‌های stateful و ۲۰٪ از replicaهای حیاتی روی On-Demand (پوشش‌داده‌شده با Savings Plans) و باقی ۸۰٪ روی Spot. این تنظیم در عمل ۶۰ تا ۷۰ درصد هزینه نود را کاهش می‌دهد. برای جزئیات بیشتر در مورد ترکیب تعهدات با اسپات، راهنمای کامل Savings Plans و Reserved Instances را ببینید.

رصد هزینه با OpenCost و Kubecost

OpenCost استاندارد متن‌باز پروژه CNCF برای محاسبه هزینه workloadهای کوبرنتیز است که در ۲۰۲۴ به سطح Incubating ارتقا یافت. این ابزار هزینه CPU، حافظه، GPU، storage و حتی load balancer را به سطح namespace، pod و label تجزیه می‌کند. Kubecost نسخه تجاری روی همان موتور است که داشبورد، گزارش‌گیری و توصیه‌های خودکار اضافه می‌کند.

نصب سریع OpenCost با Helm:

helm repo add opencost https://opencost.github.io/opencost-helm-chart
helm repo update
helm install opencost opencost/opencost \
  --namespace opencost --create-namespace \
  --set opencost.exporter.defaultClusterId=prod-eks-us-east-1 \
  --set opencost.prometheus.internal.enabled=true

پس از نصب، با endpoint زیر هزینه هر namespace را در ۷ روز گذشته دریافت کنید:

kubectl port-forward -n opencost svc/opencost 9003:9003 &
curl -s "http://localhost:9003/allocation?window=7d&aggregate=namespace" | jq '.data[0] | to_entries | map({ns:.key, cost:.value.totalCost}) | sort_by(-.cost)'

این داده‌ها را به Grafana یا داشبورد داخلی FinOps خود متصل کنید و آستانه هشدار روی رشد ناگهانی (مثلاً بیش از ۳۰٪ نسبت به هفته قبل) تنظیم کنید. همین یک اقدام جلوی بسیاری از اسراف‌های ناخواسته را خیلی زود می‌گیرد.

تخصیص هزینه به تیم‌ها با namespace و label

showback و chargeback بدون استراتژی برچسب‌گذاری منسجم غیرممکن است. در ۲۰۲۶، استاندارد FOCUS 1.2 رسماً ستون‌های مخصوص Kubernetes (مانند SubAccountId, ResourceId) را پشتیبانی می‌کند که این کار را آسان‌تر کرده است. یک مدل عملی این است که هر تیم یک namespace اختصاصی داشته باشد و سه label اجباری روی هر workload اعمال شود: team, cost-center, environment.

برای اعمال این الزام در زمان admission از Kyverno یا OPA Gatekeeper استفاده کنید. مثال Kyverno:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-cost-labels
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-labels
    match:
      any:
      - resources:
          kinds: ["Deployment", "StatefulSet", "Job"]
    validate:
      message: "برچسب‌های team، cost-center و environment الزامی هستند"
      pattern:
        metadata:
          labels:
            team: "?*"
            cost-center: "?*"
            environment: "?*"

سپس در OpenCost از این labelها به‌عنوان dimension برای تجمیع استفاده کنید. این روش به‌سادگی به مدل chargeback تبدیل می‌شود که در گزارش‌های ماهانه به تیم‌ها داده شود. برای اصول این الگو در سطح بالاتر، رویکرد FinOps عامل‌محور با عامل‌های هوش مصنوعی را مطالعه کنید که نسل بعدی اتوماسیون این فرایند است.

بهینه‌سازی هزینه ذخیره‌سازی و شبکه

هزینه‌های ذخیره‌سازی و خروج داده (egress) معمولاً نادیده گرفته می‌شوند اما در خوشه‌های بزرگ به سرعت ۲۰ تا ۳۰ درصد صورت‌حساب را تشکیل می‌دهند. سه اقدام با ROI بالا:

1. حذف PV‌های یتیم: پس از حذف یک StatefulSet، PVCها (و PVها در سیاست Retain) باقی می‌مانند. اسکریپتی هفتگی بنویسید که PVهای bound به PVC غیرموجود را پیدا و گزارش دهد.
2. انتخاب storage class مناسب: gp3 در AWS از gp2 ارزان‌تر و سریع‌تر است و مهاجرت در محل امکان‌پذیر است. برای دیسک‌های با IO کم از sc1/st1 استفاده کنید.
3. توپولوژی-آگاهی شبکه: با فعال‌سازی topologyAwareHints و Service topology، ترافیک بین AZها (که در AWS ۰.۰۲ دلار به ازای هر GB هزینه دارد) به‌شدت کاهش می‌یابد.

برای پیدا کردن PV‌های یتیم:

kubectl get pv -o json | jq -r '.items[] | select(.status.phase=="Released" or (.spec.claimRef and (.spec.claimRef.name as $n | $n | length > 0))) | "\(.metadata.name)\t\(.spec.capacity.storage)\t\(.status.phase)"'

برای کاهش هزینه خروج چندابری، از سرویس‌های CDN یا Direct Connect/ExpressRoute برای ترافیک سنگین استفاده کنید. در خوشه‌های GKE، استفاده از Multi-Cluster Services به‌جای پل‌های public تا ۸۰٪ هزینه خروج را کم می‌کند.

چقدر می‌توان در هزینه K8s صرفه‌جویی کرد؟

براساس داده‌های میدانی ۲۰۲۵ تا ۲۰۲۶، یک خوشه تولیدی متوسط که هیچ‌یک از این تکنیک‌ها را اجرا نکرده باشد می‌تواند ۴۰ تا ۶۰ درصد صرفه‌جویی به دست آورد. توزیع تقریبی صرفه‌جویی هر اقدام به این صورت است:

تکنیک	دامنه صرفه‌جویی	پیچیدگی اجرا	زمان پیاده‌سازی
راست‌سایزینگ requests/limits با VPA	۲۵–۴۰٪	متوسط	۲–۴ هفته
مهاجرت از Cluster Autoscaler به Karpenter	۱۵–۲۵٪	متوسط	۱–۲ هفته
اضافه کردن Spot برای workloadهای stateless	۳۰–۶۰٪ روی نودهای واجد شرایط	پایین تا متوسط	۱ هفته
پوشش پایه با Compute Savings Plans	۲۰–۷۲٪ (تعهد ۳ ساله All Upfront)	پایین	۱ روز
حذف PV یتیم و gp2→gp3	۵–۱۵٪ از هزینه storage	پایین	۱–۲ روز
کاهش ترافیک بین-AZ با topology hints	۵–۲۰٪ از هزینه شبکه	پایین	۱ هفته

ترتیب پیشنهادی اجرا که خودم در پروژه‌های متعدد آزموده‌ام: ابتدا OpenCost را برای دید شفاف نصب کنید، سپس Karpenter و Spot را راه‌اندازی کنید (سود سریع)، بعد راست‌سایزینگ تدریجی با VPA Recommendation. پوشش تعهدات (Savings Plans) را پس از پایدار شدن مصرف خریداری کنید، هرگز قبل از آن.

پرسش‌های متداول

آیا Kubernetes ذاتاً گران است؟

خود Kubernetes رایگان است؛ گرانی از نحوه استفاده نشأت می‌گیرد. مهم‌ترین عامل، over-provisioning پادها به دلیل ترس از OOMKill است. با راست‌سایزینگ، Karpenter و Spot، هزینه واقعی به‌ازای هر workload معمولاً از معادل آن روی ECS/Fargate کمتر می‌شود.

تفاوت OpenCost و Kubecost چیست؟

OpenCost موتور متن‌باز محاسبه هزینه و یک پروژه CNCF Incubating است. Kubecost محصول تجاری ساخته‌شده روی همین موتور است که داشبورد گرافیکی، گزارش‌های پیشرفته، multi-cluster federation و توصیه‌های خودکار اضافه می‌کند. برای شروع، OpenCost رایگان کافی است.

آیا Karpenter جایگزین Cluster Autoscaler شده است؟

عملاً بله. از نوامبر ۲۰۲۴ Karpenter به نسخه پایدار ۱.۰ رسید و AWS آن را به‌عنوان مسیر توصیه‌شده برای EKS معرفی می‌کند. Azure نیز AKS Karpenter Provider را در حالت GA دارد. Cluster Autoscaler هنوز برای محیط‌های on-prem و خوشه‌های قدیمی استفاده می‌شود اما برای پروژه‌های جدید، Karpenter انتخاب بهتری است.

چگونه می‌توان از تخریب pod روی نودهای Spot جلوگیری کرد؟

سه لایه دفاع: PodDisruptionBudget با minAvailable مناسب، تنوع در حداقل ۱۰ نوع اینستنس (با Karpenter ساده است)، و AWS Node Termination Handler یا قابلیت داخلی Karpenter که اعلان ۲ دقیقه‌ای را دریافت و نود را cordon/drain می‌کند. این ترکیب در عمل قطع کاربر-نهایی را تقریباً صفر می‌کند.

آیا باید برای کل خوشه Savings Plans بخریم؟

خیر. خط پایه پایدار (baseline) خوشه را با Compute Savings Plans پوشش دهید و ظرفیت متغیر را روی Spot و On-Demand بگذارید. معمولاً پوشش ۵۰ تا ۷۰ درصد از CPU/RAM پایه با تعهد ۱ یا ۳ ساله No Upfront، تعادل خوبی بین صرفه‌جویی و انعطاف ایجاد می‌کند.