确定 Pod 失败的原因

    终止消息为容器提供了一种方法，可以将有关致命事件的信息写入某个位置， 在该位置可以通过仪表板和监控软件等工具轻松检索和显示致命事件。 在大多数情况下，你放入终止消息中的信息也应该写入 常规 Kubernetes 日志。

    你必须拥有一个 Kubernetes 的集群，同时你的 Kubernetes 集群必须带有 kubectl 命令行工具。 建议在至少有两个节点的集群上运行本教程，且这些节点不作为控制平面主机。 如果你还没有集群，你可以通过 Minikube 构建一个你自己的集群，或者你可以使用下面任意一个 Kubernetes 工具构建：

    在本练习中，你将创建运行一个容器的 Pod。 配置文件指定在容器启动时要运行的命令。

    debug/termination.yaml

    1. 基于 YAML 配置文件创建 Pod：

      1. 显示 Pod 的信息：

        重复前面的命令直到 Pod 不再运行。

      2. 显示 Pod 的详细信息：

        1. kubectl get pod termination-demo --output=yaml

        输出结果包含 “Sleep expired” 消息：

      3. 使用 Go 模板过滤输出结果，使其只含有终止消息：

        1. kubectl get pod termination-demo -o go-template="{{range .status.containerStatuses}}{{.lastState.terminated.message}}{{end}}"

      Kubernetes 从容器的 terminationMessagePath 字段中指定的终止消息文件中检索终止消息， 默认值为 /dev/termination-log。 通过定制这个字段，你可以告诉 Kubernetes 使用不同的文件。 Kubernetes 使用指定文件中的内容在成功和失败时填充容器的状态消息。

      终止消息旨在简要说明最终状态，例如断言失败消息。 kubelet 会截断长度超过 4096 字节的消息。

      所有容器的总消息长度限制为 12KiB，将会在每个容器之间平均分配。 例如，如果有 12 个容器（ 或 containers）， 每个容器都有 1024 字节的可用终止消息空间。

      默认的终止消息路径是 /dev/termination-log。 Pod 启动后不能设置终止消息路径。

      在下例中，容器将终止消息写入 /tmp/my-log 给 Kubernetes 来检索：

      1. apiVersion: v1
      2. kind: Pod
      3.   name: msg-path-demo
      5.   containers:
      6.   - name: msg-path-demo-container
      7.     image: debian
      8.     terminationMessagePath: "/tmp/my-log"
      • 参考 资源的 terminationMessagePath 字段。
      • 了解 Go 模板。