ResourceQuota是Kubernetes命名空间级硬性资源“天花板”，由kube-apiserver准入控制器执行，client-go仅负责创建、读取、更新和删除配额对象；需显式设置metadata.namespace、spec.hard必填且值为字符串，配合LimitRange确保所有资源声明requests才能生效。
ResourceQuota 是 Kubernetes 命名空间级的硬性资源“天花板”，Golang 客户端本身不“管理”它——你用 client-go 创建、读取、更新或删除它，但配额逻辑由 kube-apiserver 的 ResourceQuota 准入控制器执行。真正要做的，是确保你的 Go 程序能正确构造、提交并诊断配额对象。
怎么用 client-go 创建 ResourceQuota 对象
核心是构造合法的 v1.ResourceQuota 结构体，并通过 ResourceQuotas 客户端提交。注意命名空间必须提前存在，且你有对应 RBAC 权限（resourcequotas/{create,update,delete}）。
-
metadata.namespace必须显式设置，不能为""；若设错，会报Forbidden: cannot set namespace on resourcequotas -
spec.hard是必填字段，哪怕只限制一个指标（如pods: "5"），也不能留空 map - 所有资源值（如
requests.cpu）必须是字符串格式，不能用 float64 或 int —— 否则序列化失败，报json: unsupported type: float64 - 示例关键片段：
quota := &corev1.ResourceQuota{
ObjectMeta: metav1.ObjectMeta{
Name: "dev-quota",
Namespace: "dev-team", // ← 必须和 apply 时的 namespace 一致
},
Spec: corev1.ResourceQuotaSpec{
Hard: corev1.ResourceList{
"pods": resource.MustParse("10"),
"requests.cpu": resource.MustParse("2"),
"requests.memory": resource.MustParse("4Gi"),
"persistentvolumeclaims": resource.MustParse("3"),
},
},
}
_, err := clientset.CoreV1().ResourceQuotas("dev-team").Create(ctx, quota, metav1.CreateOptions{})
为什么创建后 get 不到或 status.used 一直是 0
常见不是代码问题，而是配额未被“触发”：只有当命名空间中存在实际资源（如 Pod、PVC）且它们带 resources.requests 时，status.used 才会累积。如果你只创建了 ResourceQuota，但没部署任何带资源声明的 Pod，used 就永远是 0。
- 检查 Pod 是否设置了
resources.requests：没设的话，ResourceQuota会拒绝创建（报Forbidden: failed quota: dev-quota: must specify requests.cpu） - 确认
ResourceQuota所在命名空间里是否有非终止状态的 Pod/PVC ——status.used只统计phase != Failed && phase != Succeeded的对象 - 用
kubectl get quota -n dev-team -o wide看REQUEST列是否显示数值，这是最直接验证方式
如何检测配额超限导致的创建失败
当你用 client-go 创建 Pod 或 PVC 时，如果违反 ResourceQuota，API server 返回的是 HTTP 403 + 明确错误信息，不是 panic 或 generic error。
- 捕获错误时，检查
errors.IsForbidden(err)，再断言为*apierrors.StatusError -
err.Status().Details.Reason通常是Forbidden，而err.Error()会包含类似exceeded quota: dev-quota, requested: pods=1, used: pods=10, limited: pods=10 - 不要依赖
status.used实时判断能否创建 —— 它有延迟；应把配额检查逻辑放在调用前做预估，或直接捕获 403 并提示用户
更新 ResourceQuota 时要注意什么
ResourceQuota 支持 Update，但修改 spec.hard 不会“释放”已超出的资源 —— 已存在的 Pod 不会被驱逐，只是新创建请求会按新规则校验。
- 更新操作本身不会触发重计算，
status.used仍基于当前存活对象持续更新 - 若想立刻收紧限制（比如从
pods: "20"改为"10"），需先手动删掉部分 Pod，否则后续创建仍会 403 - 用
Replace或Update都可以，但必须带上ResourceVersion，否则报conflict: the object has been modified
真正容易被忽略的点是：ResourceQuota 的约束生效，严格依赖命名空间内所有资源都声明了 requests。一旦漏掉一个未设 resources 的 Pod，整个配额体系就形同虚设 —— 它既不计入 used，也不受 hard 限制。所以 Golang 侧的管理逻辑，必须和 LimitRange 配合使用，靠默认值兜底。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
