17370845950

直接写 Reconcile 函数容易失败，因其依赖 Manager、Controller、Watch 三层注册；漏掉任意一环（如未调用 For() 或 Owns()）则不会触发，且需确保 CRD 已存在、RBAC 授权完备、Leader 选举正确配置。

为什么直接写 Reconcile 函数容易失败

绝大多数新手在写 Kubernetes 自定义控制器时，第一反应是“先实现 Reconcile 方法”，但很快会发现：对象没更新、日志不打印、甚至整个 Reconcile 根本没被调用。根本原因不是逻辑错，而是没走通控制器启动链路——Reconcile 是被动触发的，依赖 Manager、Controller、Watch 三层注册。漏掉任意一环（比如忘记调用 ctrl.NewControllerManagedBy(mgr).For(&v1.Pod{})），就不会监听任何资源。

• Reconcile 不是入口函数，它必须由 controller-runtime 的调度器调用，而调度器只认注册过的 For() / Owns() 类型
• 如果 Reconcile 接收参数不是 context.Context 和 ctrl.Request，编译能过但运行时报 cannot convert ... to reconcile.Reconciler
• 返回 ctrl.Result{} 或 error 必须明确：返回 nil 表示成功且不重试；返回非 nil error 会触发指数退避重试；返回 ctrl.Result{RequeueAfter: time.Second} 是主动延时重入，不是错误

如何正确初始化 Manager 并启用 Leader 选举

本地开发时跳过 Leader 选举看似省事，但上线后多副本会同时处理同一事件，导致状态冲突。controller-runtime 默认不开启 Leader 选举，必须显式配置，且依赖 kube-system 中的 ConfigMap 或 Lease 资源。

• 启用方式：传入 manager.Options{LeaderElection: true, LeaderElectionID: "my-controller.mydomain.io"}，ID 必须全局唯一，且符合 DNS 子域名规则（只能含小写字母、数字、连字符）
• 若集群 RBAC 未授权访问 leases.coordination.k8s.io，启动会卡在 waiting for leader election，需提前部署对应 ClusterRoleBinding
• 本地调试可临时禁用：LeaderElection: false，但务必在 main.go 里加注释提醒，避免误提交到生产配置

Watches 配置错一个字段，整个控制器就静默失效

控制器是否能感知资源变化，完全取决于 Watches 链路是否完整。常见失效场景不是代码写错，而是类型注册或事件过滤配置不当。

• For(&v1.Pod{}) 只监听 Pod 资源本身；若想监听 Pod 所属的 Deployment 变更，必须额外加 Owns(&appsv1.Deployment{})
• 使用 WithEventFilter 时，Generic 事件默认不触发 Reconcile，除非显式允许：predicate.Funcs{GenericFunc: func(e event.GenericEvent) bool { return true }}
• 若监听自定义资源（CRD），必须确保该 CRD 已在集群中 kubectl apply -f crd.yaml 成功，否则 For(&myv1.MyResource{}) 会 panic 报 no matches for kind

调试时 Reconcile 日志不输出？先查 Log 是否绑定到请求上下文

controller-runtime 的日志默认按 Request 绑定，如果在 Reconcile 外部（如 init 函数、全局变量初始化）用 log.Info，日志会丢失 request ID，且可能因 logger 未初始化而静默丢弃。

• 正确做法：所有日志都通过 reqLogger := log.WithValues("name", req.NamespacedName.Name, "namespace", req.NamespacedName.Namesp

  

  ace) 派生，再调用 reqLogger.Info(...)
• 若看到日志只有 level=info msg="Starting workers" 却没有后续 Reconcile 日志，大概率是 SetupWithManager 返回了 error 但被忽略，需检查 err := r.SetupWithManager(mgr); if err != nil { os.Exit(1) }
• 用 kubectl logs -n myns my-controller-xxx --since=10s 查实时日志，别只看 IDE 控制台——本地调试时，manager 启动后才开始接收事件，早于启动的日志不会回显

func (r *MyReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
	reqLogger := log.FromContext(ctx).WithValues("myresource", req.NamespacedName)
	reqLogger.Info("starting reconcile")

	var myObj myv1.MyResource
	if err := r.Get(ctx, req.NamespacedName, &myObj); err != nil {
		reqLogger.Error(err, "unable to fetch MyResource")
		return ctrl.Result{}, client.IgnoreNotFound(err)
	}

	// 实际业务逻辑...
	reqLogger.Info("reconcile completed")
	return ctrl.Result{}, nil
}

Kubernetes 控制器不是写完 Reconcile 就能跑起来的程序，它是嵌套在 manager 生命周期里的事件处理器。最容易被忽略的是：watch 注册和 manager 启动顺序必须严格匹配，且所有资源类型（包括 CRD）必须在控制器启动前就存在于集群中。