在Kubernetes上用Bitnami Helm Chart配置Redis ACL规则遇问题

1. 先查崩溃日志定位根因 #

服务看似无报错直接崩溃，其实Redis启动时的错误日志大概率存在Pod的历史日志里，先执行命令获取：

kubectl logs <redis-pod-name> --previous

（--previous参数可以获取上次崩溃时的启动日志，能直接拿到加载失败的具体错误信息）

2. 修复ACL文件的权限问题 #

Kubernetes Secret挂载的文件默认权限是0600，而Bitnami Redis容器的运行用户是redis（UID 1001），如果文件所属用户/权限不对，Redis会因读不到ACL文件直接崩溃。

修改挂载配置，指定权限和运行用户：

extraVolumes:
  - name: redis-acl
    secret:
      secretName: your-acl-secret
      items:
        - key: acl-file.conf
          path: acl-file.conf
          mode: 0644  # 设置全局可读权限
extraVolumeMounts:
  - name: redis-acl
    mountPath: /etc/redis/acl-file.conf
    subPath: acl-file.conf
    readOnly: true
    securityContext:
      runAsUser: 1001  # 匹配Redis容器的运行用户UID

3. 验证并修正ACL文件语法 #

Redis 6.2的ACL语法要求严格，检查你的文件：

• 每行末尾不要留多余空格（你提供的第二行末尾有空格，会导致解析错误）
• 密码前的>和密码之间不能有空格
• 确保@all、@dangerous这类权限组拼写正确（Redis 6.2原生支持）

修正后的ACL文件：

user foo +@all ~* on >somepassword
user bar +@all -@dangerous on >someotherpassword

4. 解决Chart auth配置与自定义ACL的冲突 #

当你设置auth.enabled=true时，Bitnami Chart会自动添加requirepass指令，Redis 6.2会将这个密码映射到default用户。但如果加载自定义ACL文件，default用户的规则会被覆盖，导致认证逻辑冲突。

两种解决方式：

• 方案一：关闭Chart自带的auth配置（auth.enabled=false），在ACL文件中定义所有用户（包括管理员用户）
• 方案二：在ACL文件中显式定义default用户，匹配Chart设置的root密码：

  user default on >rootpassword ~* +@all
  user foo +@all ~* on >somepassword
  user bar +@all -@dangerous on >someotherpassword
  

  这样既保留原有的root密码认证，又能加载自定义权限规则。

5. 确认挂载路径的可用性 #

Bitnami Redis容器的默认配置目录是/opt/bitnami/redis/etc/，你可以尝试将ACL文件挂载到这个目录下，避免路径权限问题：

extraVolumeMounts:
  - name: redis-acl
    mountPath: /opt/bitnami/redis/etc/acl-file.conf
    subPath: acl-file.conf
    readOnly: true

同时修改commonConfiguration中的路径：

commonConfiguration: |-
  appendonly yes
  save ""
  aclfile /opt/bitnami/redis/etc/acl-file.conf

6. 本地测试ACL文件有效性 #

先在本地Redis 6.2实例中测试你的ACL文件，确认能正常启动：

redis-server --aclfile /path/to/your/acl-file.conf

如果本地启动正常，说明文件本身没问题，问题出在K8s挂载或Chart配置环节。

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