如何用controller-runtime优雅实现可配置资源的K8s备份控制器？

你不需要为每个监听资源单独创建Controller，也不用抛弃controller-runtime——下面是几种符合K8s生态惯例的实现方案，按推荐程度排序：

方案一：复用单个Controller，自定义事件路由（最优） #

这是最优雅的方式，既贴合controller-runtime的设计，又能高效处理多资源监听：

• 先通过配置解析出所有要监听的GroupVersionKind（GVK），然后遍历这些GVK，用ctrl.NewControllerManagedBy(mgr)创建主Controller，通过Watches方法为每个资源类型绑定自定义事件处理器，而不是用默认的EnqueueRequestForObject。
• 自定义事件处理器的核心是：把触发事件的资源类型（GVK）、名称、命名空间打包成自定义请求，塞进Controller的工作队列。
• Reconcile方法拿到这个自定义请求后，解析出GVK和资源标识，再用动态Client获取资源对象，执行统一的备份逻辑。

举个代码片段示例：

// 自定义请求结构体，用来传递资源类型和标识
type BackupReq struct {
    GVK       schema.GroupVersionKind
    ObjectKey client.ObjectKey
}

// 实现runtime.Object接口（空实现，仅用于队列传递）
func (r *BackupReq) GetObjectKind() schema.ObjectKind { return schema.EmptyObjectKind }
func (r *BackupReq) DeepCopyObject() runtime.Object {
    return &BackupReq{GVK: r.GVK, ObjectKey: r.ObjectKey}
}

// 自定义事件处理器
type backupHandler struct {
    targetGVK schema.GroupVersionKind
}

func (h *backupHandler) Create(evt event.CreateEvent, q workqueue.RateLimitingInterface) {
    key, _ := client.ObjectKeyFromObject(evt.Object)
    q.Add(&BackupReq{GVK: h.targetGVK, ObjectKey: key})
}

// 同理实现Update、Delete方法...

// 初始化时动态添加所有监听资源
for _, resStr := range yourConfig.Resources {
    gvk, err := schema.ParseGroupVersionKind(resStr)
    if err != nil { /* 处理错误 */ }
    // 创建对应资源的空对象
    obj, err := yourScheme.New(gvk)
    if err != nil { /* 处理错误 */ }
    
    // 绑定到主Controller
    ctrl.NewControllerManagedBy(mgr).
        For(obj).
        Watches(&source.Kind{Type: obj}, &backupHandler{targetGVK: gvk})
}

// Reconcile方法逻辑
func (r *BackupReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
    // 这里需要把req转换成自定义的BackupReq
    // （controller-runtime默认会序列化请求，所以可以通过req.Name/Namespace传递拼接后的信息，或者自定义请求解析逻辑）
    backupReq, err := parseRequestToBackupReq(req)
    if err != nil { return ctrl.Result{}, err }
    
    // 用动态Client拉取资源
    obj, err := r.DynamicClient.Resource(backupReq.GVK.GroupVersion().WithResource(backupReq.GVK.Kind)).
        Namespace(backupReq.ObjectKey.Namespace).
        Get(ctx, backupReq.ObjectKey.Name, metav1.GetOptions{})
    if err != nil { return ctrl.Result{}, err }
    
    // 执行备份逻辑
    r.backupToExternalStore(obj, backupReq.GVK)
    return ctrl.Result{}, nil
}

方案二：为每个资源创建独立Controller（可行但不推荐） #

确实可以给每个监听资源单独建Controller，每个Controller绑定一个Reconciler（或者复用同一个Reconciler，通过构造函数传入资源类型）：

• 技术上完全可行：controller-runtime支持同时运行多个Controller，每个有独立的Informer、工作队列和goroutine。
• 但有明显副作用：资源占用随监听资源数量线性增长，配置和监控的复杂度也会上升。
• 只有当不同资源的备份逻辑差异极大，且需要独立的队列重试、QoS控制时，才考虑这种方式。

方案三：直接使用动态Informer（兼容controller-runtime） #

如果你更习惯直接用client-go的Informer机制，也可以在controller-runtime的manager框架下实现：

• 基于动态Client创建每个资源的SharedIndexInformer，添加自定义事件处理函数直接触发备份。
• 把Informer注册到manager中，由manager统一管理启动和停止，这样依然能复用controller-runtime的配置、客户端等基础设施。
• 缺点是会失去controller-runtime提供的Reconcile重试、队列限流等便利特性，适合需要更底层控制的场景。

总结 #

优先选方案一：既符合controller-runtime的设计惯例，又能以较低的资源开销处理多资源监听，逻辑统一且易于维护。

内容的提问来源于stack exchange，提问作者DonGiovanni