Kubernetes微服务场景下创建PostgreSQL数据库用户的优选方式咨询

针对你提到的场景——微服务对应独立Schema/逻辑库，由Kubernetes负责创建数据库、Schema和用户，同时避免应用持有超级管理员权限，这里有几个经过实践验证的优选方案，按推荐度排序：

1. 采用PostgreSQL Operator（最推荐） #

如果你的团队还没绑定特定的Helm Chart，强烈考虑使用PostgreSQL Operator，比如Crunchy Data或Zalando的开源实现。这类Operator原生支持多租户/多用户管理，完全契合你的需求：

• 通过自定义资源（CRD）定义PostgresCluster时，可以直接配置多个databases、users和对应的权限映射，每个用户自动关联到指定的数据库/Schema，密码会自动存在Kubernetes Secret中。
• Operator会自动处理用户创建、权限授予、密码轮转等运维操作，不需要手动写SQL脚本。
• 以Zalando的Operator为例，你可以在PostgresCluster资源里添加类似这样的配置：

  spec:
    users:
    - name: service-a-user
      databases: [service-a-db]
      schemas: [service-a-schema]
      privileges:
        service-a-db: ALL
        service-a-schema: ALL
    - name: service-b-user
      databases: [service-b-db]
      schemas: [service-b-schema]
  

• 优点：自动化程度高，运维友好，原生支持多用户权限隔离；缺点：需要学习Operator的使用方式，引入新的组件到集群中。

2. 扩展现有Helm Chart的初始化逻辑 #

如果已经在使用Stolon这类Helm Chart，最直接的方式是扩展它的初始化脚本：

• 找到Chart中负责初始化数据库的部分（通常是init容器或initdb脚本），修改成支持从ConfigMap/Secret读取多用户、多数据库的配置列表。
• 比如，你可以创建一个ConfigMap，存储每个微服务的配置项：

  apiVersion: v1
  kind: ConfigMap
  metadata:
    name: postgres-init-config
  data:
    users.yaml: |
      - username: service-a
        dbname: service-a-db
        schema: service-a-schema
      - username: service-b
        dbname: service-b-db
        schema: service-b-schema
  

• 然后在初始化脚本中循环读取这个配置，执行对应的SQL命令：

  for entry in $(yq e '.[]' /config/users.yaml); do
    USER=$(echo $entry | yq e '.username' -)
    DB=$(echo $entry | yq e '.dbname' -)
    SCHEMA=$(echo $entry | yq e '.schema' -)
    
    psql -v ON_ERROR_STOP=1 --username "$POSTGRES_USER" <<-EOSQL
      CREATE DATABASE $DB;
      CREATE USER $USER WITH PASSWORD '$(cat /secrets/$USER-password)';
      GRANT ALL PRIVILEGES ON DATABASE $DB TO $USER;
      \c $DB;
      CREATE SCHEMA $SCHEMA;
      GRANT ALL ON SCHEMA $SCHEMA TO $USER;
    EOSQL
  done
  

• 把用户密码存在独立的Secret中，脚本读取后执行。
• 优点：贴合现有部署，不需要引入新组件；缺点：需要维护自定义的Chart分支，上游Chart更新时需要同步修改。

3. 使用Kubernetes Job执行批量初始化 #

如果不想修改Helm Chart，可以用Kubernetes Job来完成多用户/数据库的创建：

• 部署好PostgreSQL后，创建一个Job，挂载包含初始化SQL的ConfigMap，以及存储用户密码的Secret。
• Job的容器可以使用官方的postgres镜像，连接到PostgreSQL服务执行脚本：

  apiVersion: batch/v1
  kind: Job
  metadata:
    name: postgres-init-job
  spec:
    template:
      spec:
        containers:
        - name: init-db
          image: postgres:15
          command: ["psql", "-h", "postgres-service", "-U", "$(POSTGRES_ADMIN_USER)", "-f", "/scripts/init.sql"]
          env:
          - name: POSTGRES_ADMIN_USER
            valueFrom:
              secretKeyRef:
                name: postgres-admin-secret
                key: username
          - name: PGPASSWORD
            valueFrom:
              secretKeyRef:
                name: postgres-admin-secret
                key: password
          volumeMounts:
          - name: init-scripts
            mountPath: /scripts
          - name: user-secrets
            mountPath: /secrets
        volumes:
        - name: init-scripts
          configMap:
            name: postgres-init-scripts
        - name: user-secrets
          secret:
            secretName: postgres-service-users
        restartPolicy: OnFailure
  

• 初始化SQL脚本里包含所有用户、数据库、Schema的创建和授权语句，密码可以从Secret中读取或者直接在脚本中引用环境变量。
• 优点：简单灵活，不需要修改现有Chart；缺点：需要手动管理Job，新增微服务时要更新脚本并重新执行Job，缺乏动态管理能力。

4. 应用侧使用最小权限的初始化账号（备选） #

如果以上方案都不适合，可以创建一个仅具备初始化权限的专用账号，而不是超级管理员：

• 先创建一个拥有CREATE USER、CREATE DATABASE、CREATE SCHEMA权限的账号，权限严格限制，只能执行必要的初始化操作。
• 应用启动时，先使用这个初始化账号检查对应的用户、数据库、Schema是否存在，不存在则创建，然后切换到业务账号进行正常操作。
• 注意要确保初始化账号的权限最小化，比如只允许在指定的数据库范围内操作，避免泄露过高权限。
• 优点：不需要额外K8s组件，应用自主管理；缺点：增加了应用的复杂度，需要在代码中处理初始化逻辑，权限配置需要格外小心。

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