Around Go: Kubernetes · 3 MIN READ

Configuration: ConfigMaps, Secrets and update behavior

Create a non-secret setting, mount a Secret reference and understand why environment changes need replacement.

Separate application configuration from the image artifact. ConfigMaps hold ordinary configuration; Secrets are intended for sensitive values but are not made confidential merely by base64 encoding. These development examples assume a namespace you own and the permissions to manage its configuration.

Generate and apply a non-secret ConfigMap

create with --dry-run=client -o yaml generates an object locally. Piping that object to apply creates or updates the named configuration on the explicit cluster. LOG_LEVEL is an ordinary non-secret value here, so showing its key is appropriate.

bash

kubectl --context dev-cluster -n go-lab create configmap go-api-config \
  --from-literal=LOG_LEVEL=info --dry-run=client -o yaml | \
  kubectl --context dev-cluster -n go-lab apply -f -
kubectl --context dev-cluster -n go-lab describe configmap go-api-config

Read the code

In a Bash script, enable pipefail and handle the pipeline status. The first command only generates YAML; the second performs the API mutation. Do not use a ConfigMap for a database password or access token.

Reference existing config and secret keys from the Pod

This is a fragment to merge into the api container in deployment.yaml, not a standalone manifest. It assumes an existing go-api-credentials Secret with a password key, supplied through your cluster secret-management process.

yaml

env:
  - name: LOG_LEVEL
    valueFrom:
      configMapKeyRef:
        name: go-api-config
        key: LOG_LEVEL
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: go-api-credentials
        key: password

Read the code

The application reads these values when its process starts. Restrict Secret access and configure storage protection at the cluster level. Never commit live Secret YAML or paste decoded credentials into a lesson exercise.

Replace Pods when environment configuration changes

Changing the ConfigMap does not rewrite environment variables in a running process. A controlled rollout restart replaces Pods so they read the updated values. ConfigMap volume updates have different propagation and application-reload behavior, and subPath mounts do not receive normal automatic updates.

bash

kubectl --context dev-cluster -n go-lab rollout restart deployment/go-api
kubectl --context dev-cluster -n go-lab rollout status deployment/go-api --timeout=120s
kubectl --context dev-cluster -n go-lab get pods -l app=go-api

Read the code

Only restart after the reviewed configuration and Pod template are ready. Observe readiness and service behavior afterwards without logging the password. This restart changes running workloads; it is not a read-only configuration check.

TAKE THIS WITH YOU

Use ConfigMaps for ordinary values and controlled Secret references for credentials. Environment is captured at process startup; replacing Pods and reloading mounted files are distinct update strategies.

Check your understanding

When does a process receive a ConfigMap-backed environment variable?

Go to the source

Progress stays in this browser. No account needed.