用 client-go 创建 Namespace 最简可行代码是调用 clientset.CoreV1().Namespaces().Create(ctx, ns, metav1.CreateOptions{})，需确保名称符合规范（小写字母、数字、连字符，长度≤63）、设置 ObjectMeta.Name，并处理 apierrors.IsAlreadyExists(err) 错误；推荐显式判断而非忽略，避免竞态应先 Get 再 Create；禁用 exec kubectl 方式以保障可移植性与权限一致性。
用 client-go 创建 Namespace 最简可行代码
直接调用 Create 方法即可，不需要先检查是否存在（Kubernetes API 本身幂等），但要注意命名规范和权限。
-
Namespace名称只能包含小写字母、数字、连字符（-），且不能以连字符开头或结尾，长度不超过 63 字符 - 必须设置
ObjectMeta.Name，其他字段如Labels、Annotations可选 - ServiceAccount 需有
create权限（对应namespaces资源）
ns := &corev1.Namespace{
ObjectMeta: metav1.ObjectMeta{
Name: "my-app-prod",
},
}
_, err := clientset.CoreV1().Namespaces().Create(ctx, ns, metav1.CreateOptions{})
if err != nil {
// 注意：如果已存在，会报错 "AlreadyExists"
if !apierrors.IsAlreadyExists(err) {
log.Fatal(err)
}
}
处理 "AlreadyExists" 错误的惯用写法
很多脚本希望“创建或跳过”，但 Create 不是 GetOrCreate。硬编码重试或忽略错误容易掩盖真实问题，推荐显式判断。
- 不要用
if strings.Contains(err.Error(), "AlreadyExists")—— 不稳定，且违反 error 类型判断原则 - 必须用
apierrors.IsAlreadyExists(err)（需导入k8s.io/apimachinery/pkg/api/errors） - 若想“确保存在”，更安全的做法是先
Get再按需Create，避免竞态（例如两个进程同时创建）
为什么不用 kubectl apply -f 的方式？
在 Go 程序中调用 exec.Command("kubectl", "apply", "-f", "...") 是常见误区，它带来额外依赖和不可控行为。
- 需要宿主机安装并配置好
kubectl和 kubeconfig，破坏可移植性 - 错误信息难捕获（stderr 混合输出，exit code 不够细粒度）
- 无法复用已有 clientset，每次调用都新建连接，性能差且易触发 API server 限流
- RBAC 权限模型下，Pod 的 ServiceAccount 权限 ≠ 本地 kubectl 用户权限，行为不一致
带 Labels 和 Finalizers 的生产级写法
单纯创建空 Namespace 很少用于生产；通常要附加元数据或控制生命周期。Finalizers 尤其关键——它能防止被意外删除。
立即学习“go语言免费学习笔记（深入）”；
-
Labels用于后续 selector 过滤（如kubectl get pods -n my-app-prod --selector="env=prod"） -
Finalizers是字符串切片，常用值为["kubernetes"]（默认值），自定义 finalizer 需配套控制器清理 - 注意：一旦设置了非默认 finalizer，该 Namespace 就不会被
kubectl delete ns立即移除，直到 finalizer 被清除
ns := &corev1.Namespace{
ObjectMeta: metav1.ObjectMeta{
Name: "my-app-prod",
Labels: map[string]string{
"env": "prod",
"team": "backend",
},
Finalizers: []string{"kubernetes"},
},
}
实际写的时候最容易漏掉的是 ctx 超时控制和 RBAC 权限验证——API 调用卡住或 403 报错，往往不是代码问题，而是 context 没设 deadline，或 ClusterRoleBinding 绑错了 ServiceAccount。 
