Plan Kubernetes LimitRange changes as new-admission changes

Adding a namespace limit policy does not retrofit the resources of running Pods.

Source facts

A Kubernetes LimitRange can apply default requests and limits and reject resource specifications outside its constraints. Validation happens during Pod admission. Existing Pods continue unchanged when a LimitRange is added or modified. When multiple LimitRange objects provide defaults in the same namespace, Kubernetes documents that the selected default is not deterministic.

Source: Kubernetes documentation — Limit Ranges.

Applicability

Review LimitRange defaults and admission constraints before changing a namespace policy.

DSE recommendation

DSE recommends inventorying the existing namespace defaults before introducing a new policy. Resolve competing defaults instead of relying on their creation order. Compare the resulting request and limit values with the application’s explicit declarations, then plan any necessary workload replacement separately. Tell service owners which newly created Pods will receive a changed configuration and which running instances will retain the old values. Keep the rollout and rollback steps visible so a policy update does not produce an unexplained mix of resource settings during normal replacement activity.

Verification

Create a disposable Pod without explicit resource values and inspect its admitted specification. Compare it with a Pod admitted before the policy change. Test a deliberately invalid request and confirm that the rejection explains the expected constraint. Retain both admitted specifications in the change record, with their creation times. Ask the owner to identify the deliberate replacement step that will make the application’s instances converge on the intended values.

Official reference

Kubernetes documentation — Limit Ranges. Reviewed October 20, 2026.