在Kubernetes中为命名空间配置LimitRange可自动注入默认资源请求与限制，并强制拦截超限Pod创建；其作用范围仅限容器级，需确保type为Container，且生效于新建或更新操作。
在Kubernetes集群中为命名空间设置默认资源限制，是为了防止未显式声明resources的Pod抢占节点资源、触发OOM Killer或干扰其他关键服务——这类Pod一旦部署就可能立刻开始无约束吃内存，而你甚至来不及定位是谁提交的YAML。
创建隔离命名空间
先新建一个专用命名空间，避免污染default或其他生产环境空间：
kubectl create namespace demo-lr
编写LimitRange配置文件
新建文件limitrange.yaml，内容如下：
apiVersion: v1
kind: LimitRange
metadata:
name: ns-default-lr
namespace: demo-lr
spec:
limits:
- type: Container
default:
cpu: 200m
memory: 512Mi
defaultRequest:
cpu: 100m
memory: 256Mi
max:
cpu: 1
memory: 2Gi
min:
cpu: 50m
memory: 64Mi
注意：【type: Container这一行不能删或写成Pod】，否则default和defaultRequest不会注入到容器级resources字段，整个默认值逻辑将失效。
应用LimitRange到命名空间
kubectl apply -f limitrange.yaml
这一步执行后，LimitRange即刻生效——它不等待Pod重启，只对后续新建/更新操作起作用。
验证默认值是否自动注入
方法一：部署一个完全不写resources的Pod
apiVersion: v1
kind: Pod
metadata:
name: no-resource-pod
namespace: demo-lr
spec:
containers:
- name: nginx
image: nginx:alpine
kubectl apply -f no-resource-pod.yaml → 然后运行：
kubectl get pod no-resource-pod -n demo-lr -o yaml | grep -A 5 resources
你会看到输出中已自动补全：
requests:
cpu: 100m
memory: 256Mi
limits:
cpu: 200m
memory: 512Mi
方法二：只写limits，不写requests
此时Kubernetes会忽略defaultRequest，直接把requests设为与limits相同值——这是硬性规则，不是可配选项。
方法三：只写requests，不写limits
这时limits会严格采用default字段值，而非按比例放大。例如requests.memory设为300Mi，limits仍为512Mi，不会变成600Mi。
强制拦截超限Pod的创建
第一步：尝试部署一个突破max限制的Pod
apiVersion: v1
kind: Pod
metadata:
name: over-limit-pod
namespace: demo-lr
spec:
containers:
- name: stress
image: polinux/stress
resources:
limits:
memory: 3Gi
第二步：执行kubectl apply -f over-limit-pod.yaml
你会收到明确报错：
Error from server (Forbidden): error when creating "over-limit-pod.yaml": pods "over-limit-pod" is forbidden: maximum memory usage per Container is 2Gi, but limit is 3Gi
第三步：修改memory为2Gi → 再次apply → 成功创建
