Determine the Reason for Pod Failure
This page shows how to write and read a Container termination message.
Termination messages provide a way for containers to write information about fatal events to a location where it can be easily retrieved and surfaced by tools like dashboards and monitoring software. In most cases, information that you put in a termination message should also be written to the general Kubernetes logs.
- Before you begin
- Writing and reading a termination message
- Customizing the termination message
- What's next
Before you begin
You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using Minikube, or you can use one of these Kubernetes playgrounds:
To check the version, enter kubectl version
.
Writing and reading a termination message
In this exercise, you create a Pod that runs one container. The configuration file specifies a command that runs when the container starts.
debug/termination.yaml
|
---|
|
Create a Pod based on the YAML configuration file:
kubectl apply -f https://k8s.io/examples/debug/termination.yaml
In the YAML file, in the
cmd
andargs
fields, you can see that the container sleeps for 10 seconds and then writes “Sleep expired” to the/dev/termination-log
file. After the container writes the “Sleep expired” message, it terminates.Display information about the Pod:
kubectl get pod termination-demo
Repeat the preceding command until the Pod is no longer running.
Display detailed information about the Pod:
kubectl get pod termination-demo --output=yaml
The output includes the “Sleep expired” message:
apiVersion: v1 kind: Pod ... lastState: terminated: containerID: ... exitCode: 0 finishedAt: ... message: | Sleep expired ...
Use a Go template to filter the output so that it includes only the termination message:
kubectl get pod termination-demo -o go-template="{{range .status.containerStatuses}}{{.lastState.terminated.message}}{{end}}"
Customizing the termination message
Kubernetes retrieves termination messages from the termination message file
specified in the terminationMessagePath
field of a Container, which as a default
value of /dev/termination-log
. By customizing this field, you can tell Kubernetes
to use a different file. Kubernetes use the contents from the specified file to
populate the Container’s status message on both success and failure.
In the following example, the container writes termination messages to
/tmp/my-log
for Kubernetes to retrieve:
apiVersion: v1
kind: Pod
metadata:
name: msg-path-demo
spec:
containers:
- name: msg-path-demo-container
image: debian
terminationMessagePath: "/tmp/my-log"
Moreover, users can set the terminationMessagePolicy
field of a Container for
further customization. This field defaults to “File
” which means the termination
messages are retrieved only from the termination message file. By setting the
terminationMessagePolicy
to “FallbackToLogsOnError
”, you can tell Kubernetes
to use the last chunk of container log output if the termination message file
is empty and the container exited with an error. The log output is limited to
2048 bytes or 80 lines, whichever is smaller.
What's next
- See the
terminationMessagePath
field in Container. - Learn about retrieving logs.
- Learn about Go templates.
Feedback
Was this page helpful?
Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on Stack Overflow. Open an issue in the GitHub repo if you want to report a problem or suggest an improvement.