PerfectScalePerfectScale

PerfectScale

CreateContainerConfigError vs. CreateContainerError in Kubernetes beheben

CreateContainerConfigError vs. CreateContainerError in Kubernetes: was die Fehler verursacht, wie Sie mit kubectl auf Fehlersuche gehen und wie Sie sie beheben.

Diese Seite ist auch in English, Español, Français, Italiano, 日本語 und Português verfügbar.

Tania Duggal
By Tania Duggal
May 26, 202410 min read

TLDR: Beide Fehler treten auf, bevor Ihr Container überhaupt startet – es gibt also keine Anwendungslogs, sondern nur Kubernetes-Events und Pod-Beschreibungen. CreateContainerConfigError bedeutet, dass Kubernetes die Konfiguration des Containers nicht zusammenstellen konnte (meist wegen einer fehlenden ConfigMap oder eines fehlenden Secrets). CreateContainerError bedeutet, dass die Konfiguration zwar in Ordnung war, die Container-Runtime (containerd, Docker) den Container aber nicht tatsächlich erstellen konnte (fehlerhaftes Image, Ressourcenengpässe, fehlerhafte Volume-Mounts oder ein Runtime-Problem). Die Lösung: Legen Sie die fehlende ConfigMap bzw. das fehlende Secret an, prüfen Sie Image und Entrypoint und gleichen Sie die angeforderten Ressourcen mit den verfügbaren ab.

Die Fehlermeldungen CreateContainerConfigError und CreateContainerError spielen eine zentrale Rolle für effektives Monitoring und Troubleshooting. Sie liefern wertvolle Hinweise auf Probleme in der Container-Konfiguration und tragen zu einem reibungslosen Container-Deployment bei. Schauen wir uns also an, was CreateContainerConfigError und CreateContainerError bedeuten, warum sie in Kubernetes auftreten und wie Sie sie beheben. Der wesentliche Unterschied zwischen beiden liegt im Zeitpunkt, zu dem sie im Deployment-Lebenszyklus eines Pods auftreten.

CreateContainerConfigError bedeutet, dass Kubernetes die erforderlichen Konfigurationsdaten – etwa fehlende Variablen oder Konfigurationsdateien – vor dem Start des Containers nicht zusammenstellen kann. CreateContainerError bedeutet, dass die Konfiguration bereitsteht, die zugrunde liegende Container-Runtime wie containerd oder Docker den Container auf dem Host-Node jedoch nicht physisch erstellen konnte. Da beide Fehler vor dem Containerstart auftreten, werden in keinem der beiden Fälle Anwendungslogs im Container erzeugt.

Hier finden Sie einige der wichtigsten Kubernetes-Fehler – mit kurzen Tipps zum Troubleshooting:

In diesem Artikel:

Was ist ein CreateContainerConfigError?

CreateContainerConfigError ist ein Fehler, der beim Erstellen des Containers auftritt, weil die Konfiguration fehlerhaft ist oder in der Container-Konfiguration des Pods etwas fehlt. Kubernetes kann dadurch die erforderliche Konfiguration für den Container nicht erzeugen.

CreateContainerConfigError als Flussdiagramm: Kubernetes prüft die Container-Konfiguration des Pods; ist sie korrekt, wird die Container-Konfiguration erzeugt und der Container erfolgreich erstellt; ist sie fehlerhaft, meldet Kubernetes einen CreateContainerConfigError.

CreateContainerConfigError als Flussdiagramm

Beim Start eines neuen Containers nutzt Kubernetes die Methode generateContainerConfig, um die Konfigurationsdaten des Containers bzw. die Pod-Metadaten einzulesen. Dazu gehören Startbefehle, Verweise auf ConfigMaps und Secrets sowie Definitionen von Speicherressourcen. Unter normalen Bedingungen findet Kubernetes die in der Konfiguration definierten Ressourcen und verbindet den Container mit ihnen. Kann Kubernetes diese Ressourcen nicht finden, löst es ein CreateContainerConfigError-Event aus.

Häufige Ursachen für CreateContainerConfigError in Kubernetes

CreateContainerConfigError tritt oft auf, wenn Kubernetes Ressourcen nicht findet, die für die Konfiguration eines Containers unerlässlich sind – typischerweise ConfigMaps oder Secrets.

Fehlende ConfigMaps

Eine ConfigMap ist ein API-Objekt zum Speichern von Konfigurationsdaten, auf die Container in Pods zugreifen können. Sie entkoppelt Konfigurationsdetails vom Container-Image und sorgt so für mehr Flexibilität und eine einfachere Verwaltung von Konfigurationseinstellungen.

Schauen wir uns an, wie Sie eine ConfigMap definieren und anschließend in einer Pod-Konfiguration referenzieren.

apiVersion: v1
kind: ConfigMap
metadata:
name: my-configmap
data:
config.json: |
{
"key": "value"
}

Pod-Konfiguration mit Verweis auf die ConfigMap:

apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: <image-name>
volumeMounts:
- name: config-volume
mountPath: /etc/config
volumes:
- name: config-volume
configMap:
name: my-configmap

Beim Erstellen eines Pods müssen Sie die ConfigMap in der Pod-Konfiguration referenzieren. Existiert die ConfigMap, kann der Pod darauf zugreifen. Falls nicht, erhalten Sie den CreateContainerConfigError.

Fehlende Secrets

Secrets sind in Kubernetes der Weg, sensible Informationen sicher zu speichern, die von Anwendungen im Cluster verwendet werden.

Betrachten wir nun ein Beispiel, in dem ein Pod so konfiguriert ist, dass er ein Secret zum Speichern sensibler Informationen verwendet.

apiVersion: v1
kind: Secret
metadata:
name: my-secret
type: Opaque
data:
password: cGFzc3dvcmQ= # Base64 encoded value of 'password'

Pod-Konfiguration mit Verweis auf das Secret:

apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: <image-name>
env:
- name: DATABASE_PASSWORD
valueFrom:
secretKeyRef:
name: my-secret
key: password

Denselben Fehler erhalten Sie, wenn Sie einen Container so konfigurieren, dass er Secrets verwendet, die nicht existieren.

Legen Sie ConfigMaps und Secrets also an, bevor Sie den Pod starten und sie in der Pod-Konfiguration referenzieren.

Troubleshooting bei CreateContainerConfigError

Um einen CreateContainerConfigError zu beheben, prüfen Sie zunächst die relevanten Logs und Events, um zu bestätigen, dass der Fehler auf eine fehlerhafte Konfiguration oder eine fehlende Ressource zurückgeht.

Mit diesen Schritten gehen Sie dem Fehler auf den Grund:

  1. Pod und Logs prüfen: Prüfen Sie mit dem Befehl kubectl logs die Logs des betroffenen Pods. Achten Sie auf Log-Meldungen, die auf einen CreateContainerConfigError hinweisen.
~ kubectl get pods
NAME READY STATUS RESTARTS AGE
my-pod 0/2 CreateContainerConfigError 1 (10s ago) 28s
  1. Kubectl-Events prüfen: Führen Sie den Befehl kubectl get events aus, um Events im Zusammenhang mit CreateContainerConfigError zu identifizieren. Achten Sie auf Events, die diesen Fehler explizit erwähnen.
~ kubectl get events
  1. Pods im Detail untersuchen: Untersuchen Sie mit dem Befehl kubectl describe pod pod-name die Konfiguration des Pods. Hier sehen Sie fehlende oder falsch konfigurierte Ressourcen.
~ kubectl describe pod my-pod
Warning Failed 56s (x6 over 1m45s)
kubelet Error: configmap "my-configmap" not found
  1. Berechtigungen und Namespace-Einstellungen verifizieren: Sind alle Ressourcen korrekt konfiguriert und der CreateContainerConfigError tritt trotzdem auf, prüfen Sie die Berechtigungen und Namespace-Einstellungen. Stellen Sie sicher, dass der Pod auf die Ressourcen zugreifen kann und sie sich im selben Namespace befinden.

CreateContainerConfigError beheben

Um einen CreateContainerConfigError zu beheben, folgen Sie diesen Best Practices:

  1. Fehlende ConfigMaps und Secrets anlegen: Fehlt eine referenzierte ConfigMap oder ein Secret, legen Sie die Ressource mit dem passenden kubectl-create-Befehl an. Achten Sie darauf, sie im selben Namespace wie den Pod zu erstellen.
~ kubectl create configmap my-configmap
kubectl create secret generic my-secret
  1. Berechtigungen korrekt konfigurieren: Verifizieren Sie, dass die Berechtigungen für die Ressourcen korrekt gesetzt sind und der Pod darauf zugreifen kann. Passen Sie die Berechtigungen bei Bedarf an.

  2. Ressourcenkonfiguration noch einmal prüfen: Überprüfen Sie die Pod-Konfiguration und stellen Sie sicher, dass alle Verweise auf ConfigMaps und Secrets korrekt und richtig geschrieben sind. Vermeiden Sie Tippfehler, durch die der Pod Ressourcen an der falschen Stelle sucht.

Was ist ein CreateContainerError?

CreateContainerError ist ein Fehler, der auftritt, wenn Kubernetes einen Container innerhalb eines Pods nicht erstellen kann. Er signalisiert einen Fehlschlag im Containerisierungsprozess – das Problem liegt also bei der Erstellung des Containers selbst.

Sequenzdiagramm zum Container-Erstellungsfehler in Kubernetes: Der Client fordert die Container-Erstellung bei der Kubernetes-API an, die die Container-Runtime mit der Initialisierung des Containers beauftragt; die Container-Runtime kann den Container nicht erstellen, und die Kubernetes-API gibt einen CreateContainerError an den Client zurück.

CreateContainerError

Häufige Ursachen für CreateContainerError in Kubernetes

Typischerweise sind folgende Probleme für CreateContainerError-Events verantwortlich:

  1. Image-Probleme: Eine der häufigsten Ursachen ist ein Problem mit dem Container-Image – etwa ein ungültiges oder nicht vorhandenes Image oder ein fehlender Standard-Entrypoint, ohne dass in der Anwendungskonfiguration manuell ein Entrypoint definiert wurde.

  2. Ressourcenengpässe: Unzureichende Ressourcen wie CPU oder Arbeitsspeicher können zu einem CreateContainerError führen. Übersteigen die angeforderten Ressourcen die verfügbare Kapazität, schlägt die Container-Erstellung fehl.

  3. Fehlerhafte Volume-Mounts: Sind die Volume-Mounts des Containers falsch konfiguriert oder verweisen sie auf nicht vorhandene Speicherressourcen, kann die Container-Erstellung fehlschlagen. Das passiert, wenn die angegebenen Storage-Volumes oder Persistent Volume Claims (PVCs) nicht existieren oder nicht erreichbar sind.

  4. Probleme mit der Container-Runtime: Container-Runtimes sind für das Verwalten und Ausführen von Containern in einem Kubernetes-Cluster zuständig. Ist die Container-Runtime fehlerhaft oder fehlen ihr die nötigen Ressourcen für den normalen Betrieb, kann das zu unerwartetem Verhalten und Fehlern wie CreateContainerError führen.

Troubleshooting bei CreateContainerError

Die Schritte zum Troubleshooting ähneln denen beim CreateContainerConfigError – werfen wir einen Blick darauf:

  1. Pod-Status und Logs prüfen: Mit dem Befehl kubectl get pods sehen Sie den Status der vorhandenen Pods. Ist Ihr Pod an einem CreateContainerError gescheitert, erscheint CreateContainerError im STATUS-Feld der Ausgabe.

  2. Pods im Detail untersuchen: Mit kubectl describe pod pod-name untersuchen Sie den Pod und erhalten detaillierte Informationen zu einem bestimmten Pod.

  3. Kubectl-Events prüfen: Führen Sie den Befehl kubectl get events aus, um Events im Zusammenhang mit CreateContainerError zu identifizieren. Achten Sie auf Events, die diesen Fehler explizit erwähnen.

  4. Pod-Manifeste prüfen: Prüfen Sie, ob die Pod-Konfiguration korrekt ist, stellen Sie sicher, dass der Pod auf das Volume zugreifen kann, wenn Sie es in der Konfiguration referenzieren, und verifizieren Sie zusätzlich, dass das Container-Image gültig ist und einen sauber definierten Entrypoint enthält.

CreateContainerError beheben

Wie Sie einen CreateContainerError beheben, hängt von der Ursache des Problems ab:

  1. Fehlender Entrypoint: Beheben Sie das Problem, indem Sie das richtige Image wählen oder den Entrypoint manuell in der Anwendungskonfiguration definieren.

  2. Storage-Probleme: Stellen Sie sicher, dass der Pod auf die konfigurierten Volumes zugreifen kann und die Pod-Konfiguration sie korrekt referenziert.

  3. Problem mit der Container-Runtime: Halten Sie die Container-Runtime aktuell und kompatibel mit den zugrunde liegenden Systemkomponenten. Weisen Sie der Container-Runtime außerdem ausreichend Ressourcen zu und überwachen Sie ihre Performance, um Runtime-bedingte Fehler zu vermeiden. Regelmäßige Wartung, Updates und Troubleshooting helfen dabei, Probleme mit der Container-Runtime zu lösen und einen reibungslosen Container-Betrieb in Kubernetes sicherzustellen.

Der Umgang mit CreateContainerConfigError und CreateContainerError in Kubernetes kann herausfordernd sein. Wer jedoch die Ursachen versteht und weiß, wie sich diese Probleme effektiv beheben lassen, verbessert sein Container-Management und seine Deployment-Prozesse deutlich. Mit den beschriebenen Schritten und Best Practices reduzieren Sie diese Fehler und sorgen für eine stabilere und effizientere Kubernetes-Umgebung.

Kubernetes-Fehler 10x schneller beheben mit PerfectScale by DoiT

Die Kubernetes-Governance-Plattform PerfectScale überwacht das Verhalten von Workloads kontinuierlich und erkennt Anzeichen von Instabilität – etwa OOM-Events oder CPU-Throttling –, die häufig zu Crash Loops führen.

Bis zu 30 verschiedene Resilienz-Risikotypen identifizieren

PerfectScale bietet bis zu 30 K8s-Alerts, die speziell auf Kubernetes zugeschnitten sind. Sie decken eine breite Palette potenzieller Probleme ab – etwa Pod-Ausfälle oder Ressourcenerschöpfung – und machen tiefes Kubernetes-Expertenwissen überflüssig.

Bis zu 30 verschiedene Resilienz-Risikotypen mit PerfectScale identifizieren

Echtzeit-Alerts ohne Alert Fatigue

Mit PerfectScale richten Sie Alerts für Ihre Cluster im Handumdrehen ein und verwalten sie effizient über Alert Profiles. So überwachen Sie genau die Alerts, die für Ihr Setup relevant sind, und werden entsprechend benachrichtigt.

Für schnellere Updates nutzen Sie die Integrationsprofile für Slack oder MS Teams, um benachrichtigt zu werden, sobald ein Alert ausgelöst wird.

Umsetzbare Empfehlungen zur Beseitigung von Kubernetes-CreateContainerConfigErrors

Auf Basis realer Nutzungsdaten und resilienzorientierter Richtlinien liefert PerfectScale präzise Empfehlungen für das Right-Sizing von Workloads auf Container-Ebene – damit Ihre Workloads genau das bekommen, was sie brauchen. Ob manuell oder autonom angewendet: Diese Empfehlungen stellen die Stabilität der Workloads wieder her, beenden wiederkehrende Neustarts und beugen ähnlichen Ausfällen in Zukunft vor.

Um die Empfehlungen umzusetzen, kopieren Sie einfach die .yaml und deployen sie in Ihrem Cluster.

Umsetzbare Empfehlungen zur Beseitigung von Kubernetes-CreateContainerConfigErrors erhalten

Schließen Sie sich Branchenführern wie Paramount Pictures und Creditas an, die ihre Kubernetes-Umgebungen bereits mit PerfectScale optimiert haben. Registrieren Sie sich oder buchen Sie jetzt eine Demo mit unseren technischen Experten!

FAQ

Was ist der Unterschied zwischen CreateContainerConfigError und CreateContainerError? CreateContainerConfigError tritt früher auf: Kubernetes kann die Konfiguration des Containers nicht zusammenstellen, meist weil eine referenzierte ConfigMap oder ein Secret fehlt. CreateContainerError tritt auf, nachdem die Konfiguration bereitsteht – wenn die Container-Runtime selbst den Container nicht erstellen kann (fehlerhaftes Image, Ressourcenlimits, fehlerhafte Volume-Mounts oder ein Runtime-Problem).

Warum gibt es bei diesen Fehlern keine Anwendungslogs? Beide Fehler treten auf, bevor der Container tatsächlich startet. Die Anwendung darin läuft also nie und erzeugt keine Logs. Stattdessen müssen Sie auf kubectl describe pod und kubectl get events zurückgreifen.

Wie behebe ich einen CreateContainerConfigError, der durch eine fehlende ConfigMap oder ein fehlendes Secret verursacht wird? Legen Sie die fehlende Ressource im selben Namespace wie den Pod an, zum Beispiel mit kubectl create configmap my-configmap oder kubectl create secret generic my-secret, und prüfen Sie anschließend, ob die Pod-Spezifikation den korrekten Namen und Namespace referenziert.

Was verursacht typischerweise einen CreateContainerError? Meist ein ungültiges oder fehlendes Container-Image, ein nicht definierter Entrypoint, unzureichende CPU- bzw. Arbeitsspeicherkapazität für die Ressourcenanforderungen des Pods, falsch konfigurierte Volume-Mounts oder ein Problem mit der Container-Runtime selbst (containerd, Docker).

Welchen Befehl führe ich als Erstes aus, wenn einer der beiden Fehler auftritt? kubectl get pods, um den Fehler in der STATUS-Spalte zu bestätigen, dann kubectl describe pod <pod-name>, um die konkrete Event-Meldung zu sehen (z. B. "configmap not found"), und anschließend kubectl get events für zusätzlichen Kontext.

Kann PerfectScale helfen, diese Fehler zu vermeiden? Ja. PerfectScale überwacht das Verhalten von Workloads auf Anzeichen von Instabilität (wie OOM-Events oder CPU-Throttling) und liefert Right-Sizing-Empfehlungen auf Container-Ebene – mit dem Ziel, ressourcenbedingte Konfigurations- und Runtime-Fehler zu erkennen und zu verhindern, bevor sie erneut auftreten.