Operator启动无反应、无Reconcile日志，通常是RBAC权限缺失导致静默失败；需检查ClusterRole是否包含CR及下游资源的完整动词权限，并用kubectl auth can-i验证。
Operator 启动后没反应，日志里看不到 Reconcile 调用
这通常不是代码逻辑问题，而是 RBAC 或权限没配对。Operator 启动后会尝试 List/Watch 自定义资源（CR）和它要管理的下游资源（比如 Pod、Service），只要任一资源没权限，控制器就会静默失败——不报错、不 reconcile、也不 crash。
检查点：
- 确认
ClusterRole中包含你 CR 所在的apiVersion和kind，例如myapps.example.com/v1, Kind=MyApp - 确认对目标资源（如
apps/v1, Kind=Deployment）有get、list、watch、create、update、patch、delete全部动词 - 用
kubectl auth can-i list deployments --namespace=default模拟 operator 账户权限（注意 serviceaccount 名称和 namespace） - 临时把
manager.Options.MetricsBindAddress设为":8080"并加--enable-dynamic-configuration=false启动，避免 metrics server 干扰启动流程
本地调试时 Reconcile 函数被反复调用，但 CR 状态没更新
这是典型的“requeue 未控制”或“status 更新失败但没返回 error”导致的无限 reconcile 循环。Kubebuilder 默认在 Reconcile 返回 ctrl.Result{Requeue: true} 或非 nil error 时重入，但如果 status patch 失败却忽略错误，控制器会认为“这次没做完”，下一轮又来一遍。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 在
UpdateStatus后立刻检查 error：不要写_ = r.Status().Update(ctx, myapp)，必须if err != nil { return ctrl.Result{}, err } - 用
kubectl get myapps -o wide看AGE和REVISION是否持续跳变，确认是否真在循环 - 在
Reconcile开头加日志：log.Info("reconciling", "name", req.NamespacedName)，配合kubectl logs -f观察频率 - 避免在 reconcile 中做阻塞操作（如 HTTP 调用、time.Sleep），它们会拖慢队列处理，放大重试效应
Makefile 里的 make run 报错 no matches for kind "MyApp" in version "myapps.example.com/v1"
这不是 Operator 代码问题，而是 CRD 没装进集群。本地运行 make run 时 controller 直连 kube-apiserver，但不会自动安装 CRD —— 它只负责 reconcile，不负责 schema 注册。
解决步骤：
- 先执行
make install（它调用kubectl apply -f config/crd/bases/） - 确认 CRD 已就绪：
kubectl get crd | grep myapps，状态应为Established - 如果用
make run ENABLE_WEBHOOKS=false，确保config/webhook下的 manifests 没被误 apply；webhook 未就绪也会导致 CR 创建失败，间接让 reconcile 看不到对象 - CRD 的
spec.version必须和 controller 代码里scheme.AddKnownTypes(...)注册的版本完全一致（包括大小写），否则Get会返回NotFound而非你预期的实例
Webhook 日志空白，AdmissionReview 请求没进到 handler
Webhook 不是独立进程，它依赖 Kubernetes apiserver 主动发起调用；如果没日志，大概率是证书或服务配置没对上，请求根本没发出去。
关键验证项：
- 检查
ValidatingWebhookConfiguration中clientConfig.service.name和namespace是否与 webhook deployment 实际部署位置一致 - 确认 webhook service 的
port和 deployment 容器的containerPort匹配（默认 9443） - 用
kubectl get secret -n <your-ns> serving-cert -o jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt</your-ns>提取 CA，并验证它是否被注入到ValidatingWebhookConfiguration.clientConfig.caBundle - 临时把 webhook deployment 的 readiness probe 去掉，再
kubectl rollout restart deploy/<webhook-name></webhook-name>，避免 probe 失败导致 endpoint 被剔除
kubectl get events -A 和 kubectl describe crd，比单看 operator 日志更早暴露根因。 
