Operator核心是理解Kubernetes控制循环：监听资源、比对期望与实际状态、调用API修正；Go只是工具，关键在幂等、非阻塞、使用controller-runtime的Reconcile函数，并正确处理CRD、OwnerReference、Finalizer及调试日志。
Operator 核心不是写 Go，是理解 Kubernetes 的控制循环
你写的不是普通服务，而是一个“控制器”：监听资源变化、比对期望状态与实际状态、调用 API 做出修正。Go 只是实现工具，关键在 Reconcile 函数里怎么定义“该做什么”。很多人一上来就猛写业务逻辑，结果 Operator 启动后不响应、反复报错、状态卡死——根本原因是没先理清你要控制的资源对象（CRD）和它依赖的内置资源（如 Deployment、Service）之间怎么联动。
- 先手工写好 CRD YAML，用
kubectl apply注册，再生成 Go 类型（用controller-gen），别跳过这步；否则结构体字段和 API Server 不一致，Get/Update直接静默失败 -
Reconcile函数必须是幂等的：同一请求来 10 次，效果和来 1 次一样；不能在里面做“创建一次就永久生效”的操作（比如写本地文件、发一次 webhook） - 不要在
Reconcile里 sleep 或阻塞；Kubernetes 会超时重试，导致队列积压、状态漂移
用 controller-runtime 写 Reconcile，别自己封装 clientset
官方 client-go 太底层，手动处理 informer、listwatch、retry 逻辑极易出错。controller-runtime 封装了标准控制循环，还自带 Manager、Client、Log 和测试工具。新手硬啃 client-go 反而拖慢进度、引入竞态。
- 初始化用
ctrl.NewManager，不是clientset.NewForConfig；它的Client支持直接操作 CRD 实例，无需手动序列化/反序列化 - 获取资源优先用
mgr.GetClient().Get(ctx, key, obj)，而不是clientset.CoreV1().Pods(ns).Get；前者自动处理 scheme、GVK 映射，后者对 CRD 无效 - 更新对象必须用
Update或Patch，别用Create覆盖；否则会丢掉 metadata.generation、ownerReferences 等关键字段
调试 Reconcile 失败：看 Events 和日志里的 Request 名字
Operator 不工作？90% 是 Reconcile 返回了 error，触发重试，但你没看到具体哪次失败。Kubernetes 会把错误记到对应资源的 Events 里，同时 controller-runtime 日志开头固定带 Reconciler group=xxx kind=xxx name=xxx —— 这个 name=xxx 就是你该查的日志锚点。
- 用
kubectl describe mycrd/myinstance查 Events，里面会显示 “Reconcile error: xxx” - 日志里搜
name=myinstance，定位到那一行，看 error 是否是not found（对象被删了但 finalizer 没清理）、invalid value（struct 字段 tag 写错）、或conflict（两个 goroutine 同时改同一个对象） - 别依赖
fmt.Println；用log.WithValues("name", req.Name)打日志，否则海量请求下根本分不清谁是谁
Finalizer 和 OwnerReference 漏写，会导致资源删不干净
Operator 管理的子资源（比如它创建的 Deployment）必须绑定到自定义资源上，否则用户删 CR 时，这些子资源还在集群里飘着。靠的是 OwnerReference；而防止误删、支持优雅清理的机制是 Finalizer。这两处漏掉，你的 Operator 就算功能全对，也会被运维打回来。
立即学习“go语言免费学习笔记（深入）”；
- 创建子资源前，先用
ctrl.SetControllerReference设置OwnerReference；别手写，它会自动填blockOwnerDeletion=true和正确uid - 在 CR 首次创建时加 finalizer：
mycrd.Finalizers = append(mycrd.Finalizers, "mydomain.io/cleanup")；然后在Reconcile里检查deletionTimestamp != nil，才去删子资源 - 子资源删完，再从 CR 的 finalizers 列表里移除对应项并
Update；否则 Kubernetes 永远不会真正删除这个 CR
Operator 的复杂性不在语法，而在状态收敛的边界条件：资源被手动删了怎么办、APIServer 临时不可达怎么重试、多个实例同时更新一个共享 ConfigMap 怎么避免冲突。这些没法靠模板解决，得在每次 Reconcile 的 if 分支里想清楚。
