17370845950

用 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 返回值与错误类型判断。

立即学习“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），会导致配额完全不生效，且无任何报错日志。