KEDA证书认证失败问题分析与解决方案

问题背景

在Kubernetes环境中使用KEDA（Kubernetes Event-driven Autoscaling）时，用户从2.11.2版本升级到Helm chart 2.13.2后，出现了TLS认证握手失败的问题。具体表现为keda-operator-metrics-apiserver无法建立与KEDA Metrics Server的gRPC连接，错误提示证书签名验证失败。

问题现象

1. 连接失败：metrics-apiserver日志显示gRPC连接失败，错误信息表明无法验证证书签名
2. 证书变化：升级后发现新增了kedaorg-ca（CA证书）和kedaorg-certs（自签名证书）两个Secret，而之前版本只有kedaorg-certs一个Secret
3. API服务异常：metrics-apiserver不断尝试向Kubernetes API服务器注册自定义APIService，导致API服务器负载增加

根本原因分析

1. 证书机制变更：新版本KEDA引入了更完善的证书管理机制，使用CA证书（kedaorg-ca）为服务证书（kedaorg-certs）签名
2. 证书挂载不全：metrics-apiserver部署中只挂载了服务证书（kedaorg-certs），没有挂载CA证书，导致无法验证服务端证书链
3. 证书自动更新：问题可能与证书自动更新过程有关，特别是在证书轮换期间

解决方案

临时解决方案

手动修改metrics-apiserver部署，添加CA证书挂载：

volumes:
- name: ca-certificates
  secret:
    secretName: kedaorg-ca

长期解决方案

1. 升级到最新版本：确保使用KEDA最新版本，其中可能已修复此问题
2. 检查Helm配置：确认values.yaml中没有禁用证书相关功能
3. 监控证书更新：设置监控告警，及时发现证书更新问题

技术细节

1. 证书验证流程：

   • KEDA Metrics Server使用服务证书（kedaorg-certs）建立TLS连接
   • 该证书由KEDA CA（kedaorg-ca）签名
   • metrics-apiserver需要CA证书来验证服务端证书链

2. 证书自动管理：

   • KEDA使用cert-controller自动管理证书
   • 证书轮换时可能出现短暂的服务中断
   • 系统应能自动恢复，但本例中出现了配置不完整的情况

最佳实践建议

1. 升级前检查：在升级KEDA前，检查证书相关配置的变化
2. 监控日志：特别关注证书相关的错误日志
3. 测试环境验证：先在测试环境验证升级过程
4. 了解证书生命周期：熟悉KEDA的证书管理机制，特别是自动更新过程

总结

KEDA作为Kubernetes事件驱动自动扩展的重要组件，其证书管理机制的改进带来了更高的安全性，但也可能引发配置问题。理解证书验证流程和组件间的信任关系，是解决此类TLS问题的关键。通过正确配置证书挂载和及时更新版本，可以确保KEDA稳定可靠地运行。