Kubernetes Resource Review Practice

Kubernetes Resource Review Practice is the recurring organizational discipline of periodically re-examining resource requests, limits, quota allocations, and QoS classifications across a cluster's workloads, treating resource sizing as a decision requiring ongoing maintenance rather than a one-time exercise performed only at initial deployment. Because workload behavior, traffic patterns, and application code all change over time, resource declarations that were well-calibrated at launch drift out of alignment with actual needs — sometimes producing wasted capacity through over-provisioning, sometimes producing instability through under-provisioning — and a deliberate review cadence is what catches this drift before it compounds into either significant cost waste or recurring operational incidents.

Unlike resource declaration itself, which happens once per manifest change, review practice is a process — who looks at what, how often, using which data — and its absence is one of the more common reasons clusters accumulate persistent resource misconfiguration over time even when the underlying mechanisms (requests, limits, quotas) are all individually well understood.

What a Resource Review Examines

Comparing Declared Values Against Observed Usage

The core of any review is comparing each workload's declared requests and limits against its actual observed resource consumption over a representative period, identifying containers whose declarations no longer reflect reality in either direction.

kubectl top pods -n codartium-team --containers
kubectl get pods -n codartium-team -o json | jq '.items[].spec.containers[].resources'

Reviewing QoS Class Distribution

Auditing the distribution of Guaranteed, Burstable, and BestEffort classifications across a namespace surfaces workloads that landed in an unintended class — most commonly, critical workloads that should be Guaranteed but were left Burstable by oversight, or workloads accidentally left entirely at BestEffort due to missing declarations.

kubectl get pods -n codartium-team -o custom-columns=NAME:.metadata.name,QOS:.status.qosClass

Reviewing Quota and LimitRange Utilization

Checking how close each namespace's ResourceQuota consumption sits relative to its hard ceiling, and whether LimitRange default and bound values still match the namespace's actual workload profile, rounds out a thorough review beyond just individual Pod-level sizing.

kubectl describe resourcequota -n codartium-team

Establishing a Review Cadence

Regular, Scheduled Reviews

A fixed cadence (monthly or quarterly, depending on how quickly a given cluster's workloads change) ensures resource sizing receives attention proactively, rather than only being revisited reactively after an incident (an OOM kill, a throttling-induced latency spike, or a quota exhaustion blocking a deployment) forces the issue.

Event-Triggered Reviews

Beyond the scheduled cadence, specific events warrant an ad hoc review outside the regular schedule: a significant traffic pattern change, a major application refactor, or a recurring pattern of resource-related incidents on a specific workload all justify revisiting that workload's resource configuration immediately rather than waiting for the next scheduled cycle.

Tools Supporting Review Practice

VPA in Recommendation-Only Mode

Running the Vertical Pod Autoscaler in Off update mode (recommendation only, no automatic application) provides an ongoing, automatically-computed suggestion for appropriate requests based on historical usage, giving reviewers a data-driven starting point rather than requiring them to manually derive sizing from raw metrics each time.

kubectl describe vpa codartium-app-recommender -n codartium-team

Dashboards Summarizing Request-vs-Usage Gaps

Purpose-built dashboards (built on Prometheus or a similar metrics pipeline) visualizing the gap between declared requests/limits and actual usage across many workloads simultaneously make review sessions considerably more efficient than manually querying kubectl top workload by workload.

Documenting Review Outcomes

Recording Rationale for Non-Obvious Sizing Decisions

When a review concludes a particular sizing choice should remain as-is despite appearing unusual at first glance (a deliberately generous limit for a workload with known, occasional legitimate spikes), documenting that rationale — in a comment, an annotation, or accompanying documentation — prevents a future reviewer from "correcting" a deliberate decision without understanding its original justification.

metadata:
  annotations:
    codartium.io/sizing-rationale: "Limit set high to accommodate monthly batch reconciliation spike; reviewed 2026-06-01"

Example

kubectl top pods -n codartium-team --containers > usage-snapshot.txt
kubectl get pods -n codartium-team -o json | jq '.items[] | {name: .metadata.name, requests: .spec.containers[].resources.requests}' > declared-requests.json

Combining these two extracts is the practical starting point for any manual resource review session, giving reviewers the raw comparison data needed to identify sizing drift before deciding on any adjustments.