website/content/zh/docs/tasks/debug-application-cluster/debug-running-pod.md at 2fe48fabb022ff76f876c6f146aa20201a0ff2bb

Files

T

luzg d646c6b4f6 add page: /zh/docs/tasks/debug-application-cluster/debug-running-pod/, fix 24177

make change according to howieyuen

2020-09-30 14:46:24 +08:00

9.7 KiB

Raw Blame History

title, content_type

title	content_type
调试运行中的 Pod	task

本页解释了如何调试节点上正在运行(或者正在崩溃)的 Pod。

你的 {{< glossary_tooltip text="Pod" term_id="pod" >}} 应该已经调度并正在运行。如果 Pod 尚未运行，则从应用故障排查开始。
对于一些高级调试步骤，你需要知道 Pod 在哪个节点上运行，并拥有在该节点上执行 shell 命令的权限。在使用 kubectl 运行标准调试步骤时，则不需要这种权限。

检查 Pod 日志

首先，查看受影响的容器的日志：

kubectl logs ${POD_NAME} ${CONTAINER_NAME}

如果你的容器以前崩溃过，你可以访问前一个容器的崩溃日志：

kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME}

使用容器 exec 调试

如果 {{< glossary_tooltip text="容器镜像" term_id="image" >}} 包含调试工具，就像基于 Linux 和 Windows 基础镜像构建的镜像一样，你可以使用 kubectl exec 在特定的容器中执行命令：

kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN}

{{< note >}} -c ${CONTAINER_NAME} 是可选项。对于单容器 Pod，可以省略此参数。 {{< /note >}}

例如，要查看正在运行的 Cassandra Pod 的日志，可以执行：

kubectl exec cassandra -- cat /var/log/cassandra/system.log

你可以使用 kubectl exec 的 -i 和 -t 参数启动一个连接到终端的 shell，例如：

kubectl exec -it cassandra -- sh

更多细节，参见获取运行容器的 Shell。

使用临时调试容器进行调试

因为容器已经崩溃，或因为容器镜像没有内含调试工具，比如 distroless images，导致 kubectl exec 不足以解决问题时， {{< glossary_tooltip text="Ephemeral containers" term_id="ephemeral-container" >}} 对交互式故障诊断非常有用。从 v1.18 开始，kubectl 提供 alpha 命令，它可以为调试创建临时容器。

示例：使用临时容器调试

{{< note >}} 本节中的示例要求在集群启用 EphemeralContainers 特性门控。并且要求 kubectl v1.18 或更高版本。 {{< /note >}}

可以使用 kubectl alpha debug 命令将临时容器添加到正在运行的 Pod 中。首先，为本例创建一个 Pod：

kubectl run ephemeral-demo --image=k8s.gcr.io/pause:3.1 --restart=Never

{{< note >}} 本节在示例中使用 pause 容器镜像，是因为它不包含用户态的调试工具。但此方法适用于所有容器镜像。 {{< /note >}}

如果你试图使用 kubectl exec 去建立一个 shell，你会看到一个报错，这是因为在容器镜像中并没有包含 shell。

kubectl exec -it ephemeral-demo -- sh

OCI runtime exec failed: exec failed: container_linux.go:346: starting container process caused "exec: \"sh\": executable file not found in $PATH": unknown

你可以使用 kubectl alpha debug 添加一个调试容器。如果指定了 -i/--interactive 参数， kubectl 将自动连接到临时容器的控制台。

kubectl alpha debug -it ephemeral-demo --image=busybox --target=ephemeral-demo

Defaulting debug container name to debugger-8xzrl.
If you don't see a command prompt, try pressing enter.
/ #

此命令添加一个新的 busybox 容器并连接。 --target 参数指定了另一个容器的进程命名空间。这里必须这样做，因为 kubectl run 没有在它创建的 Pod 中启用进程命名空间共享。

{{< note >}} {{< glossary_tooltip text="Container Runtime" term_id="container-runtime" >}} 必须支持 --target 参数。如果不支持，临时容器可能无法启动，或者可能使用隔离的进程名称空间启动。 {{< /note >}}

可以使用 kubectl describe 查看新创建的临时容器的状态：

kubectl describe pod ephemeral-demo

...
Ephemeral Containers:
  debugger-8xzrl:
    Container ID:   docker://b888f9adfd15bd5739fefaa39e1df4dd3c617b9902082b1cfdc29c4028ffb2eb
    Image:          busybox
    Image ID:       docker-pullable://busybox@sha256:1828edd60c5efd34b2bf5dd3282ec0cc04d47b2ff9caa0b6d4f07a21d1c08084
    Port:           <none>
    Host Port:      <none>
    State:          Running
      Started:      Wed, 12 Feb 2020 14:25:42 +0100
    Ready:          False
    Restart Count:  0
    Environment:    <none>
    Mounts:         <none>
...

完成后，使用 kubectl delete 删除 Pod：

kubectl delete pod ephemeral-demo

通过节点上的 shell 进行调试

如果这些方法都不起作用，你可以找到运行 Pod 的主机并通过 SSH 连接到该主机，但是 Kubernetes API 中的工具通常不需要这样做。因此，如果你发现自己需要 ssh 到一台机器上，请在 GitHub 上提交一个功能请求，描述你的用例以及为什么这些工具不够用。

9.7 KiB Raw Blame History Unescape Escape

{{% heading "prerequisites" %}}