Reconcile 函数中安全创建 DeploymentOperator 需先检查 Deployment 是否存在，再决定 Create 或 Patch；必须设置 ControllerReference、避免字段丢失、正确处理 ResourceVersion 和 Status 子资源更新，并确保 CRD 与 Scheme 已提前注册。
Reconcile 函数里怎么安全创建 Deployment
Operator 启动后没反应，或者 Deployment 被反复重建、字段莫名丢失——大概率出在 Reconcile 里创建或更新 Deployment 的逻辑上。这不是“写个 client.Create 就完事”的问题。
关键点在于：不能假设 Deployment 一定不存在，也不能每次调谐都删了重来；必须尊重 Kubernetes 的声明式语义和资源生命周期。
- 先用
r.Get(ctx, types.NamespacedName{Namespace: ns, Name: name}, &dep)查是否存在，apierrors.IsNotFound(err)判断后再决定是Create还是Patch - 创建时务必调用
ctrl.SetControllerReference(&myapp, &dep, r.Scheme)，否则删除 CR 后 Deployment 不会级联清理 - 更新 Deployment 时，如果只改
spec.replicas却没保留spec.template.spec.containers[0].image，字段会被清空——因为默认 JSON Merge Patch 会覆盖整个containers数组；改用client.Patch+client.MergeFrom或显式标注 struct tag：json:"image,omitempty" patchStrategy:"retainKeys" patchMergeKey:"name" - 不要在
Reconcile里直接 new 一个appsv1.Deployment然后填字段就提交；要确保ObjectMeta.GenerateName为空、ResourceVersion为 ""（创建时），且OwnerReferences已正确注入
CRD 安装失败导致 Operator 启动 panic
报错 no matches for kind "MyApp" in version "apps.example.com/v1"，说明 Operator 启动时尝试监听 CR 类型，但 API Server 根本不认识这个资源。这不是代码 bug，是部署顺序错了。
CRD 必须在 Operator 启动前完成注册，且 controller-runtime 的 Scheme 也必须显式注册该类型，否则 r.Get 会静默失败或 panic。
- 手动部署：先
kubectl apply -f config/crd/bases/...，确认kubectl get crd myapps.apps.example.com返回 READY 状态 - 用
make install（Kubebuilder 项目）或make manifests && kubectl apply -f config/crd/bases/，别跳过这步直接make run - 检查 Go 类型是否已加入 Scheme：确认
api/v1/register.go中有AddToScheme调用，且main.go初始化mgr前已执行myappv1.AddToScheme(mgr.GetScheme()) - 如果用
controller-gen生成 CRD，确保 Go 结构体字段带完整json:tag 和//+kubebuilder:validation注释，否则生成的 OpenAPI schema 缺失字段，kubectl apply可能成功但后续Get失败
为什么 Status 更新总失败或不生效
r.Status().Update(ctx, &myapp) 报 Operation cannot be fulfilled on myapps.apps.example.com ... the object has been modified，或者日志里明明调了却看不到 status 字段变化——本质是并发冲突和子资源访问权限问题。
Status 是独立子资源，Kubernetes 要求用专用 endpoint（/status）更新，且必须带最新 ResourceVersion。直接 r.Update 会失败。
- 必须用
r.Status().Update(ctx, &myapp)，不能用r.Update；且该对象必须是从r.Get加载出来的（含当前ResourceVersion） - RBAC 清单里必须包含
verbs: ["update"]对应subresources: ["status"]，例如：- apiGroups: ["apps.example.com"] resources: ["myapps/status"] verbs: ["update"] - 不要在 Status 更新前修改 Spec 字段（比如误写成
myapp.Spec.Replicas++），这会导致对象校验失败 - 调试时用
kubectl get myapp myinstance -o yaml看status:下是否有内容；若为空，再查 Operator 日志中name=myinstance对应的行，看是否返回 error 或被 ignore
本地调试时 Reconcile 不触发
改了 CR YAML 并 kubectl apply，Operator 日志毫无反应——不是代码没跑，是监听器根本没注册上。
ctrl.NewControllerManagedBy(mgr) 的链式调用必须完整，漏掉 .For(...) 或 .Owns(...)，控制器就不会 watch 任何资源。
- 确保
SetupWithManager方法里有完整链式调用：ctrl.NewControllerManagedBy(mgr).For(&myappv1.MyApp{}).Owns(&appsv1.Deployment{}).Complete(r) -
.For(&MyApp{})告诉控制器监听哪种 CR；.Owns(&Deployment{})表示当它创建的 Deployment 发生变更（如 Pod 重启），也要触发本 CR 的 Reconcile —— 漏掉这句，Deployment 状态变化就不会驱动调谐 - 本地运行用
make run，别用go run main.go，后者不会加载config/rbac和config/manager配置，可能导致 client 权限不足或 scheme 未初始化 - 检查日志开头是否有
Starting manager和Starting workers，没有说明 Manager 没启动成功；若有但无Reconciler相关日志，大概率是.For类型注册错误或 namespace 限制（比如控制器默认只 watch 当前 namespace，而 CR 在别的 namespace）
Reconcile 的真正难点不在语法，而在状态收敛的边界条件：CR 被删但子资源还在、Deployment 更新中 Pod 处于 Pending、Status 更新冲突后要不要重试、OwnerReference UID 不匹配导致级联失效……这些都不会报编译错误，但会让 Operator 在生产环境静默失联。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
