使用Helm在私有K8s部署pgadmin后登录失败问题排查

核心原因分析 #

从你的配置来看，Pod环境变量中的邮箱和密码配置正确，但登录失败，大概率和持久化存储相关：

1. 旧存储数据残留：你的PVC/PV使用Retain回收策略，如果之前部署过pgAdmin，存储路径中可能保留了旧的用户配置数据——pgAdmin首次启动后会优先读取存储中的本地配置，忽略环境变量的新设置。
2. 存储路径权限异常：本地PV的挂载路径/mnt/disks/ssd1权限可能不匹配pgAdmin容器的运行用户（默认UID为5050），导致容器无法正确初始化或读取用户配置文件。

分步解决方案 #

1. 先验证无持久化时的登录情况 #

临时修改Helm values，禁用持久化存储，测试基础功能是否正常：

persistentVolume:
  enabled: false
# 其余配置保持不变

执行Helm升级：

helm upgrade <你的release名称> <chart路径> -f <values文件>

如果此时能使用test@test.com和SuperSecret正常登录，说明问题确实出在持久化存储上。

2. 清理旧存储数据 #

如果是旧数据残留导致：

• 登录到PV绑定的节点（即NODE_NAME对应的集群节点）
• 删除PV挂载路径下的所有内容：

rm -rf /mnt/disks/ssd1/*

• 重启pgAdmin Pod，触发重新初始化：

kubectl delete pod <pgadmin-pod名称>

3. 修复存储路径权限 #

如果是权限问题：

• 登录到PV绑定的节点
• 修改挂载路径的权限，匹配pgAdmin容器的运行用户：

chown -R 5050:5050 /mnt/disks/ssd1

• 重启Pod，让容器重新读取环境变量生成用户配置。

4. 完善Helm配置 #

在你的values文件中显式添加密码配置，避免依赖Chart默认值：

env:
  email: test@test.com
  password: SuperSecret

重新执行Helm升级确保配置生效。

额外检查点 #

• 确认PV的nodeAffinity配置中的NODE_NAME是集群中实际存在的节点名称，避免Pod调度到错误节点导致存储挂载失败。
• 检查Pod的事件日志，确认存储是否正常挂载：

kubectl describe pod <pgadmin-pod名称>

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