Learn GitOps with ArgoCD - Cost Optimization

#Introduction

In episode 32 the organization was arranged. Now there's the question that can't be avoided in any real organization: how much does it cost? Cloud costs grow with clusters, and clusters grow with applications — and without discipline, the bill becomes a surprise. In the GitOps world there's good news: every resource decision lives in Git, so cost optimization can be reviewed like any ordinary code change.

This episode discusses cost optimization from three angles: application resources, clusters, and GitOps itself — then how to monitor and allocate costs. Remember the episode 25 principle: measure first, change one thing, measure again.

#Resource Optimization

#Application Right-Sizing

The biggest waste is usually not applications that lack resources, but ones that request far above what they need. A pod requesting 4 vCPUs but using 0.3 vCPUs wastes space and money. Data from kubectl top and usage metrics shows the mismatch between request and utilization:

kubectl top pods -n api --sort-by=cpu
kubectl top pods -n api --sort-by=memory
kubectl describe pod api-5d4b6c7d9-8xk2m -n api

A healthy target: CPU request utilization around 60–80 percent on average. Below that, shrink the request; consistently above 90 percent, enlarge it.

#Requests and Limits

Requests determine scheduling and quotas; limits determine protection from throttling/OOM. Best practice: realistic requests (from measurement), protective limits (not letting one pod take everything). Use namespace quotas (episode 28) so wasteful requests can't spread.

#HPA and VPA

• HPA (Horizontal) adds/removes replicas based on metrics — efficient for varying loads. Combining HPA with correct requests keeps the cluster lean when idle.
• VPA (Vertical) recommends correct requests based on historical usage. Use VPA in Recommender mode first — let it give suggestions, then apply them manually (Auto mode can be surprising if used directly).

VPA as recommender

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: api-vpa
  namespace: api
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  updateMode: "Off"

#Cluster Optimization

#Node Pool Strategy

A cluster with a single homogeneous node pool wastes money on workloads that don't fit. Separate them:

• General node pool — standard load, on-demand.
• Spot node pool — workloads tolerant of interruption (batch, workers, non-critical).
• Burst node pool — for spikes.

#Spot Instances

Spot instances can save 60–90 percent on compute costs — provided workloads tolerate eviction. In Kubernetes, spot nodes must be labeled, and the applications using them must be able to restart: multi-replica Deployments with topologySpreadConstraints, disruptionBudget, and state outside the pod (databases stay on on-demand nodes).

Pod anti-affinity for spot nodes

spec:
  template:
    spec:
      nodeSelector:
        node.kubernetes.io/lifecycle: spot
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname

#Cluster Autoscaling

The cluster autoscaler adds nodes when pods are Pending due to resources, and removes idle nodes. It's the safety net that makes optimization safe: requests that are too small no longer cause outages because the cluster adjusts. Pair it with HPA for best results: HPA manages replicas, the autoscaler manages nodes.

#Multi-Tenancy Efficiency

One multi-tenant cluster (episode 28) is cheaper than many small clusters: idle nodes get filled with other workloads. The downside is isolation complexity — a trade-off that must be calculated per organization, not assumed.

#GitOps Efficiency Itself

ArgoCD also consumes resources. Its optimization (episode 25) is cost optimization:

• Sync frequency tuning — reconciling every 3 minutes for all applications is wasteful. Non-critical applications can do 10–30 minutes. Fewer reconciles = less controller CPU.
• Repository size optimization — large repos make cloning heavy. Separate rarely-changing manifests, use shallow clone (--depth 1).
• Cache optimization — the Redis cache prevents repeated manifest re-rendering; make sure the TTL isn't too short for rarely-changing repos.
• Network efficiency — webhooks (episode 30) replace polling; limit Git concurrency (ARGOCD_GIT_CONCURRENCY) so the repo server isn't over-provisioned.

Infrequent reconcile for non-critical applications

metadata:
  annotations:
    argocd.argoproj.io/reconcile-period: 20m
spec:
  ...

#Cost Monitoring

Costs that aren't measured can't be optimized. Four monitoring layers:

#Cost Allocation Tags

Resource labels are the foundation of everything — from the start (episode 28): team=, environment=, tenant=, app=. Cloud providers read these labels for cost reports. Undisciplined labels = costs that can't be attributed.

#Usage Tracking

Integrate Kubernetes metrics with cost data. Tools like OpenCost read resource requests and actual usage, then calculate cost per namespace/deployment from provider prices. Combine with ArgoCD metrics (episode 22) to see cost per application.

#Chargeback vs Showback

• Chargeback — real billing to business units; drives accountability, but needs accurate data and can trigger politics.
• Showback — usage reports without billing; enough to change behavior and easier to start. Start with showback, move up to chargeback once the data is trusted.

#Cost Anomaly Detection

Cost anomalies are usually a sign of a problem: an application stuck in CrashLoopBackOff (constant restarts = wasted compute), a node pool that never shrinks, or runaway syncs. A simple alert can save thousands of dollars:

groups:
  - name: cost
    rules:
      - alert: DailyCostSpike
        expr: sum(increase(cost_daily[1d])) / sum(increase(cost_daily[7d])) > 1.5

#Closing

This episode mapped cost optimization: application right-sizing with real usage data, disciplined request/limits, HPA and VPA, node pool strategies with spot instances and cluster autoscaling, multi-tenancy efficiency, GitOps efficiency through sync frequency tuning, repo size, cache, and networking, and cost monitoring with cost allocation tags, usage tracking, showback/chargeback, and anomaly detection.

The points you should take with you:

• Measure utilization first; right-sizing below 60 percent is waste.
• VPA Recommender suggests; apply after verification.
• Spot instances save big, but only for interruption-tolerant workloads.
• GitOps optimization (sync frequency, cache) is a subtle but real cost optimization.
• Disciplined labels from the start make all cost monitoring possible.

Costs are under control. Time to make sure everything is ready before really launching into production. In the next episode 34 we discuss production deployment checklist — pre-production checklist, operational practices, common pitfalls, and day-2 operations. See you in episode 34!