Introduction

A LimitRange in Kubernetes applies resource defaults, minimums, or maximums within a namespace. If one exists in the default namespace and you want to remove it, the operation is straightforward: identify the resource, inspect it, and delete it. The important part is understanding whether the LimitRange was created manually or is being continuously re-added by some controller or policy system.

Find the LimitRange in the default Namespace

Start by listing LimitRange objects:

kubectl get limitrange -n default

If there is more than one, inspect them individually:

kubectl describe limitrange my-limitrange -n default

This tells you what restrictions are being enforced and gives you the exact object name to delete.

If the list is empty, then the problem is not a LimitRange object in default. You may instead be dealing with a different admission policy or a resource quota expectation from another controller.

Delete the LimitRange

Once you know the name, remove it:

kubectl delete limitrange my-limitrange -n default

Then confirm:

kubectl get limitrange -n default

If the object no longer appears, the namespace no longer has that LimitRange.

This is the entire removal operation in plain Kubernetes. There is no special API for the default namespace beyond specifying -n default.

Watch for GitOps or Policy Reconciliation

Deletion is easy. Keeping it deleted may not be. In many clusters, namespace policies are managed by:

• Helm charts
• GitOps tools such as Argo CD or Flux
• platform operators
• admission or namespace bootstrap controllers

If you delete the LimitRange and it returns, the cluster is reconciling it from another source of truth. In that case, deleting the live object is only temporary. You must remove or change the upstream manifest that owns it.

A useful follow-up command:

kubectl get limitrange my-limitrange -n default -o yaml

Look for annotations and labels that indicate which tool created it.

Understand the Risk Before Removing It

A LimitRange is usually there for a reason. Removing it from default can allow pods without explicit resource requests or limits, which may create scheduling unpredictability or noisy-neighbor problems.

For example, after deletion, a pod like this may be admitted with no guardrails:

1apiVersion: v1
2kind: Pod
3metadata:
4  name: no-limits
5spec:
6  containers:
7    - name: app
8      image: nginx:1.25

That may be acceptable in a small local cluster, but it is often a bad idea in shared environments.

A safer option is sometimes to replace the LimitRange with a less restrictive one instead of removing it entirely.

Edit Instead of Delete When Appropriate

If the goal is to relax the policy rather than erase it, edit the resource:

kubectl edit limitrange my-limitrange -n default

This opens the current spec so you can adjust defaults, minimums, or maximums without losing the object entirely.

In managed clusters, however, editing may still be overwritten later by the control plane or GitOps system. The same source-of-truth rule applies.

Verify the Namespace Behavior After Removal

After deletion, test with a simple pod or deployment that previously failed because of the LimitRange.

kubectl apply -f test-pod.yaml -n default
kubectl describe pod no-limits -n default

This tells you whether the old enforcement path is really gone. If the pod still gets resource defaults or rejections, another policy layer is active.

Common Pitfalls

• Deleting the LimitRange once and not noticing that a controller recreates it immediately.
• Assuming the default namespace is special beyond being a normal namespace named default.
• Removing resource guardrails without understanding the scheduling and multi-tenant impact.
• Blaming LimitRange when the real enforcement is a different admission policy.
• Forgetting to test namespace behavior after deletion to confirm the change actually had the intended effect.

Summary

• List and inspect the LimitRange in default before deleting it.
• Remove it with kubectl delete limitrange ... -n default.
• If it comes back, a higher-level tool is managing it.
• Consider editing or replacing it instead of deleting it outright in shared clusters.
• Verify the namespace with a test workload so you know whether the enforcement is really gone.