Introduction

In Kubernetes, you usually update a ConfigMap or Secret in place rather than deleting and recreating it. In-place updates preserve object identity and reduce operational risk during rollout. The important detail is that pods do not always consume new values immediately, so update strategy and restart behavior must be planned together.

In-Place Update With kubectl apply

The most common workflow is editing a manifest and applying it.

1apiVersion: v1
2kind: ConfigMap
3metadata:
4  name: app-config
5  namespace: production
6data:
7  LOG_LEVEL: "info"
8  FEATURE_X_ENABLED: "true"

kubectl apply -f app-config.yaml

For Secrets, use stringData in manifests to avoid manual base64 encoding mistakes.

1apiVersion: v1
2kind: Secret
3metadata:
4  name: app-secret
5  namespace: production
6type: Opaque
7stringData:
8  DB_PASSWORD: "new-password"

kubectl apply -f app-secret.yaml

Kubernetes stores Secret data as base64 in the object, but stringData keeps authoring safer.

Partial Update With kubectl patch

If you need to change one key quickly, patch can be cleaner than full manifest replacement.

1kubectl patch configmap app-config \
2  -n production \
3  --type merge \
4  -p '{"data":{"LOG_LEVEL":"debug"}}'

Secret patch example:

1kubectl patch secret app-secret \
2  -n production \
3  --type merge \
4  -p '{"stringData":{"DB_PASSWORD":"rotated-password"}}'

Use patch carefully in automation. For long-term maintainability, source-controlled manifests are usually preferred.

Make Running Pods Pick Up Changes

How updates propagate depends on how the pod consumes config.

• Environment variables are fixed at pod start and require restart.
• Volume-mounted ConfigMap or Secret files can refresh, but app process may still need reload logic.

A common operational pattern is rollout restart.

kubectl rollout restart deployment/my-api -n production
kubectl rollout status deployment/my-api -n production

This ensures new pod instances read updated values at startup.

Versioned Config Strategy

For high-safety deployments, use versioned config names and update deployment references.

Example approach:

• app-config-v12
• Update deployment to reference app-config-v12.
• Roll out.
• Remove old config later.

This gives easy rollback by switching reference back to previous version.

Immutable ConfigMaps and Secrets

Kubernetes supports immutable objects for stronger safety.

1apiVersion: v1
2kind: ConfigMap
3metadata:
4  name: app-config
5immutable: true
6data:
7  LOG_LEVEL: "info"

Immutable objects cannot be updated in place. You must create a new object and update consumers. This is useful when accidental edits are more dangerous than update overhead.

Verify the Update

Always verify both resource and workload behavior.

kubectl get configmap app-config -n production -o yaml
kubectl get secret app-secret -n production -o yaml
kubectl get pods -n production -l app=my-api

Application-level verification is still required. Resource update alone does not prove runtime behavior changed as expected.

Security and Audit Notes for Secrets

When handling secrets:

• Avoid printing secret values in logs or terminal history.
• Prefer external secret managers where required by policy.
• Restrict RBAC permissions for secret read and write.

For compliance-sensitive environments, ensure secret rotation procedures and access logs are documented and tested.

Run periodic drill updates in non-production clusters to verify rollout and rollback mechanics still work after platform upgrades.

Common Pitfalls

A common pitfall is updating a ConfigMap and expecting environment variables in running pods to change automatically. Another issue is patching objects manually in production while manifests in Git remain outdated, causing later drift and rollback confusion. Teams also often base64-encode secret strings incorrectly when not using stringData. Failing to restart or reload application processes after updates is another frequent source of false success. Finally, secret updates without strict RBAC and audit discipline can create security incidents even when technical rollout succeeds.

Summary

• Use kubectl apply or kubectl patch to update ConfigMaps and Secrets in place.
• Prefer stringData for safer Secret authoring.
• Plan workload refresh behavior based on env-var or volume usage.
• Use rollout restart or versioned config references for controlled rollout.
• Verify both Kubernetes object state and application behavior after each update.