Flagger项目中从HPA迁移至KEDA Scaled Object的实践指南

背景介绍

在Kubernetes生态系统中，Flagger作为一款渐进式交付工具，常与Horizontal Pod Autoscaler(HPA)或KEDA Scaled Object结合使用来实现应用自动扩展。当用户需要从传统的HPA迁移到更灵活的KEDA Scaled Object时，会遇到一些特定的技术挑战。

问题本质

迁移过程中，Flagger会尝试为金丝雀部署创建主版本(Primary)的Scaled Object，但此时系统中可能仍存在由旧版HPA创建的主版本HPA资源。KEDA的准入控制器会阻止这种"一个工作负载被多个自动扩展器管理"的情况，导致迁移失败。

技术原理深度解析

1. 所有权冲突机制：KEDA通过内置的准入控制webhook(vscaledobject.kb.io)确保每个工作负载(如Deployment)只能由一个自动扩展器管理，无论是HPA还是Scaled Object。

2. HPA接管机制：KEDA提供了scaledobject.keda.sh/transfer-hpa-ownership注解，允许Scaled Object接管现有HPA的所有权，而不是创建新的HPA。

3. Flagger的工作机制：当检测到Canary资源中autoscalerRef从HPA变更为Scaled Object时，Flagger会：

   • 创建目标Scaled Object
   • 尝试创建主版本Scaled Object
   • 但不会自动清理旧的主版本HPA

解决方案实现

要实现平滑迁移，需要在Flagger中增强Scaled Object的创建逻辑：

1. 注解继承：主版本Scaled Object应继承目标Scaled Object的所有注解，特别是所有权转移注解。

primarySo = &keda.ScaledObject{
    ObjectMeta: makeObjectMetaSo(primarySoName, targetSoClone.Labels, targetSoClone.Annotations, cd),
    Spec:       soSpec,
}

2. HPA命名配置：确保主版本Scaled Object生成的HPA名称与预期一致。

Advanced: &keda.AdvancedConfig{
    HorizontalPodAutoscalerConfig: &keda.HorizontalPodAutoscalerConfig{
        Name:     primaryName,
    },
},

3. 存在性检查：在创建主版本Scaled Object前，检查同名HPA是否存在，动态决定是否添加所有权转移注解。

实践建议

对于正在考虑从HPA迁移到KEDA的用户，建议采用以下步骤：

1. 准备阶段：

   • 确保KEDA控制器已正确安装
   • 验证现有HPA的工作状态
   • 准备包含所有权转移注解的Scaled Object定义

2. 迁移阶段：

   • 先创建带有转移注解的Scaled Object
   • 再更新Canary资源的autoscalerRef
   • 监控Flagger日志确认迁移状态

3. 验证阶段：

   • 检查主版本和工作版本的自动扩展行为
   • 验证自定义指标是否生效
   • 确保没有资源冲突

技术展望

这种迁移模式展示了Kubernetes生态系统中不同组件间的协作方式。未来可能会有更智能的资源迁移机制，例如：

• 自动检测并解决资源冲突
• 提供迁移状态仪表板
• 支持回滚到原始自动扩展器

通过理解这些底层机制，运维团队可以更自信地管理生产环境中的自动扩展策略变更，实现从传统HPA到更先进的KEDA解决方案的无缝过渡。