← Start of tutorial

WIUNIX ACADEMY

CrashLoopBackOff or OOMKilled? Diagnose the failed container before restarting it

Page 2 of 3. Review the earlier steps and prerequisites before continuing.

YOUR SYSTEM. YOUR STEPS.

Where are you working?

Choose your OS and version. The prerequisites, commands and troubleshooting follow your environment.

AlmaLinux 10Reviewed against official documentation ·

USE YOUR OWN VALUES

Configure this tutorial

Set the example values for your environment; related explanations and copy panels update together. Never enter passwords, private keys or tokens. Values stay in this tab and are not sent to the server or share links. Check actual DNS, certificates and network policy before running commands.

Different IP addresses, domains or ports? Open the settings below, change the values and select “Apply to tutorial”, then copy the updated commands.

Set values for my environment7 editable values
05

LET’S BUILD

Inspect probe timing without disabling protection

Read the full selected container specification locally. Failed liveness/startup probes may trigger restart; readiness failure normally removes readiness rather than killing the container. A startup probe can protect a genuinely slow startup before liveness takes over. Confirm the path, port, scheme, startup duration and timeout under real load. Do not simply remove liveness or make every endpoint return success.

bash

Operator terminal; authorized lab context

kubectl --context='lab' -n 'academy-lab' get deployment 'api' -o jsonpath='{range .spec.template.spec.containers[*]}{.name}{"\nresources="}{.resources}{"\nliveness="}{.livenessProbe}{"\nreadiness="}{.readinessProbe}{"\nstartup="}{.startupProbe}{"\n\n"}{end}'
How do I know it worked?

Probe settings and event failures agree with the measured startup/health behavior, or the probe hypothesis is rejected.

06

LET’S BUILD

Distinguish a container limit from node pressure

A sampled current memory value is not the peak that killed a process. Metrics Server may be absent and a short spike may not be captured. Check requests/limits, namespace defaults and quotas, node conditions and historical working-set/RSS/heap metrics. Increasing a request changes scheduling; increasing a limit changes headroom but does not fix a leak. Node MemoryPressure and eviction need a node-level investigation.

bash

Operator terminal; authorized lab context

kubectl --context='lab' -n 'academy-lab' top pod 'api-example' --containers
kubectl --context='lab' -n 'academy-lab' get limitrange,resourcequota
kubectl --context='lab' get nodes
kubectl --context='lab' -n 'academy-lab' get events --field-selector involvedObject.name='api-example' --sort-by=.metadata.creationTimestamp
kubectl --context='lab' get pod 'api-example' -n 'academy-lab' -o jsonpath='{.spec.nodeName}{"\n"}'
# Replace the node name below with the observed .spec.nodeName.
kubectl --context='lab' describe node 'worker1'
How do I know it worked?

Classify limit exhaustion, node eviction or insufficient evidence; missing metrics are recorded as unknown.

07

LET’S BUILD

Check the owner and rollout boundary

Use ownerReferences to confirm the ReplicaSet and Deployment relationship. StatefulSets, Jobs, static Pods and operators have different recovery contracts and are outside this rollback panel. Compare image identity, configuration changes and rollout history. Do not dump Secret objects or resolved environment values into the incident report.

bash

Operator terminal; authorized lab context

kubectl --context='lab' -n 'academy-lab' get pod 'api-example' -o jsonpath='{.metadata.ownerReferences}'
kubectl --context='lab' -n 'academy-lab' rollout history deployment/'api'
kubectl --context='lab' -n 'academy-lab' get deployment 'api' -o jsonpath='{range .spec.template.spec.containers[*]}{.name}{" "}{.image}{"\n"}{end}'
How do I know it worked?

The responsible Deployment and relevant revision are confirmed before any mutation.

Choose the smallest supported correction

Application exit: repair the invalid configuration, unavailable dependency or incompatible image through the owning manifest. OOM: capture a profile safely, fix unbounded retention/concurrency and size memory using measured peaks plus headroom. Probe failures: correct a demonstrably wrong probe or startup budget. Node pressure: resolve node capacity and workload placement with the cluster owner.

Change one hypothesis at a time in the source of truth, review the manifest diff and use the existing deployment pipeline. Avoid live edits that GitOps immediately reverses. This guide does not prescribe a universal memory limit or aggressive automatic retry delay.

08

LET’S BUILD

Prove recovery across a workload window

After the reviewed change is deployed, watch rollout status and replacement Pods, then verify the actual application from an authorized client. Old Pod restart counts do not transfer to new Pods: record new UIDs and initial counts, then compare after a meaningful load/startup window. Ready alone does not prove correctness or absence of memory growth.

bash

Operator terminal; authorized lab context

kubectl --context='lab' -n 'academy-lab' rollout status deployment/'api' --timeout=180s
kubectl --context='lab' -n 'academy-lab' get pods -o wide
kubectl --context='lab' -n 'academy-lab' get deployment 'api' -o jsonpath='{.status.availableReplicas}{" available / "}{.spec.replicas}{" desired\n"}'
How do I know it worked?

Desired replicas are available, functional checks pass and new restart/memory observations remain stable for the chosen window.

09

LET’S BUILD

Rollback only a confirmed Deployment revision

Optional disruptive recovery: only if the owner approves and the old image/config remains compatible with current data/schema, return to the explicit known-good revision. Revision history does not back up external ConfigMaps, Secrets, databases or persistent volumes. If compatibility is uncertain, contain traffic through the owning incident plan instead of guessing.

bash

Operator terminal; authorized lab context

kubectl --context='lab' -n 'academy-lab' rollout undo deployment/'api' --to-revision='2'
kubectl --context='lab' -n 'academy-lab' rollout status deployment/'api' --timeout=180s
How do I know it worked?

The intended revision rolls out; repeat application, restart and resource checks.

Explore all tutorials ↗