Cost optimization in Kubernetes - Step-by-Step Execution

Process Flow - Cost optimization in Kubernetes

Analyze current resource usage

↓

Identify overprovisioned pods

↓

Adjust resource requests and limits

↓

Implement autoscaling (HPA/VPA)

↓

Use efficient node types and scaling

↓

Monitor costs and optimize continuously

This flow shows how to reduce Kubernetes costs by analyzing usage, adjusting resources, autoscaling, and monitoring continuously.

Execution Sample

Kubernetes

kubectl top pods
kubectl get hpa
kubectl describe node
kubectl apply -f resource-limits.yaml

Commands to check pod resource usage, view autoscaling, inspect nodes, and apply resource limits for cost optimization.

Process Table

Step	Command/Action	Evaluation	Result/Effect
1	kubectl top pods	Check current CPU and memory usage per pod	Shows pods with low usage but high requests
2	Identify overprovisioned pods	Compare usage vs requests/limits	Found pods requesting more than needed
3	Edit resource-limits.yaml	Set realistic requests and limits	Pods will request less CPU/memory
4	kubectl apply -f resource-limits.yaml	Apply new resource settings	Pods restart with updated resource specs
5	kubectl get hpa	Check Horizontal Pod Autoscaler status	Shows scaling rules based on CPU usage
6	Adjust HPA thresholds	Set target CPU utilization to optimize scaling	Pods scale up/down efficiently
7	kubectl describe node	Review node types and usage	Identify underused nodes for downsizing
8	Scale down nodes or switch to cheaper types	Reduce cluster cost	Lower cloud provider charges
9	Monitor costs continuously	Use monitoring tools (e.g., Prometheus, Grafana)	Detect new inefficiencies
10	Repeat optimization cycle	Keep costs minimal over time	Sustained cost savings
Exit	No more overprovisioning or scaling inefficiencies	Cost optimized cluster	Optimization complete

💡 No more overprovisioning or scaling inefficiencies detected, cost optimization achieved

Status Tracker

Variable	Start	After Step 3	After Step 6	After Step 8	Final
Pod CPU Requests	High (e.g., 500m)	Reduced (e.g., 250m)	Same	Same	Optimized
Pod Memory Requests	High (e.g., 1Gi)	Reduced (e.g., 512Mi)	Same	Same	Optimized
Number of Pods	Fixed	Fixed	Scaled by HPA	Scaled by HPA	Efficient scaling
Node Count	High	High	High	Reduced	Right-sized
Cluster Cost	High	Lower	Lower	Lowest	Minimized

Key Moments - 3 Insights

Why do we reduce pod resource requests instead of just deleting pods?

Reducing requests avoids wasting resources while keeping pods running smoothly, as shown in step 3 and 4 where resource limits are adjusted and applied.

How does autoscaling help with cost optimization?

Autoscaling adjusts the number of pods based on actual load, preventing overprovisioning. This is clear in step 5 and 6 where HPA status is checked and thresholds adjusted.

Why is monitoring node usage important for cost savings?

Monitoring nodes helps identify underused or expensive nodes to downsize or replace, reducing costs as seen in step 7 and 8.

Visual Quiz - 3 Questions

Look at the execution table, what happens at step 4 after applying resource limits?

A Nodes are scaled down immediately

B Pods are deleted permanently

C Pods restart with updated resource specs

D Autoscaler is disabled

💡 Hint

Check the 'Result/Effect' column for step 4 in the execution table

At which step does the Horizontal Pod Autoscaler get adjusted to optimize scaling?

A Step 3

B Step 6

C Step 8

D Step 10

💡 Hint

Look at the 'Command/Action' column for adjusting HPA thresholds

If pod CPU requests were not reduced at step 3, how would the cluster cost likely change?

A Costs would increase due to overprovisioning

B Costs would stay the same

C Costs would decrease due to fewer pods

D Costs would be unpredictable

💡 Hint

Refer to variable_tracker showing pod CPU requests and cluster cost changes

Concept Snapshot

Cost optimization in Kubernetes:
- Analyze pod resource usage with 'kubectl top pods'
- Adjust pod resource requests and limits realistically
- Use Horizontal Pod Autoscaler (HPA) for dynamic scaling
- Choose efficient node types and scale nodes accordingly
- Continuously monitor and repeat optimization for savings

Full Transcript

Cost optimization in Kubernetes involves checking current pod resource usage, identifying pods that request more CPU or memory than they actually use, and adjusting those requests and limits to realistic values. Then, autoscaling is configured to add or remove pods based on actual demand, preventing waste. Nodes are reviewed to ensure they are the right size and type for the workload, scaling down or switching to cheaper options when possible. Continuous monitoring helps catch new inefficiencies so the process can repeat, keeping costs low over time.

Practice

1. What is the main purpose of setting resource requests and limits on Kubernetes pods for cost optimization?

easy

A. To disable autoscaling features in the cluster

B. To control how much CPU and memory a pod can use, preventing waste

C. To increase the number of pods running simultaneously

D. To allow pods to use unlimited resources

Solution

1. Step 1: Understand resource requests and limits

   Requests define minimum resources a pod needs; limits set maximum usage.

2. Step 2: Link resource control to cost optimization

   By setting these, Kubernetes schedules pods efficiently and avoids resource waste.

3. Final Answer:

   To control how much CPU and memory a pod can use, preventing waste -> Option B

4. Quick Check:

   Resource limits prevent waste = C [OK]

Hint: Requests and limits control pod resource use to save costs [OK]

Common Mistakes:

• Thinking limits increase pod count
• Confusing requests with autoscaling
• Assuming unlimited resources save money

2. Which of the following is the correct YAML snippet to set a CPU request of 500m and a memory limit of 256Mi for a container in Kubernetes?

easy

A. resources:\n requests:\n cpu: '500m'\n limits:\n memory: '256Mi'

B. resources:\n limits:\n cpu: '500m'\n requests:\n memory: '256Mi'

C. resources:\n requests:\n cpu: 500\n memory: 256

D. resources:\n requests:\n cpu: '0.5'\n limits:\n memory: '256MB'

Solution

1. Step 1: Check correct YAML structure for resources

   Requests and limits must be under resources, with proper indentation and units.

2. Step 2: Validate units and order

   CPU request '500m' means 0.5 CPU; memory limit '256Mi' is correct unit. resources:\n requests:\n cpu: '500m'\n limits:\n memory: '256Mi' matches this.

3. Final Answer:

   resources:\n requests:\n cpu: '500m'\n limits:\n memory: '256Mi' -> Option A

4. Quick Check:

   Correct YAML with proper units = B [OK]

Hint: Requests before limits, use 'm' for CPU and 'Mi' for memory [OK]

Common Mistakes:

• Swapping requests and limits
• Using wrong units like 'MB' instead of 'Mi'
• Omitting quotes around values

3. Given this Horizontal Pod Autoscaler (HPA) YAML snippet:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 2
  maxReplicas: 5
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

What happens when CPU usage exceeds 50%?

medium

A. Pods restart automatically

B. The number of pods decreases to 2 to save cost

C. The number of pods increases up to 5 to handle load

D. CPU limits are increased automatically

Solution

1. Step 1: Understand HPA behavior with CPU utilization

   HPA increases pod count when average CPU usage exceeds target utilization (50%).

2. Step 2: Check min and max replicas

   Pods scale between 2 and 5 replicas based on load; exceeding 50% triggers scaling up.

3. Final Answer:

   The number of pods increases up to 5 to handle load -> Option C

4. Quick Check:

   CPU > 50% triggers scale up = A [OK]

Hint: HPA scales pods up when CPU usage exceeds target [OK]

Common Mistakes:

• Thinking pods scale down on high CPU
• Assuming pods restart on high CPU
• Believing CPU limits auto-increase

4. You notice your Kubernetes cluster is overspending because pods are not scaling down after load decreases. Which is the most likely cause?

medium

A. CPU requests are set higher than limits

B. Resource limits are set too low

C. Pods have no readinessProbe configured

D. The Horizontal Pod Autoscaler has a high minReplicas value

Solution

1. Step 1: Analyze autoscaling parameters

   A high minReplicas prevents scaling below that number, causing overspending.

2. Step 2: Evaluate other options

   Low limits or readiness probes don't directly prevent scaling down; CPU requests > limits is invalid.

3. Final Answer:

   The Horizontal Pod Autoscaler has a high minReplicas value -> Option D

4. Quick Check:

   High minReplicas blocks scale down = A [OK]

Hint: Check minReplicas to allow scaling down [OK]

Common Mistakes:

• Confusing limits with requests
• Ignoring minReplicas effect
• Assuming readinessProbe affects scaling

5. You want to optimize costs by automatically scaling your Kubernetes cluster nodes based on pod resource usage. Which combination of tools and settings should you use?

hard

A. Cluster Autoscaler with properly set pod resource requests and limits

B. Manual node scaling with no pod resource limits

C. Disable Horizontal Pod Autoscaler and increase node count permanently

D. Set pod resource limits to zero and rely on node autoscaling

Solution

1. Step 1: Understand cluster autoscaling

   Cluster Autoscaler adjusts node count based on pod scheduling needs and resource requests.

2. Step 2: Importance of pod resource requests and limits

   Proper requests and limits let the autoscaler know actual resource needs to scale nodes efficiently.

3. Step 3: Evaluate other options

   Manual scaling wastes resources; disabling HPA or zero limits causes inefficiency or errors.

4. Final Answer:

   Cluster Autoscaler with properly set pod resource requests and limits -> Option A

5. Quick Check:

   Autoscaler + resource requests = cost savings [OK]

Hint: Use Cluster Autoscaler plus pod requests/limits for best cost control [OK]

Common Mistakes:

• Relying on manual scaling only
• Disabling autoscaling features
• Setting resource limits to zero