Bird
Raised Fist0
Kubernetesdevops~30 mins

Cost optimization in Kubernetes - Mini Project: Build & Apply

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Cost optimization in Kubernetes
📖 Scenario: You are managing a Kubernetes cluster for a small company. The company wants to reduce cloud costs by optimizing resource usage of pods running in the cluster.You will create a simple Kubernetes pod manifest, add resource requests and limits, and then check the pod's resource usage to ensure cost optimization.
🎯 Goal: Build a Kubernetes pod manifest with resource requests and limits to optimize cost and ensure efficient resource usage.
📋 What You'll Learn
Create a pod manifest YAML file named cost-optimized-pod.yaml with a container named app-container running the image nginx:latest.
Add resource requests and limits for CPU and memory in the container spec.
Use kubectl commands to apply the manifest and check the pod's resource usage.
Print the pod's resource usage summary.
💡 Why This Matters
🌍 Real World
Cloud providers charge based on resource usage. Setting resource requests and limits in Kubernetes helps control costs by preventing pods from using more resources than needed.
💼 Career
DevOps engineers and site reliability engineers often optimize Kubernetes workloads to reduce cloud expenses while maintaining performance and reliability.
Progress0 / 4 steps
1
Create the initial pod manifest
Create a YAML file named cost-optimized-pod.yaml with a pod named cost-optimizer that has one container named app-container running the image nginx:latest. Include the apiVersion, kind, and metadata fields as shown.
Kubernetes
Hint

Remember to include apiVersion, kind, metadata, and spec sections in your YAML.

2
Add resource requests and limits
In the cost-optimized-pod.yaml file, add resource requests and limits under the container app-container. Set CPU request to 100m, CPU limit to 200m, memory request to 128Mi, and memory limit to 256Mi.
Kubernetes
Hint

Indent resource requests and limits correctly under the container spec.

3
Apply the pod manifest to the cluster
Use the kubectl apply -f cost-optimized-pod.yaml command to create the pod in the Kubernetes cluster.
Kubernetes
Hint

Use kubectl apply -f cost-optimized-pod.yaml to create or update the pod.

4
Check and print pod resource usage
Run the command kubectl top pod cost-optimizer to display the CPU and memory usage of the pod. Then print the output exactly as shown.
Kubernetes
Hint

Use kubectl top pod cost-optimizer to see current CPU and memory usage.

Practice

(1/5)
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