为什么 Kubernetes 调试如此成问题？

在 Kubernetes 集群中调试应用程序问题通常感觉就像在迷宫中穿行。容器在设计上是短暂的，一旦部署就不可改变。当出现问题并且我们需要深入研究问题时，这会带来独特的挑战。在深入研究调试工具和技术之前，必须掌握核心问题：为什么直接修改容器实例是个坏主意。这篇博文将带您了解 Kubernetes 调试的复杂性，提供见解和实用技巧，以有效地排除 Kubernetes 环境故障。

Kubernetes 的问题

视频

容器的不可变性

Kubernetes 的基本原则之一是容器实例的不变性。这意味着一旦容器运行，就不应该改变它。动态修改容器可能会导致不一致和不可预测的行为，尤其是当 Kubernetes 协调这些容器的生命周期并根据需要替换它们时。想象一下，当您试图诊断问题时，却发现您正在调查的容器已被修改，这使得很难一致地重现问题。

这种不变性背后的想法是确保容器的每个实例都与任何其他实例相同。这种一致性对于实现可靠、可扩展的应用程序至关重要。如果你开始修改容器，就会破坏这种一致性，导致一个容器的行为与另一个容器的行为不同，即使它们应该是相同的。

kubectl exec 的局限性

我们通常使用以下命令开始 Kubernetes 之旅：

$ kubectl -- exec -ti <pod-name>

这样就可以登录到容器中，感觉就像使用 SSH 访问传统服务器一样。但是，这种方法有很大的局限性。容器通常缺少基本的诊断工具——没有vim，没有traceroute，有时甚至没有 shell。对于那些习惯于功能齐全的 Linux 环境的人来说，这可能是一个沉重的打击。此外，如果容器崩溃，kubectl exec由于没有正在运行的实例可以连接，它将变得毫无用处。此工具不足以进行彻底的调试，尤其是在生产环境中。

想象一下，登录容器后发现甚至无法打开一个简单的文本编辑器来检查配置文件，这是多么令人沮丧的事情。缺乏基本工具意味着您通常只有很少的选项来诊断问题。此外，许多容器镜像的简约性（旨在减少其攻击面和占用空间）加剧了这个问题。

避免直接修改

虽然使用 之类的命令动态安装缺失的工具可能很诱人apt-get install vim，但这种做法违反了容器不变性的原则。在生产中，动态安装软件包可能会引入新的依赖项，从而可能导致应用程序故障。风险很高，因此维护部署清单的完整性至关重要，确保所有配置都是预定义且可重现的。

想象一下，生产中的快速修复需要安装缺失的软件包。这可能会解决眼前的问题，但可能会导致无法预料的后果。新软件包引入的依赖项可能会与现有依赖项冲突，从而导致应用程序不稳定。此外，这种方法使得重现确切的环境变得具有挑战性，而这对于调试和扩展应用程序至关重要。

进入临时容器

解决上述问题的关键在于临时容器。Kubernetes 允许在与您需要调试的应用程序容器相同的 pod 中创建这些临时容器。这些临时容器与主应用程序隔离，确保任何修改或安装的工具都不会影响正在运行的应用程序。

临时容器提供了一种在不违反不变性和一致性原则的情况下绕过限制的方法kubectl exec。通过在同一个 pod 中启动单独的容器，您可以在不改变其状态的情况下检查和诊断应用程序容器。这种方法可以保持生产环境的完整性，同时为您提供有效调试所需的工具。

使用 kubectl debug

该kubectl debug命令是一个功能强大的工具，可简化临时容器的创建。kubectl exec与登录到现有容器不同，kubectl debug它会在同一命名空间内创建一个新容器。此容器可以运行不同的操作系统、挂载应用程序容器的文件系统并提供所有必要的调试工具，而无需更改应用程序的状态。此方法可确保您即使原始容器无法运行也可以检查和诊断问题。

例如，让我们考虑使用临时 Ubuntu 容器调试容器的场景：

kubectl debug <myapp> -it <pod-name> --image=ubuntu --share-process --copy-to=<myapp-debug>

此命令会在同一 pod 中启动一个基于 Ubuntu 的新容器，从而提供完整的环境来诊断应用程序容器。即使原始容器缺少 shell 或崩溃，临时容器仍可正常运行，允许您执行必要的检查并根据需要安装工具。它依赖于我们可以在同一个 pod 中拥有多个容器的事实，这样我们就可以检查被调试容器的文件系统而无需实际进入该容器。

临时容器的实际应用

为了说明这一点，让我们深入研究一下如何在实际场景中使用临时容器。假设您有一个容器由于神秘问题而不断崩溃。通过部署带有一整套调试工具的临时容器，您可以监控日志、检查文件系统和跟踪进程，而不必担心原始容器环境的限制。

例如，您可能会遇到应用程序容器由于未处理的异常而崩溃的情况。通过使用kubectl debug，您可以创建一个与原始容器共享相同网络命名空间的临时容器。这允许您捕获网络流量并对其进行分析，以了解是否存在与连接或数据损坏相关的任何问题。

安全注意事项

虽然临时容器降低了影响生产环境的风险，但它们仍然存在安全风险。限制对调试工具的访问并确保只有授权人员才能部署临时容器至关重要。对这些系统的访问要像交出基础设施的钥匙一样谨慎。

临时容器本质上可以访问 pod 内的敏感信息。因此，必须实施严格的访问控制和审计日志，以跟踪谁在部署这些容器以及正在采取哪些操作。这可确保调试过程不会引入新的漏洞或暴露敏感数据。

插曲：可观察性的作用

kubectl exec虽然和等工具kubectl debug对于故障排除非常有用，但它们并不能替代全面的可观察性解决方案。可观察性让您可以实时监控、跟踪和记录应用程序的行为，从而无需进行侵入式调试会话即可更深入地了解问题。

这些工具并不适合日常调试：该角色应由各种可观察性工具承担。我将在下一篇文章中更详细地讨论可观察性。

命令行调试

kubectl exec虽然和这样的工具非常kubectl debug有用，但有时你需要深入研究应用程序代码本身。这时我们就可以使用命令行调试器了。命令行调试器允许你以非常精细的级别检查应用程序的状态，逐步执行代码、设置断点和检查变量状态。就我个人而言，我并不经常使用它们。

例如，Java 开发人员可以使用jdbJava 调试器，它类似于C/C++ 程序。以下是您在 Kubernetes 环境中gdb如何使用的基本概述：jdb

1. 设置调试

首先，您需要在启用调试的情况下启动 Java 应用程序。这通常涉及向 Java 命令添加调试标志。但是，正如我在此处的帖子中所讨论的那样，还有一种更强大的方法，不需要重新启动：

java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005 -jar myapp.jar

2. 端口转发

由于调试器需要连接到应用程序，因此您将设置端口转发以将 pod 的调试端口公开到本地计算机。这很重要，因为JDWP 很危险：

kubectl port-forward <pod-name> 5005:5005

3. 连接调试器

完成端口转发后，您现在可以连接jdb到远程应用程序：

jdb -attach localhost:5005

在这里，您可以使用jdb命令设置断点、逐步执行代码和检查变量。此过程允许您调试代码本身的问题，这对于诊断通过日志或表面检查无法立即发现的复杂问题非常有用。

连接标准 IDE 进行远程调试

到目前为止，我更喜欢 IDE 调试。除了演示之外，我从未将 JDB 用于任何其他用途。现代 IDE 支持远程调试，通过利用 Kubernetes 端口转发，您可以将 IDE 直接连接到 pod 内正在运行的应用程序。

要设置远程调试，我们从与命令行调试相同的步骤开始。配置应用程序并设置端口转发。

1.配置IDE

在您的 IDE（例如 IntelliJ IDEA、Eclipse）中，设置远程调试配置。将主机指定为，localhost将端口指定为5005。

2. 开始调试

在 IDE 中启动远程调试会话。现在，您可以直接在 IDE 中设置断点、逐步执行代码和检查变量，就像调试本地应用程序一样。

结论

调试 Kubernetes 环境需要结合传统技术和专为容器编排设计的现代工具。了解kubectl exec临时容器的局限性和优势可以显著增强您的故障排除过程。但是，最终目标应该是在您的应用程序中构建强大的可观察性，减少临时调试的需求并实现主动问题检测和解决。

通过遵循这些准则并利用正确的工具，您可以自信而准确地应对 Kubernetes 调试的复杂性。在本系列的下一篇文章中，我们将深入探讨 Kubernetes 中的常见配置问题以及如何有效解决这些问题。