Kubernetes中Pod必须配置CPU和内存的Requests与Limits：Requests是调度硬门槛，Limits是运行生死线；内存建议Requests=Limits以防OOMKilled；可通过YAML声明、kubectl patch（仅测试）或Deployment+LimitRange批量管控。
在Kubernetes中为Pod配置CPU和内存的Limit与Request，是防止容器失控占用资源、避免OOMKilled、保障集群稳定运行的强制性操作。不设Limit的内存容器一旦超限会被内核直接杀掉，不设Request的Pod则可能永远卡在Pending状态无法调度。
理解Requests与Limits的核心分工
Requests是调度器选节点时的硬门槛：所有容器requests之和必须≤目标节点的可分配资源，否则Pod进不了Node；Limits是运行时的生死线：CPU超Limit会被节流但不死，内存超Limit则立即触发OOMKilled。
内存的Requests和Limits建议设为相等——因为内存无法像CPU那样平滑限流，留出差值等于主动制造一个“被杀窗口”。
【内存Limit必须≥Requests，且不能为0；CPU Limit可以大于Requests，但Requests不可为0】
在Pod YAML中直接写死资源配置
方法一：手动编辑Pod定义文件，在containers.resources下声明
① 打开你的pod.yaml，定位到某个container的spec块内部；
② 在resources字段下，嵌套写入requests和limits对象：
```yaml
resources:
requests:
memory: "256Mi"
cpu: "250m"
limits:
memory: "512Mi"
cpu: "500m"
```
注意：单位必须准确——内存用Mi/Gi（不是MB/GB），CPU用m（毫核）或小数（如0.5）；写成"500m"比"0.5"更不易出错。
通过kubectl patch动态追加资源限制
适用于已运行但未配置resources的Pod（仅限测试环境，生产环境应重建）
执行命令一次性注入requests和limits：
kubectl patch pod <pod-name> -p '{"spec":{"containers":[{"name":"<container-name>","resources":{"requests":{"memory":"128Mi","cpu":"100m"},"limits":{"memory":"256Mi","cpu":"200m"}}}]}}'
这一步会立即触发Pod重启——因为resources属于不可变字段，patch本质是删除旧Pod、新建带配置的新Pod。
【不要对线上核心Pod直接patch；若容器名不明确，先用kubectl get pod <name> -o yaml确认name字段】
用Deployment模板批量管控资源策略
方法一：在Deployment的template.spec.containers中定义resources
这是生产环境唯一推荐的方式，确保每次滚动更新都继承统一策略。
方法二：配合LimitRange实现命名空间级兜底
在目标namespace中创建LimitRange对象，自动为未声明resources的Pod注入默认值：
```yaml
apiVersion: v1
kind: LimitRange
metadata:
name: default-limit
namespace: prod
spec:
limits:
- default:
memory: 512Mi
cpu: 250m
defaultRequest:
memory: 256Mi
cpu: 100m
type: Container
```
LimitRange只影响新创建的Pod，不会修改已有Pod；它不能替代显式声明，只是最后一道安全网。
验证配置是否生效
运行kubectl describe pod <pod-name>，在Containers部分查找Resources行：
你会看到类似输出：
Resources:
Requests:
cpu: 250m
memory: 256Mi
Limits:
cpu: 500m
memory: 512Mi
如果Requests或Limits显示<unset>，说明该字段未配置或配置有语法错误。
用kubectl top pod <pod-name>可实时观察实际使用量是否在Limits范围内。
