client-go 创建 pod 时 resources.limits 必须显式为每个容器完整指定，且 limits 与 requests 需同时存在；patch 更新会触发 pod 重建而非热更新；limitrange 仅服务端兜底注入，默认值不替代代码显式声明；jvm 应用需为非堆内存预留 limits 缓冲。
Go client-go 中设置 Pod 的 resources.limits 必须写全 container 名称和字段
用 client-go 创建 Pod 时，resources.limits 不是可选字段，也不是“默认继承”——它必须显式写在每个 container 的 Resources 结构里，且 limits 和 requests 都要成对出现（哪怕只设一个，另一个也得填零值或明确值）。否则 API Server 会拒绝创建，报错类似：ValidationError(Pod.spec.containers[0].resources): missing required field "limits"。
常见错误包括：
- 只写了
requests，漏掉limits字段（K8s 不接受） - 用
resource.MustParse("512Mi")解析后没赋值给Limitsmap，而是误塞进了Requests - 容器名写错（比如 Deployment 模板里叫
app，代码里硬编码成main），导致 patch 失败或字段被忽略
正确写法示例（关键字段已加注释）：
container := corev1.Container{
Name: "app",
Image: "my-app:latest",
Resources: corev1.ResourceRequirements{
Requests: corev1.ResourceList{
corev1.ResourceCPU: resource.MustParse("100m"),
corev1.ResourceMemory: resource.MustParse("128Mi"),
},
Limits: corev1.ResourceList{ // ← 必须显式声明
corev1.ResourceCPU: resource.MustParse("200m"),
corev1.ResourceMemory: resource.MustParse("256Mi"),
},
},
}
用 client-go patch 已有 Pod 的 limits 会触发重建，不是热更新
kubectl patch 在命令行里看着是“打补丁”，但 client-go 调用 Patch 方法更新 Pod.spec.containers[].resources 时，Kubernetes 会直接拒绝原地修改——因为 resources 是不可变字段（immutable field）。实际行为是：旧 Pod 被删除，新 Pod 按新 spec 重建。
这意味着：
- Pod IP、本地卷挂载、hostNetwork 等状态全部丢失
- 若 Pod 属于 Deployment，patch 后会被控制器立即“纠正”回原始模板配置（除非你同时 patch Deployment）
- 线上服务不能靠 patch 救急；真正要改，得更新 Deployment 的
template.spec并 rollout
如果你真要用 client-go patch（仅限测试环境），必须确认两点：
- 目标 Pod 不在任何控制器管理下（即
ownerReferences为空） - 先用
Get拿到当前 spec，再构造完整 patch payload，避免覆盖其他字段（推荐用StrategicMergePatchType）
LimitRange 对 client-go 创建的 Pod 有兜底作用，但不改变代码逻辑
即使你在 Go 代码里没写 limits，只要目标命名空间存在 LimitRange 对象且设置了 default，API Server 就会在准入阶段自动注入默认 limits 值。但这只是“服务端补全”，你的 client-go 代码依然要能处理返回的完整 spec（比如后续读取时发现 limits 被加进来了）。
注意几个边界情况：
-
LimitRange的type: Container才影响 Pod 容器；type: Pod是限制整个 Pod 所有容器 requests/limits 总和，client-go 创建时仍需单个容器填值 - 如果代码里写了
limits.cpu: "1"，但LimitRange设了max.cpu: "500m"，API Server 会直接拒绝创建，报错：spec.containers[0].resources.limits.cpu: Invalid value: "1": must be less than or equal to "500m" -
LimitRange不会修正你代码里的单位错误（比如把"512MB"当成合法值）——resource.MustParse在 client-go 侧就会 panic
JVM 应用在 Go 创建的 Pod 里，memory limits 必须预留非堆空间
如果你用 client-go 创建的是 Java 应用 Pod，只按 -Xmx2g 设置 JVM 堆，然后在 Go 代码里把 limits.memory 也设成 "2Gi"，大概率会 OOMKilled。因为 JVM 还要吃 Metaspace、CodeCache、线程栈、JIT 编译缓存等非堆内存，Linux cgroups 统计的是整个容器 RSS。
稳妥做法是在 Go 构造 ResourceRequirements 时留出余量：
- 堆设
-Xmx1536m→limits.memory至少设"2Gi"（+~512Mi 缓冲） - 更严谨的做法是加
-XX:MaxRAMPercentage=75.0，让 JVM 自适应容器 limit，再把 Go 里写的limits.memory设为最终上线值 - 别依赖
requests == limits来“保命”——内存没法节流，超了就是 kill，缓冲区比绝对相等更重要
这个细节在 client-go 代码里最容易被忽略：单位写对了、字段填全了，但数值没算准，上线后跑几天才开始 intermittent OOMKilled。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
