01
Read the termination record for the correct container
Inspect the current and previous container states, not only the Pod’s top-level phase. With multiple containers, identify the one that failed. Record its termination reason, exit code, time, and restart count alongside the workload. Use --previous only if a previous instance exists; read ordinary logs for a terminated container that has not restarted.
Exit 137 is consistent with a process killed by SIGKILL, but that code alone cannot identify the actor. In our test the termination reason was explicitly OOMKilled. That additional evidence connected the failure to the controlled allocation and limit.
# Substitute your namespace, Pod, and container names.
kubectl -n your-namespace get pod your-pod -o yaml
kubectl -n your-namespace describe pod your-pod
kubectl -n your-namespace logs your-pod -c app --previous02
Compare requests, limits, and actual work
A memory request contributes to placement; a memory limit constrains the container at runtime. Inspect the effective Pod, including any defaults or admission changes, rather than assuming the source manifest is the final configuration.
The experiment used a small request and a 32 MiB limit, then attempted a 128 MiB bytearray. The process could start but could not complete that allocation under the limit. Scheduling successfully did not establish sufficient runtime memory.
# A container resources fragment, not a complete workload manifest:
resources:
requests:
memory: 16Mi
limits:
memory: 32Mi03
Reproduce the operation with controlled headroom
In an isolated namespace, run the same operation with an appropriate test limit. Keep the command, input, and image constant so the memory allowance is the variable being tested. Use resource values suitable for the test cluster.
Our second Pod kept the same 128 MiB allocation but used a 256 MiB limit. It printed its completion marker and exited zero. This demonstrated that the original allowance was insufficient for that operation, without claiming that the application’s memory growth was acceptable.
# Corrected lab resources fragment:
resources:
requests:
memory: 16Mi
limits:
memory: 256Mi04
Apply a measured change to the workload owner
For a Deployment or another controller, update its intended container resources in the source of truth. Do not rely on editing an individual managed Pod. Review the rollout and available node capacity before increasing resource commitments.
Observe more than a quiet restart count: repeat the relevant load and inspect memory behavior over time. If the workload grows without a stable bound, investigate allocations, caches, concurrency, or retained data rather than repeatedly raising the limit.
kubectl -n your-namespace rollout status deployment/your-deployment
kubectl -n your-namespace get pods
# Requires a working Metrics API and suitable permissions:
kubectl -n your-namespace top pod your-pod --containers05
Keep node pressure and application diagnosis separate
A node under memory pressure can evict workloads, and external actions can kill processes. Those paths need their own event and node evidence. Do not label every restart OOMKilled because one prior incident had that reason.
Keep the before/after termination records and the operation used for verification. The useful conclusion is that a specific workload completed under a tested allowance, with any remaining application-memory investigation still explicit.
Sınırları bil
Reproduced in a disposable Kubernetes v1.32.2 cluster with Python 3.12 allocating 128 MiB. A 32 MiB container limit killed it; a 256 MiB limit allowed completion. These are lab values, not sizing recommendations or a customer incident.
Kaynaklar ve ileri okuma
CoreTrailKit tarafından hazırlanan teknik yayın.
Bütün yazıları keşfet