CreateContainerConfigError and OOMKilled — the misconfiguration and memory failures

CreateContainerConfigError is the kubelet failing to read a ConfigMap or Secret. OOMKilled is the kernel killing the container for exceeding memory limits. The events and the previous logs are the diagnostic. The discipline is the same 11-step methodology: read the events, identify the cause, apply the remediation.

CreateContainerConfigError

A CreateContainerConfigError is the kubelet’s response to a container whose configuration cannot be created — typically because a ConfigMap, Secret, or volume reference is missing.

A real kubectl describe pod for a CreateContainerConfigError:

Containers:
  billing:
    Image:      registry.example.com/billing:1.2.3
    State:      Waiting
      Reason:   CreateContainerConfigError
    Ready:      False
Events:
  Type     Reason          Age   From               Message
  ----     ------          ----  ----               -------
  Warning  Failed          4m    kubelet            Error: cannot find volume 'config' to mount into container "billing"
  Warning  Failed          4m    kubelet            Error: configmap "billing-config" not found

The events tell the operator:

• The kubelet cannot find the volume config.
• The ConfigMap billing-config does not exist.

The remediation is to create the ConfigMap (or fix the volume name).

Common causes of CreateContainerConfigError

The most common causes:

• Missing ConfigMap. The Pod’s envFrom references a ConfigMap that does not exist.
• Missing Secret. The Pod’s envFrom references a Secret that does not exist.
• Wrong volume name. The Pod’s volumes reference a ConfigMap or Secret by name, but the name is wrong.
• Wrong key. The Pod’s env.valueFrom.secretKeyRef or configMapKeyRef references a key that does not exist in the ConfigMap or Secret.

flowchart TD
    A[CreateContainerConfigError] --> B{ConfigMap or Secret?}
    B -->|Missing| C[Create the resource]
    B -->|Wrong name| D[Fix the volume name]
    B -->|Wrong key| E[Fix the key reference]

The diagnostic is the events. The events name the missing resource.

OOMKilled

An OOMKilled is the kernel’s response to a container that has exceeded its memory limit. The cgroup’s memory limit is hit; the kernel kills the container with SIGKILL; the kubelet records the exit reason.

A real kubectl describe pod for an OOMKilled:

Containers:
  billing:
    Image:      registry.example.com/billing:1.2.3
    State:      Waiting
      Reason:   CrashLoopBackOff
    Last State: Terminated
      Reason:   OOMKilled
      Exit Code:  137
      Started:    Fri, 16 Aug 2026 04:23:01 +0000
      Finished:   Fri, 16 Aug 2026 04:23:45 +0000
    Ready:      False
    Limits:
      cpu:     500m
      memory:  512Mi
    Requests:
      cpu:     250m
      memory:  256Mi

The events tell the operator:

• The container was terminated with OOMKilled.
• The exit code is 137 (128 + 9, SIGKILL).
• The container is now in CrashLoopBackOff because the kubelet is restarting it; the OOMKilled will recur.

The remediation is to either:

• Increase the memory limit. The workload genuinely needs more memory.
• Fix the application’s memory leak. The workload is consuming memory it should release.
• Investigate the workload’s profile. The workload is hitting a peak that the limit is not accommodating.

The exit code 137

The exit code 137 is the canonical signal of OOMKilled. The breakdown:

• 128 + signal number. The kernel sent SIGKILL (signal 9).
• 137 = 128 + 9. The container was killed by SIGKILL, not by the application.

A container that exited with code 1 (or any other non-zero code) is the application failing. A container that exited with code 137 is the kernel killing it.

How to investigate OOMKilled

The diagnostic is the previous logs. The previous logs show the application’s view of the OOM. The application may have been logging a memory pressure warning before the kill.

kubectl logs -n prod billing-7d8f-abcde -c billing --previous

The output may show:

[2026-08-16 04:23:42] WARNING: memory usage at 480Mi / 512Mi
[2026-08-16 04:23:43] WARNING: memory usage at 502Mi / 512Mi
[2026-08-16 04:23:44] WARNING: memory usage at 510Mi / 512Mi
[2026-08-16 04:23:45] CRITICAL: OOMKilled by kernel

The application’s memory observability is the diagnostic. The operator who sees the warning can correlate it with the kubelet’s OOMKilled event.

Production discipline

An OOMKilled is a workload that does not fit its limit. The discipline is to read the previous logs, identify the cause, and apply the remediation. A cluster that has frequent OOMKilleds is a cluster that has misconfigured limits or buggy workloads.

• Read the events. The events name the missing ConfigMap, Secret, volume, or key.
• Create the resource. The remediation for a CreateContainerConfigError is to create the missing ConfigMap or Secret, not to redeploy.
• Fix the reference. If the resource exists in a different namespace, fix the reference — a Pod can only mount objects from its own namespace.
• Exit code 137 is the canonical signal. 128 + 9 means the kernel sent SIGKILL; the application did not choose to exit.

Quiz