直接用client-go的Create/Delete会丢资源，因Kubernetes资源需经API Server→etcd→controller完整控制循环，Create返回仅表示写入etcd，不代表Pod运行或Deployment就绪；Delete后资源可能卡在Terminating状态，尤其含finalizer时。
为什么直接用 client-go 的 Create / Delete 会丢资源
因为 Kubernetes 资源不是“创建即存在”，而是走完整个控制循环：API Server 接收请求 → etcd 持久化 → controller 监听到变化 → 实际调度/拉起/清理。你调 Create 返回成功，只代表对象已写入 etcd，不代表 Pod 已 Running、Deployment 已 Ready。
常见现象是：刚 Create 完立刻 Get，返回 NotFound；或 Delete 后立即查，发现还在（尤其带 finalizers 的资源）。
怎么等 Deployment 真正 Ready 再继续
不能靠 sleep，得轮询其 status.conditions 和 status.replicas 字段。client-go 提供了 WaitForDeploymentComplete（v0.28+）和更底层的 WaitForCacheSync，但实际项目中建议自己写轮询逻辑，可控性更强：
for i := 0; i < 60; i++ {
dep, err := clientset.AppsV1().Deployments("default").Get(context.TODO(), "my-app", metav1.GetOptions{})
if err != nil {
return err
}
if dep.Status.AvailableReplicas >= dep.Spec.Replicas && dep.Status.ObservedGeneration >= dep.Generation {
return nil // Ready
}
time.Sleep(2 * time.Second)
}
return errors.New("deployment not ready in time")
- 检查
AvailableReplicas≥Replicas，而非ReadyReplicas（后者在滚动更新中可能暂时为 0） - 必须校验
ObservedGeneration≥Generation，否则可能读到旧状态缓存 - 超时时间别设太短——网络延迟、image pull、node 调度都可能耗时 10s+
如何安全删除带 finalizer 的资源（如 Namespace、CustomResource）
直接 Delete 只是打上 deletionTimestamp，真正清理由对应 controller 执行。如果 controller 崩溃或 finalizer 配错，资源会卡在 Terminating 状态。
手动干预前先确认 finalizer 来源：kubectl get ns my-ns -o yaml 查 metadata.finalizers。常见有 kubernetes（内置）、example.com/my-finalizer（自定义）。
立即学习“go语言免费学习笔记（深入）”；
- 不要直接 patch 掉 finalizer——绕过 controller 可能导致资源泄漏（如 PV 未解绑、LB 未释放）
- 若确定 controller 不再运行，且已手动清理下游依赖，才用
Patch清 finalizer：clientset.CoreV1().Namespaces().Patch(context.TODO(), "my-ns", types.JSONPatchType, []byte(`[{"op":"remove","path":"/metadata/finalizers"}]`), metav1.PatchOptions{}) - 对 CRD，优先检查其 controller 日志，而不是删 finalizer
StatefulSet 更新时如何避免滚动重启中断服务
默认 RollingUpdate 策略下，StatefulSet 会按序号从高到低重建 Pod，但新 Pod 启动完成前，旧 Pod 仍需提供服务——这要求 readiness probe 必须准确反映“可服务”状态，且 podManagementPolicy 不能误设为 Parallel。
- readiness probe 必须检查真实业务端口（如 HTTP
/healthz），不能只 check 进程存活 - 设置
minReadySeconds: 10，防止 Pod 刚 ready 就被下线 - 更新时用
Apply+ServerSideApply，避免因本地字段覆盖导致 spec 回滚 - 注意
revisionHistoryLimit：设太小会导致无法回滚，设太大则 etcd 存太多旧 ReplicaSet
生命周期不是 CRUD 的线性流程，而是和控制器、探针、etcd 一致性、网络就绪状态深度耦合的过程。漏掉任何一个环节的等待或校验，都会让“资源已部署”变成“看似部署成功”。
