Kubernetes / Pods, Containers & Application Health
Distinguish normal container completion from a failed long-running service
A container that exits successfully may be correct for a Job but wrong for a Deployment. Inspect the owner and termination context.
Environment and inputs: Kubernetes · kubectl with supported client/server versions and delegated RBAC. Examples use namespace app unless noted. Check context, namespace, APIs and provider support first.
Start with this check
Confirm the environment and replace sample objects, namespaces, images, paths and hosts with approved targets. Share only relevant, sanitized output. Follow the workload owner’s process for changes.
kubectl -n app get pod worker-0 -o jsonpath='{.metadata.ownerReferences[*].kind}{" "}{.status.containerStatuses[*].lastState.terminated.reason}'Read the result
The owner kind and recorded state help distinguish batch intent from a continuously supervised process. A successful exit does not prove business output is correct.
Resolve and verify
Compare the controller type, command and expected lifecycle with application design. Correct a process that backgrounds itself or use an appropriate batch controller.
Before changing production
Do not force a completed batch container to remain alive with a sleep loop just to make status look green.