Argo Helm 中 Redis-HA 禁用 Haproxy 导致的部署问题分析

问题背景

在使用 Argo Helm Chart 部署 Argo CD 时，当配置 Redis 高可用(Redis-HA)模式并禁用 Haproxy 组件时，会导致生成的 Kubernetes 部署清单中出现空白的 Secret 名称引用，进而引发部署失败。

技术细节

问题表现

当在 values.yaml 中配置以下参数时：

redis-ha:
  enabled: true
  haproxy:
    enabled: false

Helm 模板生成的部署清单中，Redis Sentinel 相关的环境变量会出现空白的 Secret 名称：

- name: REDIS_SENTINEL_USERNAME
  valueFrom:
    secretKeyRef:
      name: ""  # 这里应为有效的 Secret 名称
      key: redis-sentinel-username
      optional: true

根本原因

问题源于 Helm 模板中的辅助函数设计缺陷。当前模板中的 argo-cd.redis-ha.fullname 辅助函数仅考虑了 Haproxy 启用时的情况，当禁用 Haproxy 时，函数返回空值，导致生成的 Secret 名称为空。

影响范围

此问题主要影响以下组件：

1. Argo CD Repo Server 部署
2. Argo CD Server 部署

这些组件依赖 Redis Sentinel 的用户名和密码进行认证，当 Secret 名称为空时，Kubernetes 会拒绝创建/更新这些部署。

解决方案分析

临时解决方案

目前可以通过以下方式临时解决：

1. 保持 Haproxy 启用状态
2. 手动指定 Redis Sentinel 的 Secret 名称

长期修复建议

从技术实现角度，建议在 Helm Chart 中进行以下改进：

1. 修改辅助函数，增加对禁用 Haproxy 情况的处理：

{{- define "argo-cd.redis-ha.fullname" -}}
{{- if .Values.redis-ha.haproxy.enabled -}}
{{- printf "%s-haproxy" (include "argo-cd.redis-ha.name" .) -}}
{{- else -}}
{{- printf "%s-redis" (include "argo-cd.redis-ha.name" .) -}}
{{- end -}}
{{- end -}}

2. 或者在部署模板中添加条件判断，当禁用 Haproxy 时跳过相关环境变量的注入。

最佳实践建议

对于生产环境使用 Redis-HA 的场景，建议：

1. 评估是否真正需要禁用 Haproxy，因为 Haproxy 提供了重要的负载均衡功能
2. 如果必须禁用 Haproxy，确保正确配置 Redis Sentinel 的认证信息
3. 考虑使用外部 Redis 集群而非内置 Redis-HA，以获得更好的控制性和灵活性

总结

这个问题揭示了 Helm Chart 中条件逻辑处理的重要性。作为基础设施代码，Helm Chart 需要全面考虑各种配置组合的边界情况。开发者在自定义配置时也应当注意检查生成的清单文件，确保所有必要的引用都正确填充。