在Kubernetes中使用ConfigMap或Secret配置PostgreSQL用户环境变量时遭遇角色不存在错误的问题

这是个很常见的场景问题，我帮你拆解下最可能的两个原因和对应的解决办法：

原因1：Secret中的值包含隐藏空白字符（最常见） #

很多时候我们创建Secret时，会不小心引入换行符或其他空白字符，导致注入到容器的环境变量值和预期不一致。比如：

• 如果你用echo "a" > username.txt然后从文件创建Secret，文件里的"a"后面会自动添加一个换行符，最终环境变量的实际值是a\n（带换行的字符串）
• 这种情况下，要么PostgreSQL初始化时创建了a\n这个特殊角色（首次启动场景），要么因为旧数据卷存在，初始化脚本没运行，现有角色是a，但你用带换行的变量去连接，自然会报错"role 'a' does not exist"

验证方法 #

1. 直接查看Secret解码后的值：

   kubectl get secret postgres -o jsonpath='{.data.username}' | base64 -d | cat -A
   

   输出显示a$是正常情况；如果是a\n$或a^M$（Windows换行符），说明存在隐藏字符。
2. 进入容器查看环境变量实际值：

   kubectl exec -it <你的PostgreSQL Pod名称> -- sh
   echo "$POSTGRES_USER" | cat -A
   

解决办法 #

创建Secret时避免引入换行符：

• 用--from-literal直接指定值：

  kubectl create secret generic postgres --from-literal=username=a
  

• 或者用echo -n写入文件（-n参数不会自动添加换行）：

  echo -n "a" > username.txt
  kubectl create secret generic postgres --from-file=username=username.txt
  

原因2：持久化存储卷保留了旧初始化数据 #

PostgreSQL官方镜像的初始化脚本只会在首次启动且数据目录为空时运行。如果你之前用直接设置env的方式启动过Pod，已经创建了持久化卷并写入了数据库数据，那么即使后来改用Secret注入环境变量，初始化脚本也不会重新执行——因为它检测到数据目录已有内容。

如果之前初始化用的是其他用户值，或者当前Secret的值和旧环境变量不一致，就会出现角色不匹配的情况。

解决办法 #

清理旧的持久化数据：

1. 删除对应的PersistentVolumeClaim（PVC）：

   kubectl delete pvc <你的PostgreSQL PVC名称>
   

2. 重新部署PostgreSQL Pod，此时会创建新的PVC和数据目录，初始化脚本会重新执行，根据当前Secret中的值创建正确的角色。

最终验证 #

修复完成后，你可以进入容器执行以下命令确认：

kubectl exec -it <你的PostgreSQL Pod名称> -- psql -U "$POSTGRES_USER" -c "SELECT rolname FROM pg_roles;"

如果能看到a角色，说明问题已经解决。

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