Live For Yourself, Not For Others – This video shares a sharp mindset framework to help you stay focused, block out noise, and make bold moves for yourself.

A must watch to build a bulletproof mind.

🛠️ TOOL OF THE DAY

Teller - A cloud native secrets management tool to manage secrets directly from the command line, connecting to vaults and cloud services like Hashicorp Vault and AWS Secrets Manager.

🧠 USE CASE

Kubernetes Resource Limits Simplified

Most people underestimate how much CPU and memory settings affect node pressure, eviction policies, and overall application performance. I did too, until a few bad deployments made it clear.

This visual breaks it down better than docs ever could.

Download a high resolution copy of this diagram here for future reference.

Here’s what each class actually means:

1. No Limits, No Class

If you skip both requests and limits, your pod gets no QoS class. It can consume all available CPU, but it will be the first to get evicted under pressure.

I have seen pods disappear middebug without any warning.

Command to identify:

kubectl get pod <pod-name> -o jsonpath="{.status.qosClass}"

Where I use it? Never in production. Sometimes in dev jobs or pre-merge preview builds.

2. Guaranteed Class

When both requests and limits are set and equal, you get the Guaranteed class. This ensures the pod always gets the exact resources it needs and is the last to be evicted.

resources:
  requests:
    cpu: "500m"
    memory: "512Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

Ideal for stateful workloads like databases or message brokers. But if used everywhere, it leads to over provisioned clusters and higher costs.

3. Burstable Class

When requests are set and limits are higher, the pod can burst when extra capacity is available.

resources:
  requests:
    cpu: "500m"
    memory: "512Mi"
  limits:
    cpu: "1000m"
    memory: "1Gi"

This is how I run most stateless services. You get fairness during contention and flexibility when the node is underused. It strikes the right balance between stability and cost.

4. BestEffort Class

No requests or limits puts you in BestEffort. These pods only get CPU if nothing else needs it.

Use this only for non critical workloads like preview environments or test jobs.

Common mistake: People forget to define requests, thinking it's optional. But without it, HPA (Horizontal Pod Autoscaler) doesn’t work as expected.

My 2 Cents:

Always set requests to make sure pods get scheduled fairly.
Use limits only when needed. Overusing them can choke performance.
Stick with Burstable unless you absolutely need Guaranteed.
Avoid BestEffort in anything user-facing or persistent.

If you’re troubleshooting performance issues, check your pod’s QoS class first. It often tells you what went wrong.

Looking to promote your company, product, service, or event to 45,000+ Cloud Native Professionals? Let's work together.