用 client-go 创建/删除 Namespace 需调用 Create/Delete 方法，注意删除异步、不可跳过 finalizers；创建时仅设 Name 等必要字段；导出 YAML 需剔除 status 和服务器字段；等待状态需轮询 Get 并判 phase 或错误类型；资源隔离须配合 ResourceQuota 和 LimitRange。
如何用 client-go 创建和删除 Kubernetes 命名空间
命名空间（Namespace）是 Kubernetes 中最基础的资源隔离单元，Golang 项目若需动态管理集群环境（如 CI/测试环境自动建删），必须通过 client-go 操作 v1.Namespace 资源。直接调用 Create 或 Delete 方法即可，但要注意：命名空间删除是异步过程，且不能强制跳过 finalizers。
- 创建时需设置
ObjectMeta.Name，其他字段如Labels、Annotations可选，但建议打标便于后续筛选 - 删除后调用
Get会返回404错误（errors.IsNotFound(err)判断），但实际对象可能仍在Terminating状态，需轮询确认 - 不要省略
context超时控制——命名空间删除可能卡在 finalizer（如 NetworkPolicy、ResourceQuota 清理未完成），默认无超时会导致 goroutine 泄漏
ns := &corev1.Namespace{
ObjectMeta: metav1.ObjectMeta{
Name: "my-test-ns",
Labels: map[string]string{"env": "ci"},
},
}
_, err := clientset.CoreV1().Namespaces().Create(ctx, ns, metav1.CreateOptions{})为什么 Namespace 不能跨集群复用或导出为 YAML 直接 apply
命名空间本身不包含集群拓扑信息，但它的生命周期深度绑定于所在集群的 etcd 和 admission controller。你可能会遇到这些现象：
- 从生产集群
kubectl get ns my-ns -o yaml导出后再在测试集群kubectl apply -f失败，报错field is immutable—— 因为status.phase、creationTimestamp等字段被写入了 YAML，而 server 不允许修改 - 用
client-go读取一个已存在的命名空间再原样Create，会触发409 Conflict，因为Name是集群级唯一标识 - 即使清空所有
status和metadata中的服务器字段，某些启用NamespaceLifecycle插件的集群还会校验metadata.uid是否为空，非空则拒绝
正确做法是只保留 metadata.name 和可选的 metadata.labels/annotations，其余全部剔除。
如何安全地等待 Namespace 进入 Active 或 Terminating 状态
client-go 没有内置的 WaitForNamespaceReady，必须手动轮询。关键点在于：状态字段在 status.phase，但该字段可能延迟更新；更可靠的方式是结合 Get 返回值与错误类型判断。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 检查 Active：当
err == nil且ns.Status.Phase == corev1.NamespaceActive时认为就绪 - 检查 Terminating：当
err != nil且errors.IsNotFound(err)为 false，同时ns.Status.Phase == corev1.NamespaceTerminating - 避免高频轮询：使用
time.Sleep(1 * time.Second)+ 最大重试次数（比如 30 次），否则易触发 API server 限流
for i := 0; i < 30; i++ {
ns, err := clientset.CoreV1().Namespaces().Get(ctx, "my-test-ns", metav1.GetOptions{})
if err != nil && errors.IsNotFound(err) {
return fmt.Errorf("namespace deleted")
}
if err == nil && ns.Status.Phase == corev1.NamespaceActive {
return nil
}
time.Sleep(1 * time.Second)
}ResourceQuota 和 LimitRange 配合 Namespace 实现硬性资源隔离
仅靠 Namespace 本身无法限制 CPU/Memory 使用量，必须搭配 ResourceQuota（集群管理员视角）和 LimitRange（租户默认限制）。Golang 程序若要实现“开箱即用”的隔离，需在创建 Namespace 后立即部署这两类资源。
-
ResourceQuota控制总量上限，例如限制该 Namespace 下所有 Pod 总共最多用2核 CPU 和4Gi内存，超出后Pod创建会失败并报Forbidden: exceeded quota -
LimitRange设置默认 request/limit，避免用户不写resources导致调度器无法决策；它不影响已有 Pod，只对新创建的生效 - 二者都属于命名空间作用域资源，必须指定
Namespace字段，且创建顺序无关（但建议先建 Namespace，再建配额）
容易忽略的是：ResourceQuota 的 scopeSelector 或 scopes 字段若配置错误（比如写了不存在的 label），会导致配额完全不生效，且无任何报错日志。
