Flagger在EKS集群中CRD权限问题的排查与解决

问题背景

在使用Flagger进行渐进式交付时，用户报告了一个关键问题：当在本地Kind集群中部署Flagger时运行正常，但在Azure EKS集群（Kubernetes v1.27.9）上部署时，Flagger Pod会立即崩溃并报错。错误信息显示Flagger服务账号没有权限在集群范围内列出flagger.app API组中的canaries资源。

错误现象分析

Flagger启动时会对CRD进行验证，这是确保渐进式交付功能正常工作的前提条件。当部署到EKS环境时，出现了以下关键错误日志：

Canary CRD is not registered canaries.flagger.app is forbidden: User "system:serviceaccount:flagger-system:flagger" cannot list resource "canaries" in API group "flagger.app" at the cluster scope

虽然CRD本身的状态显示为正常（NamesAccepted和Established条件均为True），且RBAC配置看起来完整，但服务账号仍然无法执行必要的列表操作。

根本原因

经过深入排查，发现问题出在ClusterRoleBinding的配置上。在istio的patch.yaml文件中，服务账号的namespace被错误地指定为istio-system，而实际上Flagger的服务账号是部署在flagger-system命名空间中的。这个不匹配导致RBAC规则无法正确关联到服务账号。

解决方案

修正ClusterRoleBinding中的subject配置，确保namespace与Flagger实际部署的命名空间一致：

subjects:
  - kind: ServiceAccount
    name: flagger
    namespace: flagger-system  # 修正为实际的命名空间

经验总结

1. 跨环境部署验证：在本地环境（如Kind）工作正常的配置，在生产环境（如EKS）可能会因为RBAC等安全限制而失败，必须进行充分验证。

2. RBAC调试技巧：当遇到权限问题时，应该：

   • 确认服务账号的身份（通过describe pod查看）
   • 检查相关的ClusterRole和RoleBinding
   • 特别注意namespace的匹配性

3. 渐进式交付工具的特殊性：像Flagger这样的工具通常需要较宽的集群权限来监控和操作资源，在安全强化的环境中需要特别注意权限配置。

最佳实践建议

1. 在多集群部署时，建议使用统一的配置管理工具（如Kustomize或Helm）来保持配置一致性。

2. 对于生产环境，可以考虑：

   • 使用更细粒度的RBAC规则
   • 定期审计服务账号权限
   • 实现权限的最小化原则

3. 在部署类似Flagger的系统组件时，建议先手动验证服务账号的权限是否足够，可以使用kubectl auth can-i命令进行快速检查。

通过这次问题排查，我们不仅解决了特定的配置错误，更重要的是理解了在不同Kubernetes环境中部署复杂系统组件时需要注意的关键点，特别是跨命名空间的权限配置问题。