K8s Pod 故障排查，一个不为人知的技巧！

原文链接：https://blog.51cto.com/u_15682575/8768364

如果您在 Kubernetes 上运行软件，您会想要在某些时候去调试您所部署的软件的一些方面。对于习惯于使用虚拟机 (VMs) 的人来说能自然使用的一种简单的调试方法，就是连接到一个正在运行的 pod，然后进行解译:

kubectl exec -it podname -c containername -- bash

这通常行之有效，而且非常管用。然而，至少有两种 Kubernetes "最佳实践 "限制了 exec 的实用性:

当应用这些最佳实践时，使用 kubectl exec 连接到您的容器要么不可行，要么进入到不适合进行调试的环境。

kubectl exec 指令不允许指定用户标志或能力以启动进程，而是会从目标容器的主指令中复制这些设置。

调试容器

在解决运行容器问题时，Kubernetes 提供了一种原生化调试策略，即使用 kubectl debug 。调试指令会在运行中的 pod 中启动一个新的容器。这个新容器能够以不同的用户身份以及从您选择的任何镜像去运行。由于调试容器与目标容器位于同一个 pod 中运行(因此在同一个节点上)，两者之间不需要绝对的隔离。调试容器可以与同一 pod 中运行的其他容器共享系统资源。

考虑去检查在 pod postpod 中的容器 postcont 里运行的 PostgreSQL 数据库的 CPU 使用情况。这个 pod 并不以 root 用户身份运行，并且 Postgres 镜像没有安装类似 top 或 htop 的工具，也就是说， kubectl exec 指令几乎没有作用。您可以按照以下的指令去运行:

kubectldebug -it \ --container=debug-container \ --image=alpine \ --target=postcont \ postpod

您将以 root 身份登录(这是 Alpine 镜像的默认设置)，并可以轻松安装您最喜欢的交互式进程查看器 htop ( apt add htop )。您与 postcont 容器共享同一个进程命名空间，可以查看并甚至终止在此运行的所有进程！当您退出进程时，临时容器也会终止。

如果希望调试容器与 postcont 共享相同的进程命名空间，即使 postcont 是在 postpod 中运行的唯一容器，指定 --target 是不具备选择性的 (non-optional)。

您可以按 CTRL+P CTRL+D 断开与临时容器/bash 会话 (session) 的连接，而无需退出 (终止) 它。再使用 kubectl attach 即可重新连接。

kubectl debug 提供的功能比这里概述的更多，比如使用一个修改后的启动指令复制 pods，或通过访问节点文件系统的启动一个 "节点 (node) " pod。

原理解释

以上的 kubectl debug 指令是通过创建临时容器 (ephemeral container) 来实现。这些容器应在现有 pod 中临时运行，以支持故障排除等操作。「普通」容器和临时容器之间的区别很小。而查看 Kubernetes 在创立之初所做的基础架构选择最能让我们理解使用临时容器的原因:

Pod 应该是免洗的、可替换的，并且 Pod 规范也是不可改变的。

当 Kubernetes 主要用于部署无状态工作负载时，这一点更加合理——因为此时 pod 本身会被认为是临时的。在这个 Kubernetes 中它可能会受到限制。Pod 规范保持不变，但 Kubernetes 会将临时容器作为 Pod 的子资源建模。 与「普通」容器不同，临时容器不属于 Pod 规范的一部分 。

挂载卷 (volumes)

内置指令 kubectl debug 非常有用。它允许您在运行的 pod 中添加一个临时容器，并可选择与运行中的容器共享进程命名空间。不过，如果您希望使用 kubectl debug 来检查或修改运行中容器文件系统的某个部分，那就不走运了——因为调试 pod 的文件系统与您将其连接到的容器的文件系统是分离的。幸运的是，我们可以做的更好。原理很简单:

因为没有用于创建临时容器的 kubectl 命令，所以我们需要构建一个 PATCH 请求到 K8s API 来创建它。 kubectl proxy 指令允许访问 K8s API。这一过程对用户来说并不太友好，因此将这一过程封装到脚本或 kubectl 插件中是合理的。您可以在这里找到这样一个脚本实现示例:

https://github.com/JonMerlevede/kubectl-superdebug

需要注意的是，这种方法和脚本可以很容易地扩展到从目标容器中复制环境变量的规范。如果您将此脚本保存为 kubectl-superdebug ，并将其放在您的路径上，就可以在任何地方以 kubectl superdebug 的形式运行，如下所示:

还可以尝试扩展此脚本，将目标容器的其他方面复制到调试容器中，例如环境变量引用。

至此，Kubernetes 本机调试运行中的容器的方法概述就完成了，应该能满足大多数人的需求。

非 Kubernetes 原生方法

Kubernetes 不提供以 root 身份连接到正在运行的容器的方法（除非主进程以 root 身份运行），也不提供从另一个容器访问容器根文件系统的方法。但这并不意味着这些事情不可能做到。毕竟， Kubernetes 只是一个位于容器化引擎之上的容器编排器。如果出于某种原因，确实有必要的话，您通常可以通过移除抽象层来做任何您想做的事。

如果您使用的是 Docker 引擎，并且可以直接从节点或通过节点上运行的特权容器访问您的引擎，那么您就可以运行 docker exec --user ，并以您选择的用户身份执行一个进程。

kubectl ssh 和 kubectl exec-user 等插件实现了这种方法。但遗憾的是，containerd 和 CRI-O 等现代引擎不再提供 --user 这样标志功能，这意味着这些插件无法在当下的 Kubernetes 安装上运行。

不过，即使是这些现代引擎，通常也只是与 Linux 命名空间接口。通过输入相应的 Linux 命名空间集，您可以在任何您想要的「容器」中运行指令。kpexec 工具实现了这种方法。它在与目标容器相同的节点上启动一个有权限的 pod，然后确定要针对哪些 (Linux) 命名空间，在这些 (Linux) 命名 空间中执行命令，最后将其输出流式传输到您的终端。作为额外的收获，它还能在目标容器的文 件系统之上叠加一套用于调试的工具。

与 kubectl exec 不同，kpexec 可以使用不同的 uid/gid 运行指令，甚至可以使用与容器主进程不同的功能。它与 containerd 和 cri-o 兼容。只是 kpexec 采用的方法有些笨重和脆弱，可能与集群的安全配置不兼容。但如果 kubectl (super) 调试无法满足您的需求，则值得考虑它。

需要注意，kpexec 使用 nsenter 是直接在命名空间中执行指令的。它与无处不在的容器运行时 runc 兼容，但与 Kata Containers 等运行时不兼容。

借助 Appilot 对话式诊断 K8s

Appilot 是一款面向 DevOps 场景的开源 AI 助手，它可以 充分利用 AI 大语言模型的能力让用户直接输入自然语言进一步简化应用部署与管理体验 。用户可以根据自身的需求和使用习惯，将 Appilot 集成到任意平台，进而实现通过输入自然语言即可调用后端平台的能力，轻松完成 Kubernetes debug 工作。

Appilot 项目地址 https://github.com/seal-io/appilot

往期推荐

点亮，服务器三年不宕机