Backend interview prep

Start Learning

OpenShift Cost Optimization

Learn how to optimize infrastructure costs for Spring Boot applications running on OpenShift. Understand resource requests and limits, autoscaling, right-sizing, node utilization, storage optimization, monitoring, and enterprise cost optimization strategies.

Introduction

Running applications in the cloud provides flexibility and scalability, but without proper planning it can also lead to unnecessary infrastructure costs.

Consider an enterprise running:

  • 250 Spring Boot microservices
  • 600 Pods
  • 50 Worker Nodes
  • Multiple Development, QA, UAT, and Production environments

If every application is allocated more CPU and memory than required, infrastructure costs increase significantly.

For example:

  • Application uses 300m CPU
  • Requested 2 CPU
  • 85% of CPU remains unused

Multiply this across hundreds of services and the organization wastes thousands of dollars every month.

Cost optimization ensures applications consume only the resources they actually need while maintaining performance and availability.

Learning Objectives

By the end of this article, you will understand:

  • Why Cost Optimization Matters
  • OpenShift Resource Management
  • CPU & Memory Requests
  • Resource Limits
  • Horizontal Pod Autoscaler
  • Cluster Autoscaler
  • Right Sizing
  • Storage Optimization
  • Enterprise FinOps Best Practices

Why Cost Optimization?

Without optimization:

  • Low node utilization
  • High cloud bills
  • Idle resources
  • Over-provisioned Pods
  • Wasted storage
  • Unused worker nodes

Goal:

Deliver the same performance using fewer resources.

Cost Optimization Architecture

flowchart LR
    A[Spring Boot Applications]
    B[Resource Requests]
    C[Autoscaling]
    D[Worker Nodes]
    E[Cloud Cost]

    A --> B
    B --> C
    C --> D
    D --> E

Resource Allocation

flowchart LR
    A[Pod]

    B[CPU Request]

    C[Memory Request]

    D[CPU Limit]

    E[Memory Limit]

    A --> B
    A --> C
    A --> D
    A --> E

Every Pod should have properly configured resource requests and limits.

Resource Requests

Requests define the minimum guaranteed resources.

Example

resources:

  requests:

    cpu: "500m"

    memory: "512Mi"

Resource Limits

Limits prevent applications from consuming excessive resources.

resources:

  limits:

    cpu: "1"

    memory: "1024Mi"

Right Sizing

Poor configuration

CPU Request

4 Core

Actual Usage

500m

Optimized configuration

CPU Request

600m

Actual Usage

500m

CPU Utilization

flowchart LR
    A[Application]
    B[CPU Usage]
    C[Prometheus]
    D[Optimization]

    A --> B
    B --> C
    C --> D

Use historical metrics before adjusting requests.

Memory Optimization

Applications should allocate memory based on actual JVM usage.

Avoid:

  • Oversized JVM heap
  • Large container limits
  • Memory waste

JVM Memory Example

Container Memory

2 GB

JVM Heap

512 MB

The remaining memory is largely unused.

Autoscaling

Horizontal Pod Autoscaler improves both performance and cost.

flowchart LR
    A[Traffic]
    B[HPA]
    C[Scale Pods]

    A --> B
    B --> C

During low traffic:

Pods are automatically removed.

Cluster Autoscaler

flowchart LR
    A[HPA]
    B[Cluster Autoscaler]
    C[Worker Nodes]

    A --> B
    B --> C

If Pods decrease:

Unused worker nodes can also be removed.

Resource Monitoring

Use Prometheus to monitor:

  • CPU
  • Memory
  • Disk
  • Network
  • JVM Heap
  • Thread Count
flowchart LR
    A[Spring Boot]
    B[Prometheus]
    C[Grafana]

    A --> B
    B --> C

Idle Resources

Typical enterprise clusters contain:

  • Unused Deployments
  • Idle Namespaces
  • Stopped Projects
  • Old Images
  • Unused PVCs

Cleaning these regularly reduces costs.

Storage Optimization

Avoid:

  • Large Persistent Volumes
  • Unused PVCs
  • Duplicate container images
flowchart LR
    A[Persistent Volumes]
    B[Unused Storage]
    C[Cleanup]

    A --> B
    B --> C

Image Optimization

Large container images increase:

  • Storage
  • Network traffic
  • Deployment time

Good practices:

  • Multi-stage builds
  • Distroless images
  • Remove unnecessary packages

Node Utilization

flowchart LR
    A[Worker Node]

    B[Pod]

    C[Pod]

    D[Pod]

    A --> B
    A --> C
    A --> D

Aim for balanced utilization across nodes.

Namespace Quotas

Prevent one team from consuming excessive resources.

Example

hard:

  requests.cpu: "20"

  requests.memory: "40Gi"

LimitRange

Provide default limits.

kind: LimitRange

Ensures every Pod receives reasonable defaults.

Enterprise Banking Example

flowchart TD
    A[Banking Applications]

    B[Payments]

    C[Loans]

    D[Cards]

    E[Prometheus]

    F[Grafana]

    G[Cost Dashboard]

    A --> B
    A --> C
    A --> D

    B --> E
    C --> E
    D --> E

    E --> F
    F --> G

Operations teams monitor both performance and infrastructure costs.

Cost Optimization Workflow

flowchart LR
    A[Collect Metrics]
    B[Analyze Usage]
    C[Adjust Requests]
    D[Deploy]
    E[Monitor Again]

    A --> B
    B --> C
    C --> D
    D --> E

Optimization is an ongoing process.

Useful Commands

View Resource Usage

oc adm top pods

View Node Usage

oc adm top nodes

View Resource Quotas

oc get resourcequota

View LimitRanges

oc get limitrange

List PVCs

oc get pvc

Common Problems

Over-Provisioned Pods

Symptoms:

  • Low CPU utilization
  • High cloud costs

Solution:

Reduce requests after analyzing metrics.

Under-Provisioned Pods

Symptoms:

  • CPU throttling
  • Frequent restarts
  • Slow response times

Solution:

Increase requests or enable autoscaling.

Unused Storage

Review and remove:

  • Old PVCs
  • Old snapshots
  • Unused images

Idle Clusters

Development clusters often remain unused overnight or on weekends.

Consider automated shutdown schedules where appropriate.

Production Best Practices

  • Define requests and limits for every Pod.
  • Use Prometheus to analyze resource utilization.
  • Enable Horizontal Pod Autoscaler.
  • Enable Cluster Autoscaler.
  • Right-size JVM heap.
  • Clean unused images regularly.
  • Remove unused Persistent Volumes.
  • Configure ResourceQuotas and LimitRanges.
  • Monitor cloud spending monthly.
  • Adopt FinOps practices across teams.

Common Mistakes

❌ No resource requests.

❌ Unlimited memory usage.

❌ Oversized JVM heap.

❌ Scaling only based on CPU.

❌ Keeping unused namespaces.

❌ Ignoring storage costs.

Advantages

  • Lower cloud costs
  • Better resource utilization
  • Improved cluster efficiency
  • Faster deployments
  • Higher node density
  • Better scalability
  • Reduced waste
  • Enterprise-ready FinOps

Summary

Cost optimization is not about reducing infrastructure blindly—it is about delivering the required performance with the minimum necessary resources.

Key takeaways:

  • Configure CPU and memory requests appropriately.
  • Use resource limits to prevent resource contention.
  • Enable Horizontal Pod Autoscaler and Cluster Autoscaler.
  • Continuously monitor utilization with Prometheus and Grafana.
  • Remove unused workloads and storage.
  • Combine technical optimization with FinOps practices for sustainable cloud spending.

Interview Questions

  1. Why is cost optimization important in OpenShift?
  2. What is the difference between resource requests and limits?
  3. How does HPA help reduce infrastructure costs?
  4. What is the purpose of Cluster Autoscaler?
  5. Why should JVM heap be right-sized?
  6. What is a ResourceQuota?
  7. What is a LimitRange?
  8. How do you identify over-provisioned applications?
  9. Why should Prometheus be used for cost optimization?
  10. What are the production best practices for OpenShift cost optimization?