核心是将租户生命周期、资源边界、权限策略和数据流向全部锚定在client-go调用链中：需通过ownerreference关联tenant cr，用label而非命名区分环境，动态创建resourcequota/limitrange，严格使用role+rolebinding限定权限，serviceaccount须在租户namespace内创建，清理时须按依赖顺序删除pv/pvc/secret等资源并校验元数据一致性。
Go 语言管理 Kubernetes 集群租户隔离，核心不是“写个程序连上 K8s”，而是把租户生命周期、资源边界、权限策略和数据流向全部用代码锚定在 client-go 调用链里。硬编码 Namespace 名字或手写 RBAC YAML 是不可维护的起点。
创建租户 Namespace 时必须带 OwnerReference 和标签
直接 kubectl create ns tenant-a 或裸调 client.CoreV1().Namespaces().Create() 会丢失租户归属上下文，导致后续审计、自动清理、配额联动全部失效。
- Namespace 必须设置
labels["tenant"] = tenantID和labels["environment"]，便于 NetworkPolicy 或 Prometheus 标签匹配 - 必须通过
OwnerReferences关联到自定义租户 CR（如Tenant），这样租户删除时可由 Operator 自动级联清理 Namespace 及其所有资源 - 避免在 Namespace 名称里拼接环境（如
tenant-a-prod），应统一用 label 区分，名称保持简洁可读（tenant-a）
ResourceQuota 和 LimitRange 必须动态生成并绑定到 Namespace
静态 YAML 模板无法应对租户分级（免费/企业版）或按需扩缩容。client-go 创建配额时若漏设 namespace 字段，对象会创建失败但错误不明显。
- ResourceQuota 的
spec.hard值应来自租户等级配置（如数据库查出tenant_tier = "enterprise"→ CPU 20 →requests.cpu: "20"） - LimitRange 中的
default和defaultRequest必须显式设置，否则 Pod 不指定资源请求时会被 kube-scheduler 拒绝，但错误日志只显示 “0/3 nodes are available”，排查困难 - 创建顺序必须是：Namespace → ResourceQuota → LimitRange，否则 LimitRange 可能因 quota 未就绪而被忽略
RBAC 绑定必须用 RoleBinding 而非 ClusterRoleBinding
用 ClusterRoleBinding 给租户绑 admin 角色等于交出整个集群控制权。即使加了 namespace 字段，ClusterRoleBinding 本身作用域就是全局的，字段无效。
- 租户管理员权限应基于
Role+RoleBinding，且Role定义中apiGroups、resources、verbs全部显式限定，禁用resources: ["*"] - ServiceAccount 必须在租户 Namespace 内创建，不能复用 default SA；绑定前检查
serviceAccount.Name是否属于该 Namespace - client-go 创建 RoleBinding 时，
Subjects的name字段必须与 SA 名字完全一致，大小写敏感，且不能含命名空间前缀
租户清理必须同步删除 Secret、ConfigMap 和 PV 引用
仅删 Namespace 会导致 orphaned 资源堆积：Secret 仍存于 etcd、PV 未释放、NetworkPolicy 残留影响网络策略计算。client-go 的 DeleteCollection() 不处理跨资源依赖。
- 清理流程应为：解除 PVC 与 PV 的绑定（patch PV
spec.claimRef为 null）→ 删除 PVC → 删除 PV → 删除 Namespace - Secret 和 ConfigMap 必须按 label selector（
tenant=a）批量删除，不能依赖 Namespace 级联——因为有些 Secret 可能被多个租户共享（如 TLS CA），需额外判断 ownerRef - 调用
client.CoreV1().Namespaces().Delete()前，先用client.CoreV1().Pods(ns).List()确认无活跃 Pod，否则 Namespace 进入Terminating卡住
最易被忽略的是租户元数据一致性：Tenant CR 的 status.phase、Namespace 的 annotation、ResourceQuota 的实际使用量，这三者在并发创建/删除时极易错位。不要依赖最终一致性等待，要在 Go 控制器里做状态机校验和补偿操作。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
