创建依赖PostgreSQL的Helm Chart：获取运行时数据库配置问题

Got it, let's work through this Helm Chart dependency and runtime data challenge step by step. I’ve dealt with similar setups before, so here’s how you can make this work reliably.

The core issue here is that PostgreSQL's runtime details (like auto-generated passwords, service hostname) don’t exist until after it’s deployed—so we can’t hardcode them in templates. Instead, we’ll use Helm’s dependency system and Kubernetes native resources (Secrets, Services) to pass these values to your second service dynamically.

1. Set Up PostgreSQL as a Helm Dependency #

I highly recommend using the official Bitnami PostgreSQL Helm Chart as a dependency—it’s well-maintained, handles secret management automatically, and exposes all the runtime data we need via standard Kubernetes resources.

Step 1: Add the Dependency to Your Chart #

In your main Chart’s Chart.yaml, add the PostgreSQL dependency:

dependencies:
  - name: postgresql
    version: "15.5.0" # Use the latest stable version for your needs
    repository: "https://charts.bitnami.com/bitnami"
    alias: postgres # Optional, makes referencing easier later

Run helm dependency update to pull the chart into your charts/ directory.

Step 2: Configure PostgreSQL in values.yaml #

Define your desired database credentials and service settings (you can let Helm auto-generate passwords for security):

postgres:
  auth:
    database: my_app_db
    username: my_app_user
    # Leave password commented to let Helm auto-generate a secure one
    # password: my_weak_password_123
  primary:
    service:
      port: 5432 # Default PostgreSQL port, adjust if needed

2. Reference PostgreSQL Runtime Data in Your Second Service #

The Bitnami PostgreSQL Chart automatically creates two key resources we’ll use:

• A Secret storing the database username and password
• A Service exposing the PostgreSQL instance’s hostname and port

Reference Username & Password (From Secret) #

The Secret name follows the pattern <release-name>-postgres, with keys username (your custom user) and password (the auto-generated or defined password). In your second service’s Deployment template:

env:
  - name: DB_USERNAME
    valueFrom:
      secretKeyRef:
        name: {{ .Release.Name }}-postgres
        key: username
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: {{ .Release.Name }}-postgres
        key: password

Reference Hostname & Port (From Service) #

Inside the Kubernetes cluster, the PostgreSQL Service name acts as a resolvable DNS hostname. The port is what you defined in values.yaml:

env:
  - name: DB_HOST
    value: {{ .Release.Name }}-postgres
  - name: DB_PORT
    value: "{{ .Values.postgres.primary.service.port }}"

If You’re Using a Custom PostgreSQL Subchart

If you’re building your own PostgreSQL subchart instead of using Bitnami’s, add helper templates in your subchart’s templates/_helpers.tpl to standardize resource names:

{{/* Define the name of the PostgreSQL secret */}}
{{- define "postgres.secretName" -}}
{{- printf "%s-%s" .Release.Name "postgres" | trunc 63 | trimSuffix "-" -}}
{{- end -}}

{{/* Define the name of the PostgreSQL service */}}
{{- define "postgres.serviceName" -}}
{{- printf "%s-%s" .Release.Name "postgres" | trunc 63 | trimSuffix "-" -}}
{{- end -}}

Then reference these helpers in your main service’s template:

env:
  - name: DB_HOST
    value: {{ include "postgres.serviceName" . }}
  - name: DB_USERNAME
    valueFrom:
      secretKeyRef:
        name: {{ include "postgres.secretName" . }}
        key: username

3. Ensure Your Service Waits for PostgreSQL #

To avoid your second service starting before PostgreSQL is ready, add a startup probe to its Deployment. This will keep retrying until PostgreSQL accepts connections:

containers:
  - name: my-second-service
    image: your-service-image:latest
    startupProbe:
      exec:
        command: ["psql", "-h", "$(DB_HOST)", "-U", "$(DB_USERNAME)", "-d", "$(DB_PASSWORD)", "-c", "SELECT 1;"]
      initialDelaySeconds: 10
      periodSeconds: 5
      failureThreshold: 12 # Wait up to 60 seconds before failing

Common Troubleshooting Tips #

• Missing Secret/Service: Double-check that helm dependency update ran successfully, and that your release name (used in {{ .Release.Name }}) matches what you’re deploying with.
• Password Mismatch: Bitnami’s chart uses password for custom users and postgres-password for the superuser—don’t mix them up.
• DNS Resolution Issues: If your services are in different namespaces, use the full hostname: <service-name>.<namespace>.svc.cluster.local.

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