When running Kubernetes at Scale, ensuring application stability is rarely about having enough raw hardware; it's about predictability. The Nautilus DevOps team recently diagnosed performance degradation in several hosted applications. The root cause wasn't application failure, but noisy neighbors: a few pods were consuming excessive memory and CPU, starving critical components on the same nodes.
To restore balance and protect cluster health, we implemented fundamental resource scheduling controls- Requests and Limits- starting with a standard Apache httpd deployment. This pos details how we configured this governance. This post details how we configured this governance.
The Challenge: Resource Contention
Unconstrained containers are a significant risk. Without defined limits, a process with a memory leak or a spiked CPU load can consume all available resources on its underlying worker node. This "OOMKilled" ( Out of Memory Killed ) even dosen't just impact the runaway container; it can crash the kubelet itself, leading to node instability and cascading failures.
Image 0 visualizes the state of our cluster before implementation: simplified nodes were operational, but the total resource consumption was high, approaching critical thresholds. The lack of granular control meant we were vulnerable to the next performance spike.
Image 0: Pre-Optimization. The Kubernetes cluster visualization shows overall resource usage hitting critical levels (85% Memory, 90% CPU), indicating high stress and contention.)
The Solution: A Governed Deployment
Our strategy was simple: deploy a new Apache webserver instance, httpd-pod, but strictly define its compute resource footprint using requests and limits.
Resource Requests (Guaranteed Minimum): This is what the pod is guaranteed to receive. Kubernetes uses this value for scheduling. The pod will only be placed on a node that can fulfill this specific reservation.
Resource Limits (Absolute Maximum): This is the hard ceiling. The container will never be allowed to consume more than this amount. If it tries to exceed the memory limit, it may be terminated (OOMKilled). If it exceeds the CPU limit, it will be throttled.
The Blueprint (YAML)
We created httpd-pod.yaml with the following configuration:
apiVersion: v1
kind: Pod
metadata:
name: httpd-pod
spec:
containers:
- name: httpd-container
image: httpd:latest
resources:
requests:
memory: "15Mi" # Guaranteed minimum RAM reservation
cpu: "100m" # Guaranteed minimum CPU reservation
limits:
memory: "20Mi" # Hard memory ceiling
cpu: "100m" # Hard CPU ceiling
This configuration ensures the httpd container always has 15Mi of RAM and 0.1 CPU cores available, but it can never exceed 20Mi or use more than 0.1 CPU cores.
Implementation: Deploying the Governed Pod
We applied the configuration using kubectl:
kubectl apply -f httpd-pod.yaml
The cluster immediately began the deployment process. Image 1 visualizes this implementation. You can see the schematic deployment taking place on 'NODE 1' (identified in Image 0). Crucially, the infographic integrated into this visualization (Image 1) highlights the precise constraints we defined: the requests and the limits are now part of the pod's identity before it even starts running.
Verification and Long-Term Stability
Once deployed, we verified the configuration:
kubectl describe pod httpd-pod
The output confirms that the limits are active.
The difference in cluster health is visual. Contrast Image 0 with the post-optimization monitoring view in Image 2. By zooming in on 'NODE 1', we see the running httpd-pod.
The visualization highlights the effectiveness of the governance: a glowing hexagonal boundary now surrounds the pod. This represents the enforced resource quota. While the pod's internal metrics show it is active and utilizing resources, its usage is strictly contained within that ring. The corresponding graph for NODE 1 shows that memory usage is stable, remaining safely below the 20Mi ceiling. By restricting this single application, the entire node remains stable and optimal.
(Image 2: Post-Optimization Stability. The monitoring view focuses on 'NODE 1'. The running 'httpd-pod' (with a green health pulse) is contained within a strong, glowing hexagonal quota boundary. The pod's real-time usage graph is stable just below the enforced 20Mi limit, keeping the node optimal and stable.)
Conclusion
By implementing resource requests and limits, the Nautilus DevOps team transitioned from reactive firefighting to proactive governance. We have guaranteed that the httpd-pod has the resources it needs to function, while simultaneously ensuring it can never become a noisy neighbor that threatens the stability of the entire cluster. This fundamental configuration is the cornerstone of predictable Kubernetes performance.
Top comments (0)