Kubernetes CreateContainerConfigError: a missing Secret or ConfigMap, and how to find it

1. Read the events

kubectl describe pod myapp-7d9f8b6c4-x2k9p

At the bottom, under Events:

Warning  Failed  12s (x4 over 45s)  kubelet  Error: secret "db-credentials" not found

2. A missing Secret or ConfigMap

See what the pod asks for:

kubectl get pod myapp-7d9f8b6c4-x2k9p -o jsonpath='{.spec.containers[*].envFrom}'
kubectl get pod myapp-7d9f8b6c4-x2k9p -o yaml | grep -A4 -E 'secretKeyRef|configMapKeyRef|secretRef|configMapRef'

And compare it with what exists:

kubectl get secrets,configmaps

Then create it, or fix the name in the Deployment. The value goes on the command line here only as an example, and from a file is better:

kubectl create secret generic db-credentials \
  --from-literal=username=app \
  --from-file=password=./password.txt

Is it in another namespace? Secrets and ConfigMaps can only be used from their own namespace. That’s a common reason for this error when moving between environments:

kubectl get secrets -A | grep db-credentials
kubectl config view --minify --output 'jsonpath={..namespace}'

Copy it across, or better, create it from your source of truth.

Is it created by something else? A chart or an operator like External Secrets may be slow or failing. Look at that one’s status. With Helm, a Secret from another release may be installed later, or under a different name:

kubectl get externalsecret
helm list

3. A wrong key

The Secret is there, and it has other keys:

Error: couldn't find key password in Secret default/db-credentials

List the keys, without showing the values:

kubectl get secret db-credentials -o jsonpath='{.data}' | python3 -c 'import json,sys; print(list(json.load(sys.stdin)))'
kubectl describe secret db-credentials

The usual reason is a tiny difference such as DB_PASSWORD vs db-password. Keys are case-sensitive. Fix one to match:

env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: db-credentials
        key: password

The Kubernetes Manifest Generator writes the Secret, the ConfigMap and the references so that they match.

4. If it’s truly optional

For a setting your application can do without, say so, and the pod starts without it:

env:
  - name: FEATURE_FLAG
    valueFrom:
      configMapKeyRef:
        name: features
        key: flag
        optional: true
envFrom:
  - secretRef:
      name: extra-settings
      optional: true

Don’t use it for what’s really required, like a database password. Then the application starts, and fails later in a way that’s harder to diagnose.

5. After you fix it

The kubelet retries, so the pod usually starts on its own, within a minute or so. Want it faster?

kubectl delete pod myapp-7d9f8b6c4-x2k9p
kubectl rollout restart deployment/myapp
kubectl rollout status deployment/myapp

If you changed the Deployment itself, a new ReplicaSet rolls out without any of that. And remember that a running pod doesn’t pick up a changed environment variable until it restarts.

If there’s now a different failure, the application itself is running: read kubectl logs, and see CrashLoopBackOff.

6. Keep it from happening

Create what’s referenced before the Deployment, and apply both together. With one file, the order is yours to control:

kubectl apply -f secret.yaml -f deployment.yaml

Test against the cluster first, as a dry run on the server side checks a lot, even though it doesn’t check for references:

kubectl apply --dry-run=server -f deployment.yaml

Don’t commit real Secrets in plain YAML, since Base64 isn’t encryption. Use your secret manager with External Secrets, or Sealed Secrets. And in a pipeline, set the value from your CI’s secret store.