https://drive.google.com/file/d/16snilNvcm5kKAWoRmJy0ub-xajEUTnIY/view?usp=sharing

🔍 YAML Breakdown

apiVersion: v1
kind: Pod
meta
  name: nnwebserver
spec:
  containers:
    - name: nnwebserver
      image: nginx
      resources:
        requests:        # ← Minimum guaranteed resources
          cpu: "500m"    # = 0.5 CPU core
          memory: "128Mi" # = 128 Mebibytes
        limits:          # ← Maximum allowed resources
          cpu: "1000m"   # = 1.0 CPU core
          memory: "256Mi" # = 256 Mebibytes
      ports:
        - containerPort: 80
          name: http
          protocol: TCP

📌 Core Concepts: requests vs limits

Term Meaning Used By What Happens If Exceeded?
requests Guaranteed minimum resources the container needs to start. Kubernetes Scheduler → decides which node can run this Pod. ✅ Never exceeded by scheduler — Pod won’t be placed on a node without enough free requests.
limits Hard ceiling — container cannot use more than this. Kubelet + Container Runtime (e.g., containerd) - CPU: Throttled (slowed down)<br>- Memory: OOMKilled (Pod crashes!)

💡 Units Explained:

✅ Best Practice:

Always set both requests and limits in production.

Without them, your Pod is BestEffort (lowest priority, first to be evicted!).

🔍 How Kubernetes Uses This

  1. Scheduling:

    Scheduler checks: "Does any node have ≥500m CPU and ≥128Mi free memory?"

    → Only then places the Pod.

  2. Runtime Enforcement:

  3. QoS Class:

    Because requests ≠ limits (CPU: 500m ≠ 1000m), this Pod is Burstable (medium priority).

🎯 Goal: Prevent one noisy app from starving others on the same node.

🧪 Lab: Deploy & Observe Resource Behavior

🔧 Part 1: Deploy the Pod

# Apply the Pod
kubectl apply -f pod-with-resource-limits.yml

# Check status
kubectl get pods

# Describe to see resources + QoS class
kubectl describe pod nnwebserver | grep -A 5 -B 2 "Limits\\\\|QoS"

✅ Expected Output:

Limits:
  cpu:     1
  memory:  256Mi
Requests:
  cpu:     500m
  memory:  128Mi
QoS Class: Burstable