Kubernetes Cost Control: Your FinOps Guide

Kubernetes Cost Management and FinOps: A Comprehensive Guide

Kubernetes has become the de facto standard for deploying and managing containerized applications at scale. Its power lies in its ability to abstract away infrastructure complexities, enable rapid deployment, and provide unparalleled resilience. However, this very abstraction, coupled with dynamic resource allocation and diverse workloads, can quickly turn into a significant financial challenge. Organizations often find themselves grappling with unexpectedly high cloud bills, struggling to attribute costs accurately, and lacking visibility into their Kubernetes spend.

The rise of Kubernetes FinOps addresses this critical need. FinOps, short for “Cloud Financial Operations,” is an evolving cultural practice that brings financial accountability to the variable spend model of the cloud. When applied to Kubernetes, FinOps combines best practices, tools, and a collaborative approach between engineering, finance, and product teams to maximize business value by helping organizations understand and manage their Kubernetes costs more effectively. This guide will walk you through the essential strategies, tools, and practices to implement a robust FinOps framework for your Kubernetes environments.

# Example: Resource Requests & Limits
resources:
  requests:
    memory: "64Mi"
    cpu: "250m"
  limits:
    memory: "128Mi"
    cpu: "500m"
    

# Install Kubecost (example)
helm repo add kubecost https://kubecost.github.io/cost-analyzer/
helm install kubecost kubecost/cost-analyzer --namespace kubecost --create-namespace
    

Prerequisites

To effectively follow this guide and implement Kubernetes FinOps, you should have:

• Basic Kubernetes Knowledge: Familiarity with Kubernetes concepts like Pods, Deployments, Services, Namespaces, and Resource Requests/Limits.
• kubectl Installed and Configured: The Kubernetes command-line tool, connected to your cluster. You can find installation instructions in the official Kubernetes documentation.
• Helm Installed: The package manager for Kubernetes, essential for deploying many cost management tools. Refer to the Helm installation guide.
• Cloud Provider Account: (AWS, GCP, Azure) where your Kubernetes cluster is running, with appropriate administrative access to provision resources and view billing.
• Monitoring Stack: A basic understanding of how to collect metrics (e.g., Prometheus) is beneficial for right-sizing.

Step-by-Step Guide: Implementing Kubernetes FinOps

1. Step 1: Gain Visibility with Cost Allocation Tools

   The first rule of FinOps is: you can’t optimize what you can’t see. Understanding where your money is going is paramount. Kubernetes’ dynamic nature makes this challenging, as resources are shared and constantly reallocated. Dedicated cost allocation tools integrate with your cluster and cloud provider to break down costs by namespace, deployment, service, label, and even individual pods, providing invaluable insights.

   We’ll use OpenCost as an example. OpenCost is a CNCF Sandbox project providing real-time cost visibility and allocation. It integrates with Prometheus and your cloud provider to give you a clear picture of your spend.

   
   # 1. Add the OpenCost Helm repository
   helm repo add opencost https://opencost.github.io/opencost-helm-chart/
   helm repo update
   
   # 2. Install OpenCost into its own namespace
   # Replace  with "aws", "azure", or "gcp" as appropriate.
   # Ensure you have configured cloud provider credentials for OpenCost to access billing data.
   # For AWS, this often involves an IAM role for the service account.
   helm install opencost opencost/opencost -n opencost --create-namespace \
     --set cloudProvider..enabled=true
           

   Explanation: This command adds the OpenCost Helm chart repository and then installs OpenCost into a new namespace called `opencost`. The crucial part is setting the `cloudProvider..enabled=true` flag. This tells OpenCost to integrate with your specific cloud provider’s billing APIs to fetch actual pricing data for your resources (VMs, storage, network, etc.). Without this, OpenCost can only estimate based on default pricing.

   For detailed cloud provider integration, refer to the OpenCost documentation.

   Verify

   Check if the OpenCost pods are running and then access the UI.

   
   # Verify OpenCost pods are running
   kubectl get pods -n opencost
   
   # Expected Output (may vary slightly)
   NAME                            READY   STATUS    RESTARTS   AGE
   opencost-7b9c7b9c7d-abcde       1/1     Running   0          2m
   opencost-grafana-7c7c7c7c7-fghij 1/1     Running   0          2m
   opencost-prometheus-server-ijk 1/1     Running   0          2m
   
   # Port-forward to access the OpenCost UI (default port 9090)
   kubectl port-forward -n opencost svc/opencost 9090:9090
           

   Now, open your browser to http://localhost:9090. You should see the OpenCost dashboard, providing a breakdown of your cluster costs. This initial visibility is the cornerstone of any FinOps initiative.

2. Step 2: Implement Resource Requests and Limits

   One of the most fundamental and impactful cost-saving measures in Kubernetes is correctly configuring resource requests and limits for your pods. Requests guarantee a minimum amount of resources (CPU, memory) for a container, allowing the scheduler to place it on a node where these resources are available. Limits, on the other hand, cap the maximum resources a container can consume.

   Misconfigured requests (too high) lead to over-provisioning and wasted resources. Misconfigured limits (too low) can cause performance issues or evictions. The sweet spot is to set requests based on actual observed usage and limits slightly above requests to allow for bursts.

   
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: my-app
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: my-app
     template:
       metadata:
         labels:
           app: my-app
       spec:
         containers:
         - name: my-container
           image: nginx:latest
           resources:
             requests:
               memory: "64Mi"
               cpu: "250m" # 0.25 CPU core
             limits:
               memory: "128Mi"
               cpu: "500m" # 0.5 CPU core
           ports:
           - containerPort: 80
           

   Explanation: In this `Deployment` manifest, we’ve defined `resources.requests` and `resources.limits` for the `my-container`. The container will request 64 MiB of memory and 0.25 CPU cores, guaranteeing it those resources. It will be capped at 128 MiB of memory and 0.5 CPU cores. This prevents a single misbehaving container from consuming all node resources and ensures efficient scheduling.

   Verify

   Apply the deployment and then inspect its resource configuration.

   
   # Apply the deployment
   kubectl apply -f my-app-deployment.yaml
   
   # Get the deployment details
   kubectl describe deployment my-app
   
   # Expected Output (snippet)
   ...
   Containers:
     my-container:
       Image:        nginx:latest
       Port:         80/TCP
       Host Port:    0/TCP
       Limits:
         cpu:     500m
         memory:  128Mi
       Requests:
         cpu:     250m
         memory:  64Mi
   ...
           

   The `Limits` and `Requests` sections confirm that your resource specifications have been applied. Regularly reviewing and adjusting these based on actual application performance metrics is a continuous FinOps task. Tools like Vertical Pod Autoscaler (VPA) can help automate this process by recommending optimal resource settings.

3. Step 3: Leverage Autoscaling (HPA & Cluster Autoscaler)

   Static resource provisioning is inherently inefficient. Applications often experience fluctuating demand. Kubernetes offers powerful autoscaling mechanisms to dynamically adjust the number of pods and nodes based on actual load, preventing both over-provisioning (wasted money) and under-provisioning (poor performance).

   • Horizontal Pod Autoscaler (HPA): Scales the number of pod replicas up or down based on observed CPU utilization, memory usage, or custom metrics.
   • Cluster Autoscaler: Scales the number of nodes in your cluster up or down. It adds nodes when pods are pending due to insufficient resources and removes nodes when they are underutilized.

   
   # hpa-example.yaml
   apiVersion: autoscaling/v2
   kind: HorizontalPodAutoscaler
   metadata:
     name: my-app-hpa
   spec:
     scaleTargetRef:
       apiVersion: apps/v1
       kind: Deployment
       name: my-app # Target the deployment created in Step 2
     minReplicas: 1
     maxReplicas: 10
     metrics:
     - type: Resource
       resource:
         name: cpu
         target:
           type: Utilization
           averageUtilization: 50 # Target 50% average CPU utilization
     - type: Resource
       resource:
         name: memory
         target:
           type: AverageValue
           averageValue: 80Mi # Target 80MiB average memory usage
           

   Explanation: This HPA configuration targets the `my-app` deployment. It will ensure that the deployment has at least 1 pod and at most 10. The HPA will scale up if the average CPU utilization across all pods exceeds 50% or if the average memory usage exceeds 80MiB. This dynamic scaling ensures you’re only paying for the resources you need at any given moment.

   For more advanced autoscaling scenarios, explore our guide on LLM GPU Scheduling Guide, which often involves specific resource-based scaling considerations for specialized workloads.

   Verify

   Apply the HPA and check its status.

   
   # Apply the HPA
   kubectl apply -f hpa-example.yaml
   
   # Check HPA status
   kubectl get hpa my-app-hpa
   
   # Expected Output (initially, current replicas will match desired, then scale based on load)
   NAME         REFERENCE       TARGETS                       MINPODS   MAXPODS   REPLICAS   AGE
   my-app-hpa   Deployment/my-app   <unknown>/50%, <unknown>/80Mi   1         10        3          2m # <unknown> until metrics server collects data
   # After some time and load:
   NAME         REFERENCE       TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
   my-app-hpa   Deployment/my-app   25%/50%, 60Mi/80Mi   1         10        3          5m
           

   The `TARGETS` column will eventually show the current CPU utilization and memory usage against your defined targets. To test it, you could introduce load to your `my-app` and observe the HPA scaling up the number of replicas.

   For Cluster Autoscaler, its deployment and configuration are typically part of your cloud provider’s Kubernetes service (EKS, GKE, AKS) or deployed via Helm. Refer to the Cluster Autoscaler GitHub repository for specific installation instructions for your cloud.

4. Step 4: Optimize Node Provisioning with Karpenter

   Traditional cluster autoscalers often struggle with diverse workloads and can be slow to provision optimal nodes. Karpenter Cost Optimization is an open-source, high-performance Kubernetes cluster autoscaler built by AWS. It observes pending pods and launches right-sized compute resources in response, often provisioning nodes significantly faster and more cost-effectively than traditional autoscalers.

   Karpenter works by directly interfacing with your cloud provider’s compute services (e.g., EC2 for AWS) to provision nodes that precisely match the aggregate resource requests of pending pods. It also has advanced features like consolidation, which identifies underutilized nodes and de-schedules pods to optimize node usage, and support for spot instances.

   
   # This is a conceptual example for AWS. Actual installation involves IAM roles and NodePools.
   # 1. Install Karpenter (requires a service account with specific IAM permissions)
   # Follow the official Karpenter installation guide for your cloud provider:
   # https://karpenter.sh/docs/getting-started/
   helm upgrade --install karpenter oci://public.ecr.aws/karpenter/karpenter --version <LATEST_VERSION> \
     --namespace karpenter --create-namespace \
     --set serviceAccount.create=false \
     --set serviceAccount.name=karpenter \
     --set settings.aws.clusterName=<YOUR_CLUSTER_NAME> \
     --set settings.aws.defaultInstanceProfile=<YOUR_INSTANCE_PROFILE_NAME> \
     --wait # Wait for the deployment to complete
   
   # 2. Define a NodePool (example for AWS)
   # Save this as karpenter-nodepool.yaml
           

   
   apiVersion: karpenter.k8s.aws/v1beta1
   kind: NodePool
   metadata:
     name: default
   spec:
     template:
       spec:
         requirements:
           - key: kubernetes.io/arch
             operator: In
             values: ["amd64"]
           - key: kubernetes.io/os
             operator: In
             values: ["linux"]
           - key: karpenter.sh/capacity-type # Leverage spot instances for cost savings
             operator: In
             values: ["on-demand", "spot"]
           - key: karpenter.k8s.aws/instance-category
             operator: In
             values: ["c", "m", "r"] # Allow different instance types
           - key: karpenter.k8s.aws/instance-family
             operator: In
             values: ["c5", "m5", "r5"] # Example instance families
         nodeClassRef:
           name: default # Refers to a provisioner-managed EC2NodeClass
     limits:
       cpu: "1000" # Max total CPU for nodes provisioned by this NodePool
     disruption:
       consolidationPolicy: WhenUnderutilized
       expireAfter: 720h # Nodes expire after 30 days
           

   Explanation: This `NodePool` manifest instructs Karpenter on what kind of nodes it can provision. It specifies architectural and OS requirements, crucially allowing `spot` instances for potential cost savings. It also defines instance categories and families, giving Karpenter flexibility to choose the most cost-effective option. The `disruption` section enables consolidation and node expiration, further enhancing cost efficiency.

   Verify

   Apply the NodePool and then deploy a pod that requires more resources than currently available, watching Karpenter provision a new node.

   
   # Apply the NodePool
   kubectl apply -f karpenter-nodepool.yaml
   
   # Watch Karpenter logs (in a separate terminal)
   kubectl logs -f -n karpenter -l app.kubernetes.io/name=karpenter
   
   # Deploy a large pod to trigger Karpenter
   # Save this as large-pod.yaml
           

   
   apiVersion: v1
   kind: Pod
   metadata:
     name: large-resource-pod
     labels:
       app: large-app
   spec:
     containers:
     - name: heavy-container
       image: busybox
       command: ["sh", "-c", "sleep 3600"]
       resources:
         requests:
           memory: "4Gi"
           cpu: "2"
         limits:
           memory: "4Gi"
           cpu: "2"
     affinity:
       nodeAffinity:
         requiredDuringSchedulingIgnoredDuringExecution:
           nodeSelectorTerms:
           - matchExpressions:
             - key: karpenter.sh/nodepool
               operator: Exists # Ensure it lands on a Karpenter-managed node
           

   
   # Apply the large pod
   kubectl apply -f large-pod.yaml
   
   # Watch for new nodes
   kubectl get nodes --watch
           

   You should observe Karpenter logs indicating it’s provisioning a new node, and `kubectl get nodes –watch` will show a new node appearing. Karpenter’s efficiency in right-sizing and using spot instances can lead to significant cost reductions.

5. Step 5: Leverage Spot Instances and Savings Plans/Reserved Instances

   Cloud providers offer various pricing models. Spot Instances (AWS EC2 Spot, GCP Preemptible VMs, Azure Spot VMs) are significantly cheaper (up to 90% off on-demand prices) but can be interrupted with short notice. They are ideal for fault-tolerant, stateless, or batch workloads.

   For stable, long-running workloads, Savings Plans (AWS), Committed Use Discounts (GCP), or Reserved Instances (AWS, Azure) offer substantial discounts (20-70%) in exchange for a commitment to use a certain amount of compute over 1 or 3 years. Integrating these into your FinOps strategy requires careful forecasting but yields massive savings.

   Karpenter, as demonstrated in the previous step, makes using spot instances much easier by automatically provisioning them when appropriate. For managing Savings Plans or Reserved Instances, this is typically done at the cloud provider account level, outside of Kubernetes, but its impact on your overall bill is profound.

   
   # Example: Pod with a toleration for spot instance node taints (if not using Karpenter)
   # If your nodes are tainted to identify them as spot instances, your pods need to tolerate it.
   # Karpenter handles this automatically, but it's good to know.
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: spot-tolerant-app
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: spot-tolerant-app
     template:
       metadata:
         labels:
           app: spot-tolerant-app
       spec:
         tolerations:
         - key: "kubernetes.azure.com/scalesetpriority" # Example for Azure Spot VM
           operator: "Equal"
           value: "spot"
           effect: "NoSchedule"
         - key: "karpenter.sh/capacity-type" # Example for Karpenter-provisioned spot nodes
           operator: "Equal"
           value: "spot"
           effect: "NoSchedule"
         containers:
         - name: my-container
           image: busybox
           command: ["sh", "-c", "sleep 3600"]
           resources:
             requests:
               memory: "100Mi"
               cpu: "100m"
           

   Explanation: This manifest shows how a `Deployment` can be configured with `tolerations` to allow its pods to run on nodes that have specific taints, such as those indicating they are spot instances. While Karpenter simplifies this by automatically matching pods to appropriate nodes, understanding tolerations is crucial for clusters where spot nodes might be manually tainted or managed by other autoscalers. This allows you to selectively deploy interruptible workloads to cheaper spot instances.

   Verify

   If you have spot nodes (either manually tainted or provisioned by Karpenter), you can verify that pods with appropriate tolerations are scheduled onto them.

   
   # Apply the spot-tolerant deployment
   kubectl apply -f spot-tolerant-app.yaml
   
   # Check where the pods are scheduled
   kubectl get pods -l app=spot-tolerant-app -o wide
   
   # Expected Output (Node column should show a spot instance node name)
   NAME                                  READY   STATUS    RESTARTS   AGE   IP           NODE                                       NOMINATED NODE   READINESS GATES
   spot-tolerant-app-7b9c7b9c7d-abcde    1/1     Running   0          2m    10.0.0.10    ip-10-0-0-10.ec2.internal # This would be a spot node
   spot-tolerant-app-7b9c7b9c7d-fghij    1/1     Running   0          2m    10.0.0.11    ip-10-0-0-11.ec2.internal
           

   The `NODE` column should indicate that your pods are running on nodes that are provisioned as spot instances. If you don’t have spot nodes, these pods will likely remain pending or be scheduled on on-demand nodes if they don’t have exclusive taints.

6. Step 6: Implement Cost Attribution with Labels and Namespaces

   Accurate cost attribution is vital for FinOps. It allows you to charge back costs to specific teams, projects, or applications, fostering accountability. Kubernetes labels and namespaces are your primary tools for this.

   • Namespaces: Naturally segment your cluster. You can dedicate namespaces to teams, environments (dev, staging, prod), or specific applications. Cost tools like OpenCost can easily break down costs by namespace.
   • Labels: Provide finer-grained categorization. You can label resources (pods, deployments, services, persistent volumes) with `team`, `project`, `environment`, `cost-center`, or `application` tags. These labels are then picked up by cost allocation tools.

   
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: analytics-service
     namespace: data-team # Dedicated namespace for the data team
     labels:
       app: analytics-engine
       team: data-engineering
       project: customer-insights
       environment: production
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: analytics-engine
     template:
       metadata:
         labels:
           app: analytics-engine
           team: data-engineering
           project: customer-insights
           environment: production
       spec:
         containers:
         - name: analytics-container
           image: custom-analytics-image:1.0
           resources:
             requests:
               memory: "1Gi"
               cpu: "1"
             limits:
               memory: "2Gi"
               cpu: "2"
           

   Explanation: This deployment is placed in the `data-team` namespace and is adorned with multiple labels. These labels (e.g., `team: data-engineering`, `project: customer-insights`) provide crucial metadata that cost allocation tools can use to slice and dice your expenses. This allows the finance team to understand exactly how much the “customer-insights” project run by the “data-engineering” team is costing in the “production” environment.

   Consider using Kubernetes Network Policies in conjunction with namespaces to further isolate and secure different teams’ workloads, which can also be a part of a broader FinOps security strategy.

   Verify

   Create the namespace and apply the deployment, then check its labels.

   
   # Create the namespace
   kubectl create namespace data-team
   
   # Apply the deployment
   kubectl apply -f analytics-service.yaml
   
   # Check the deployment's labels
   kubectl get deployment analytics-service -n data-team -o jsonpath='{.metadata.labels}'
   
   # Expected Output
   {"app":"analytics-engine","environment":"production","project":"customer-insights","team":"data-engineering"}
   
   # Check the pod's labels (should inherit from deployment template)
   kubectl get pods -n data-team -l app=analytics-engine -o jsonpath='{.items[0].metadata.labels}'
   
   # Expected Output
   {"app":"analytics-engine","environment":"production","project":"customer-insights","team":"data-engineering"}
           

   The output confirms that the labels are correctly applied to the deployment and its pods. Your cost allocation tool will now be able to use these labels for granular reporting.

7. Step 7: Clean Up Unused Resources

   One of the easiest ways to save money is to simply delete resources that are no longer needed. This includes stale deployments, abandoned namespaces, unattached Persistent Volumes (PVs), and Load Balancers or public IPs that are no longer serving traffic. While Kubernetes handles some garbage collection, manual oversight and automated policies are crucial.

   
   # Example: Identifying and deleting unused resources
   
   # 1. List all namespaces and identify any that are no longer active
   kubectl get namespaces
   
   # 2. For a suspicious namespace (e.g., "old-dev-env"), list its resources
   kubectl get all -n old-dev-env
   kubectl get pvc -n old-dev-env # Check for Persistent Volume Claims
   kubectl get ingress -n old-dev-env # Check for Ingresses (might provision LBs)
   kubectl get svc -n old-dev-env # Check for Services (type LoadBalancer)
   
   # 3. If confirmed unused, delete the namespace (this will delete all resources within it)
   # BE EXTREMELY CAREFUL WITH THIS COMMAND!
   # kubectl delete namespace old-dev-env
   
   # 4. Identify unattached Persistent Volumes (PVCs are gone, but PVs might persist depending on reclaim policy)
   # This requires inspecting PVs and checking their status/claimRef.
   kubectl get pv
   
   # 5. Identify unused Load Balancers or public IPs in your cloud provider's console.
   # These are often created by Kubernetes Services of type LoadBalancer or Ingress controllers.
   # Ensure they are not in use before deleting them directly from the cloud console.
           

   Explanation: This step emphasizes the importance of regular audits. Stale resources, especially persistent volumes and load balancers, can incur significant costs even when not actively used by an application. Deleting an entire namespace is powerful but must be done with extreme caution. For PVs, check their `STATUS` and `CLAIM` fields. If `STATUS` is `Available` and `CLAIM` is empty, it might be safe to delete. Cloud resources like Load Balancers often persist even after a Service or Ingress is deleted if not properly configured for automatic cleanup, requiring manual intervention in the cloud console.

   Verify

   After running cleanup commands, verify the resources are indeed gone.

   
   # Verify namespace deletion
   kubectl get namespace old-dev-env
   # Expected Output: Error from server (NotFound): namespaces "old-dev-env" not found
   
   # Verify PV deletion (if you deleted an unattached PV)
   kubectl get pv my-old-pv
   # Expected Output: Error from server (NotFound): persistentvolumes "my-old-pv" not found
           

   Regular audits, perhaps automated with custom scripts or policies, are a crucial part of a proactive FinOps strategy. This also ties into good operational hygiene, reducing clutter and potential security risks. Tools like Sigstore and Kyverno can be used to enforce policies around resource lifecycle, though their primary focus is security and compliance.

Production Considerations

• Continuous Monitoring and Alerting: FinOps is not a one-time setup. Continuously monitor resource usage, costs, and key performance indicators. Set up alerts for cost anomalies or sudden spikes. Integrate with your existing observability stack, perhaps leveraging eBPF Observability with Hubble for network-level insights.
• Reserved Instances/Savings Plans Strategy: For stable, long-running base loads, commit to Reserved Instances or Savings Plans. This requires careful forecasting of your compute needs over 1-3 years. Work closely with finance and engineering to get this right.
• Right-Sizing Workloads Iteratively: Use data from your cost allocation tools and monitoring (e.g., Prometheus) to continually fine-tune resource requests and limits. This is an ongoing process as applications evolve.
• Automation: Automate as much as possible – from autoscaling to automated cleanup of unused resources. Tools like Karpenter are key here.
• Chargeback/Showback Mechanisms: Implement a system to attribute costs back to specific teams or business units. “Showback” provides visibility without direct financial impact, while “Chargeback” directly allocates costs. This fosters a sense of ownership.
• Network Egress Costs: Don’t forget network egress! Data transfer costs, especially across regions or to the internet, can be substantial. Optimize network topology, use internal network paths (e.g., VPC peering), and consider content delivery networks (CDNs). For sophisticated network management, consider solutions like Istio Ambient Mesh or even Cilium WireGuard Encryption for secure and efficient pod-to-pod traffic.
• Storage Optimization: Choose appropriate storage classes (e.g., GP2 vs GP3 on AWS, standard vs SSD on GCP). Delete old snapshots and unattached volumes. Consider object storage for large, infrequently accessed data.
• Cloud Provider Specific Optimizations: Each cloud provider has unique services and pricing models. Leverage their specific cost management tools (e.g., AWS Cost Explorer, GCP Cost Management, Azure Cost Management) in conjunction with Kubernetes-native tools.
• Cultural Shift: FinOps is as much about culture as it is about tools. Foster collaboration between engineering, finance, and product teams. Educate engineers on the financial impact of their architectural decisions.

Troubleshooting

1. Issue: High CPU/Memory Utilization on Nodes, but Pods are Underutilized

   Problem: Your cluster nodes appear to be running hot, but individual pods or deployments show low CPU/memory usage, leading to wasted capacity.

   Solution: This often indicates poorly configured resource requests.

   • Review Requests/Limits: If requests are set too high, Kubernetes reserves more resources than pods actually need, leading to fragmentation and inefficient scheduling. Use monitoring tools (Prometheus, Grafana) to observe actual pod usage over time.
   • Right-size: Adjust `resources.requests` closer to the average observed usage and `resources.limits` slightly above peak usage.
   • Vertical Pod Autoscaler (VPA): Consider deploying VPA in recommendation mode to get data-driven suggestions for optimal requests/limits.

   
   # Example: Check actual pod usage (requires Metrics Server)
   kubectl top pod -n <your-namespace>
   
   # Example: Check node usage
   kubectl top node
           

2. Issue: Pods are Pending Due to Insufficient Resources

   Problem: Pods are stuck in a `Pending` state, with messages like “0/N nodes available: M Insufficient