基于同镜像的K8S多Deployment共享环境变量方案咨询

Absolutely! You’ve got a few great options to reuse common environment variables across your Deployments while still keeping their unique settings intact. Let’s walk through each approach with concrete examples:

This is the go-to method since it uses Kubernetes built-in resources to separate common non-sensitive variables (ConfigMap) and sensitive secrets (Secret), then lets you load them into any Deployment.

First, define your shared variables in a ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: common-app-env
data:
  DB_HOST: "db-cluster.default.svc.cluster.local"
  EXTERNAL_SERVICE_BASE_URL: "https://api.external-service.com/v2"
  LOG_FORMAT: "json"

For sensitive values like passwords or API keys, use a Secret (remember to encode values in Base64):

apiVersion: v1
kind: Secret
metadata:
  name: common-app-secrets
type: Opaque
data:
  DB_PASSWORD: "YmFzZTY0LWRlbW8tcGFzc3dvcmQ=" # Base64-encoded "base64-demo-password"
  EXTERNAL_API_KEY: "ZXh0ZXJuYWwtYXBpLWtleQ==" # Base64-encoded "external-api-key"

Now, in each Deployment, load these shared variables and add your unique ones:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-api
  template:
    metadata:
      labels:
        app: web-api
    spec:
      containers:
      - name: web-api
        image: your-shared-app-image:latest
        # Load all common variables from ConfigMap
        envFrom:
        - configMapRef:
            name: common-app-env
        # Load all sensitive secrets
        - secretRef:
            name: common-app-secrets
        # Add unique variables for this Deployment
        env:
        - name: SERVICE_PORT
          value: "8080"
        - name: API_RATE_LIMIT
          value: "1000"

The best part? Update the ConfigMap/Secret once, and all Deployments using them will pick up the changes (you’ll need to restart pods for env vars to refresh, or use rolling updates).

If you’re using Helm to manage your Kubernetes manifests, you can create reusable templates for common environment variables.

First, define shared variables in your values.yaml:

# values.yaml
commonEnv:
  DB_HOST: "db-cluster.default.svc.cluster.local"
  EXTERNAL_SERVICE_BASE_URL: "https://api.external-service.com/v2"
commonSecrets:
  DB_PASSWORD: "your-production-db-password"
  EXTERNAL_API_KEY: "your-production-api-key"

Then, in your Deployment template, reference these shared values and add unique ones:

# templates/web-admin-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-web-admin
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web-admin
  template:
    metadata:
      labels:
        app: web-admin
    spec:
      containers:
      - name: web-admin
        image: your-shared-app-image:latest
        env:
        # Inject all common environment variables
        {{- range $key, $value := .Values.commonEnv }}
        - name: {{ $key }}
          value: {{ $value | quote }}
        {{- end }}
        # Inject common secrets (make sure you've created a Secret resource in your Helm chart too)
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: {{ .Release.Name }}-common-secrets
              key: DB_PASSWORD
        - name: EXTERNAL_API_KEY
          valueFrom:
            secretKeyRef:
              name: {{ .Release.Name }}-common-secrets
              key: EXTERNAL_API_KEY
        # Add unique variables for the admin service
        - name: ADMIN_PORT
          value: "8081"
        - name: ENABLE_ADMIN_DEBUG
          value: "false"

Helm makes it easy to override values per environment (e.g., staging vs production) while keeping your base template DRY.

Kustomize lets you define a "base" Deployment with common settings, then create overlays for each service to add unique variables.

First, create your base Deployment with shared env vars:

# base/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-base
spec:
  template:
    spec:
      containers:
      - name: app-container
        image: your-shared-app-image:latest
        env:
        - name: DB_HOST
          value: "db-cluster.default.svc.cluster.local"
        - name: EXTERNAL_SERVICE_BASE_URL
          value: "https://api.external-service.com/v2"

Then, create an overlay for your tasks worker Deployment to add unique vars:

# overlays/tasks-worker/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: tasks-worker
spec:
  replicas: 5
  template:
    metadata:
      labels:
        app: tasks-worker
    spec:
      containers:
      - name: tasks-worker
        env:
        - name: WORKER_CONCURRENCY
          value: "10"
        - name: TASK_QUEUE_NAME
          value: "data-processing-queue"

Finally, link everything in your kustomization.yaml:

# overlays/tasks-worker/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
bases:
- ../../base
resources:
- deployment.yaml

Kustomize merges the base and overlay configs, so you get all the common vars plus the unique ones for each service.

All these approaches eliminate duplicate env var definitions across your Deployments. For most teams, starting with ConfigMaps + Secrets is the simplest, most maintainable choice since it’s Kubernetes-native. If you’re managing a large number of services or multiple environments, Helm or Kustomize will give you the template flexibility you need.

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