ResourceQuota 的 spec.hard 字段支持原地更新，需通过 CoreV1().ResourceQuotas(namespace) 获取最新对象并保留 ResourceVersion，仅修改 hard 中键值，避免字段清空或 422 错误。
Go 语言动态修改 Kubernetes 资源配额（ResourceQuota）的关键，不是“能不能改”，而是“改完要不要触发重建”和“字段是否允许更新”。ResourceQuota 的 spec.hard 字段支持原地更新，但 status 和部分元数据字段不可写；一旦写错字段或漏传 ResourceVersion，API server 会直接拒绝并返回 422 Unprocessable Entity 或静默失败。
用 client-go 更新 ResourceQuota 的正确姿势
必须使用 CoreV1().ResourceQuotas(namespace) 接口，不能误用 CoreV1().Namespaces() 或其它 GroupVersion —— ResourceQuota 是命名空间级资源，属于 core/v1，且只在指定 namespace 下存在。
- 先
Get当前对象，确保拿到最新ResourceVersion：否则Update会因版本冲突被拒 - 只修改
spec.hard中的键值，例如limits.cpu、requests.memory；其他字段如spec.scopes虽可读，但修改后提交会报错field is immutable - 调用
Update时传入完整对象指针，不是 patch；client-go 不自动 merge，空字段会被清空 - 注意：
ResourceQuota没有UpdateStatus方法，所有变更都走Update
常见错误：422 / 无效果 / 静默清空字段
典型现象是执行 Update 后没报错，但 kubectl get resourcequota -o yaml 显示 spec.hard 变成空或部分字段丢失。根本原因是结构体初始化不完整。
- 手写
&corev1.ResourceQuota{}时没填全ObjectMeta，尤其漏了ResourceVersion和Name→ API server 当作新建请求，但 name 已存在，直接 422 - 从
Get结果拷贝对象后，手动改spec.hard，却忘了spec.hard是map[string]string类型，直接赋值nil或未初始化 map → 提交时该字段被序列化为空 map，覆盖原有配额 - 用
Unstructured构造时 key 写错，比如"limits.cpu"写成"limits.cpu"（看似一样，实则空格/大小写敏感），K8s 忽略该条目但不报错
一个安全更新的 minimal 示例
以下代码片段仅更新 CPU limit，保留原有 memory 配置：
立即学习“go语言免费学习笔记（深入）”；
quota, err := clientset.CoreV1().ResourceQuotas("myns").Get(ctx, "my-quota", metav1.GetOptions{})
if err != nil {
return err
}
// 深拷贝 hard map，避免污染原对象
hard := make(map[string]string)
for k, v := range quota.Spec.Hard {
hard[k] = v
}
hard["limits.cpu"] = "4" // ← 只改这一项
quota.Spec.Hard = hard
_, err = clientset.CoreV1().ResourceQuotas("myns").Update(ctx, quota, metav1.UpdateOptions{})
注意：这里没动 quota.ObjectMeta.ResourceVersion，因为 Get 返回的对象已含该字段；也不需要手动设 quota.ObjectMeta.Name，它本来就有。
为什么不用 Patch？
虽然 Patch 看起来更轻量，但 ResourceQuota 的 hard 是 map 类型，JSON Merge Patch 对 map 的行为不可靠（可能整 map 替换而非增量更新），而 Strategic Merge Patch 在 client-go 中对 ResourceQuota 不启用。实际生产中，Get-Modify-Update 是最可控、最容易 debug 的方式。
真正容易被忽略的是：更新生效后，新创建的 Pod 才受新配额约束；已在运行的 Pod 不受影响，也不会被驱逐 —— 这不是 bug，是设计使然。
