CreateContainerConfigError: Secret, ConfigMap, fehlender Key

TL;DR

CreateContainerConfigError heißt: das Kubelet kann die Container-Konfiguration nicht bauen. Der Prozess startet nicht. kubectl logs bleibt leer. Die fehlende Stelle steht im Event:

kubectl describe pod POD

Drei Texte decken den Alltag ab. secret "NAME" not found und configmap "NAME" not found: das Objekt fehlt oder liegt im falschen Namespace. couldn't find key KEY in Secret NAME: das Objekt ist da, der Key nicht. Die Übersicht der anderen Status steht unter Pod startet nicht.

Bevor der Prozess existiert

Das Kubelet setzt Env-Variablen, envFrom und projizierte Volumes, bevor es den Entrypoint aufruft. Fehlt dabei eine Referenz, bleibt der Container in Waiting mit Reason CreateContainerConfigError. Restart Count kann trotzdem steigen, weil das Kubelet den Versuch wiederholt. Es gibt keinen Previous-Log, denn es gab keinen Prozess.

Ein Volume-Mount auf ein fehlendes Secret sieht oft anders aus: FailedMount während ContainerCreating. Env und env.valueFrom landen bei CreateContainerConfigError. Dieselbe Ursache, zwei Reasons. describe entscheidet, welche Zeile Sie anfassen.

Objekt fehlt, oder es liegt woanders

Namen sind namespace-lokal. Ein Secret in default gilt nicht in prod.

kubectl get secret NAME -n NAMESPACE
kubectl get configmap NAME -n NAMESPACE
kubectl get pod POD -n NAMESPACE -o jsonpath='{.spec.containers[*].envFrom}{"\n"}{.spec.containers[*].env}{"\n"}'

Typisch nach einem Kopieren des Manifests: Namespace geändert, Secret nicht mitgezogen. Oder das Secret entsteht in einem späteren Schritt der Pipeline, und der Pod startet vorher. Dann ist die Reihenfolge der Fehler, nicht der Key.

optional: true an der Env-Quelle macht den fehlenden Namen zum leeren Wert statt zum harten Fehler. Das ist richtig für optionale Konfiguration. Für ein Passwort, ohne das die Anwendung nicht läuft, verschiebt es den Ausfall nur auf Exit Code 1.

Key fehlt im vorhandenen Objekt

couldn't find key DB_PASSWORD in Secret app-env heißt: app-env existiert, DB_PASSWORD ist kein Data-Key. Keys sind die Dateinamen unter data:, nicht die Werte.

kubectl get secret app-env -o jsonpath='{.data}' | python3 -m json.tool

Sie sehen die Key-Namen, nicht die decodierten Werte, wenn Sie nur die Keys brauchen: kubectl get secret app-env -o go-template='{{range $k,$v := .data}}{{$k}}{{"\n"}}{{end}}'. Ein Tippfehler DB_PASSWROD ist still, bis der Pod ihn sucht.

Bei envFrom.secretRef zieht Kubernetes alle Keys. Fehlt das ganze Secret, kommt CreateContainerConfigError. Ein einzelner falscher Key in valueFrom.secretKeyRef nennt genau diesen Key.

Nach dem Anlegen

Das Kubelet merkt ein neues Secret von selbst und startet den Versuch erneut. Ein kubectl delete pod ist nicht nötig, schadet aber nicht, wenn Sie sehen wollen, ob der nächste Pod denselben Fehler zeigt. Zeigt er ihn, referenziert das Pod-Spec noch den alten Namen. Dann ist das Deployment nicht das, was Sie gerade angelegt haben.

Ein Image, das sich nicht ziehen lässt, ist dieser Fehler nicht. Dafür gibt es ImagePullBackOff.

Quellen

• Secrets an Pods übergeben
• ConfigMaps als Env