Kubernetes Operator 是运行在集群中、基于 Reconcile 函数实现声明式闭环控制的控制器程序，依赖 CRD 定义资源并由 controller-runtime 驱动，需严格配置 RBAC、ownerReference 和 Status 更新方式。
Go 语言编写的 Kubernetes Operator 不是一个“工具”或“插件”，而是一个运行在集群中、持续监听自定义资源（CR）变化并调谐实际状态的控制器程序。它的本质是：用 Reconcile 函数实现的声明式闭环控制逻辑，背后依赖 controller-runtime 框架驱动。
CRD 是 Operator 的“身份证”，不是可选配置
没有 CRD，Kubernetes 就不认识你定义的资源，Operator 再完整也无从触发。它不是单纯为了“加个类型”，而是让 API Server 能校验、存储、广播你的资源对象。
-
apiVersion: apiextensions.k8s.io/v1必须用 v1（v1beta1 已弃用），否则kubectl apply会静默失败或被 kube-apiserver 拒绝 -
spec.validation.openAPIV3Schema建议强制加上，比如对spec.replicas限制为minimum: 1，否则用户提交负数或字符串时，错误只在Reconcile阶段才暴露，日志里看到的是 client-go 的泛型报错，难定位 - CRD 的
group和version一旦发布，就几乎不可更改——升级时若要改 version（如 v1alpha1 → v1），必须新建 CRD 并迁移数据，旧 CRD 删除前所有 CR 实例会丢失
Reconcile 函数不是事件处理器，而是状态对齐循环
很多人误以为 Reconcile 只在 CR 创建时执行一次，其实它会被反复调用：CR 更新、关联 Deployment 被手动删掉、甚至只是 Informer 缓存同步延迟都会触发。它的设计目标是“无论当前状态如何，都能收敛到 Spec 所述期望状态”。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 不要在
Reconcile里写“首次初始化逻辑”（如生成随机密码），而应检查myapp.Status.SecretName != ""再跳过；否则每次调谐都重置密码，导致服务中断 - 所有子资源（Deployment、Service 等）必须设置
ownerReference，否则用户删掉 CR 后，这些资源不会自动清理，变成“孤儿” - 更新
Status必须用r.Status().Update(ctx, &myapp)单独调用，不能和 Spec 更新混在同一个Update请求里——Kubernetes 会返回Invalid: status错误
本地调试时，KUBECONFIG 不等于“能跑通”，权限才是关键
用 go run main.go 直连集群很便捷，但极易因 RBAC 权限不足卡在第一步：r.Get(ctx, req.NamespacedName, &myapp) 返回 403 Forbidden，而错误日志只显示 “failed to get MyApp”，看不出是权限问题。
立即学习“go语言免费学习笔记（深入）”；
- 确保
make install（安装 CRD）和make deploy（部署 RBAC+Manager）都执行过；仅make install不会创建 ClusterRoleBinding - 本地调试时，RBAC 清单（
config/rbac/role.yaml）里的rules必须覆盖所有实际访问的资源：比如用了client.CoreV1().Secrets()，就得有secrets的get/list/watch权限，缺一条就会失败 - 别依赖
cluster-admin角色调试——它掩盖真实权限缺陷，上线后在生产环境必然崩
Operator 最容易被低估的复杂点，不在 Go 语法或 controller-runtime API，而在“状态收敛”的边界处理：网络抖动导致一次 Get 失败，是否该重试？Deployment 处于 Progressing 状态时，是否该更新 CR 的 Status.Conditions？这些问题没有标准答案，只能靠对业务终态的精确建模和大量真实场景下的观测来打磨。
