用 client-go 删除命名空间必须传非空 *metav1.deleteoptions 且需轮询等待 finalizers 清空，因删除是异步的；卡在 terminating 时应检查并手动清理 finalizers。
用 client-go 调用 DeleteNamespace 必须等 Finalizers 清空
Go 里删 Namespace 不是发个 DELETE 请求就完事——Kubernetes 会先把它置为 Terminating 状态，然后等待所有 finalizers（比如 kubernetes、foregroundDeletion）被控制器逐个移除。直接调用 DeleteNamespace 后立刻检查，大概率看到它还卡在 Terminating。
- 必须传入非空
metav1.DeleteOptions{}，否则 API server 拒绝请求（400 Bad Request） - 若想跳过 graceful deletion，可设
PropagationPolicy为metav1.DeletePropagationBackground，但不推荐；Namespace 下的资源仍可能残留 - 常见错误：传了
&metav1.DeleteOptions{GracePeriodSeconds: new(int64)}却没初始化值，导致指针为 nil，client-go 报invalid value for gracePeriodSeconds
client-go 示例：带轮询等待的删除函数
以下代码片段封装了「触发删除 + 等待消失」的完整流程，适用于集成测试或运维工具：
func deleteNamespaceAndWait(ctx context.Context, clientset *kubernetes.Clientset, nsName string) error {
// 触发删除
if err := clientset.CoreV1().Namespaces().Delete(ctx, nsName, metav1.DeleteOptions{}); err != nil {
return fmt.Errorf("failed to delete namespace %s: %w", nsName, err)
}
// 轮询等待 Namespace 彻底消失
return wait.PollImmediate(2*time.Second, 60*time.Second, func() (bool, error) {
_, err := clientset.CoreV1().Namespaces().Get(ctx, nsName, metav1.GetOptions{})
if apierrors.IsNotFound(err) {
return true, nil
}
if err != nil {
return false, err
}
return false, nil
})
}
- 依赖
k8s.io/apimachinery/pkg/wait和k8s.io/apimachinery/pkg/api/errors - 超时设为 60 秒是经验值；有些集群因 finalizer 卡住（如 CSI driver 未响应），可能需要更久或人工干预
- 不要用
time.Sleep替代wait.PollImmediate—— 它无法感知 Namespace 是否已真正删除
Finalizer 卡住时怎么查和手动清理
如果 Namespace 长时间停留在 Terminating，90% 是 finalizer 没被清理。先确认状态：
kubectl get ns <ns-name> -o yaml</ns-name>
看输出里的 metadata.finalizers 字段。常见卡点：
-
kubernetes：说明还有 Pod/Service 等资源未删干净，检查kubectl get all -n <ns-name></ns-name> -
foregroundDeletion：通常因某子资源设置了ownerReferences.blockOwnerDeletion=true且其控制器离线 -
servicecatalog.k8s.io或其他第三方 finalizer：需对应 controller 正常运行
强制清理 finalizer 属于危险操作，仅限调试环境：
kubectl get ns <ns-name> -o json \ | jq 'del(.spec.finalizers[])' \ | kubectl replace --raw "/api/v1/namespaces/<ns-name>/finalize" -f -</ns-name></ns-name>
用 kubectl 命令行删完，Go 程序里为什么还查得到？
不是 Go 代码问题，而是缓存或延迟。Kubernetes API server 的 etcd 写入、watch 事件分发、client-go informer 缓存更新都有毫秒级延迟。典型表现：
- 刚执行完
kubectl delete ns foo，立刻在 Go 里调用Get还返回对象（状态为Terminating） - client-go 使用
SharedInformer时，默认缓存不会自动刷新已删除对象，需靠 watch 事件触发清理 - 解决方案：不用 informer 查 Namespace 删除状态，直接走实时
Get+IsNotFound判断；或者给 informer 加ResyncPeriod缩短缓存陈旧窗口
Finalizer 处理逻辑分散在多个控制器中，没有统一入口；一旦卡住，得顺着 finalizer 名称定位对应组件，而不是指望一个 Delete 调用能自动兜底。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
