在当今迅速发展的技术景观中，从单体架构迁移到微服务架构正变得越来越普遍。然而，对于那些在这个领域经验较少的人来说，适应这些新资源可能会带来重大的挑战。

无论您是开发团队、DevOps、基础设施还是其他技术团队的一部分，本文都将为您提供关于如何优化您的调试过程的有价值的见解。

您将了解到我个人使用的工具和策略，这些都是为了节省时间并提高调试微服务时的效率。

继续阅读以发现关于如何像专家一样调试微服务的专家建议和技巧！

【squids.cn】 全网zui低价RDS，免费的迁移工具DBMotion、数据库备份工具DBTwin、SQL开发工具等

---

调试Kubernetes中的错误的关键是对应用程序有完美的理解。这不仅仅是知道其他应用程序之间存在依赖关系，或者需要暴露某个端口，或者需要连接到同一个Kubernetes集群中的另一个应用程序。

要真正成功地调试Kubernetes错误，关键是要完全沉浸在开发者的世界中，并深入了解这些应用程序是如何工作的，以及它们为了正常运行需要什么。这样，您将更有能力处理可能出现的任何错误，并确保您的应用程序顺利高效地运行。

因此，请花时间充分了解您的应用程序及其依赖关系，您将大大提高成为Kubernetes调试专家的速度！

本文主要关注的是当您的应用程序已经在Kubernetes中并且遇到问题时该怎么做，而不是应用程序本身存在错误或外部因素阻碍它时该怎么做。我们还将介绍一些常见的错误情境。

---

在调试方面，我有两种方法，取决于应用的关键性和熟悉程度：自上而下和自下而上。

自上而下的方法

当我们熟悉该应用，并确信问题出在Kubernetes方面时，我们会使用这种方法，而紧急呼叫和解决问题是优先考虑的。

我们首先要查看入口。

从上图中我们可以看到，用户试图通过一个名为“testing.jjotah.com”的域名连接到Kubernetes的入口。通常，如果出现错误，是因为用户无法连接到应用程序，或者他们遇到了一些应用程序错误。从图中可以看出，当发生错误时，用户尝试与入口建立连接，这可能是或可能不是问题所在。

我将与您分享一些对我非常有效的命令。

• nc → 一个用于在两个计算机网络之间读取和写入数据的命令行工具 

• curl → 一个命令行工具，可以通过终端在设备和服务器之间交换数据 

• kubectl → 一个命令行工具，用于使用Kubernetes API与Kubernetes集群的控制平面通信。（别名k） 

在这种情况下，我们尝试使用nc命令检查端口是否开放。

nc -v test.jjotah.com 443

在调试与端口域验证相关的问题时，考虑所有涉及的因素是很重要的。在这种情况下，当出现“未知的名称或服务”错误时，我建议按照以下步骤操作：

1.在您的域名提供商中验证DNS设置。对于这个场景，我们需要确认域名“test.jjotah.com”指向了ingress控制器创建的负载均衡器。为了检查这一点，我们可以使用“dig”命令，并确认它指向了我们的kind集群中使用MetalLB创建的负载均衡器的IP，如图所示。

在我的情况下，我没有创建DNS，所以在创建DNS后，我将DNS名称指向了我的负载均衡器IP地址。

dig test.jjotah.com | grep test.jjotah.com

2.确保集群级别的外部网络连接已正确配置。这意味着需要审查可能影响客户端机器的DNS的任何安全设置或其他因素，特别是如果问题只影响一个人。通过仔细检查所有这些因素，我们可以有效地调试这个问题，并尽快使我们的应用程序重新运行。

INGRESS部分

当我们已经创建了DNS，我们可以再次测试到“443端口”的连接。

现在这个问题是“无法到达主机”，所以我建议检查：

1. 用户和ingress之间是否有东西，如防火墙、CDN或在集群外工作的东西

2. Ingress定义

kubectl get ing

这里我们找到了第一个问题：我们正在做检查，看看“443端口”是否开启，我们是否可以访问“80端口”，所以我们必须尝试“80端口”。

如果检查“80端口”你还是遇到同样的问题，也许你应该从自下而上的方法开始。

首先检查容器。我们知道，在Kubernetes中，最小的资源是包含容器的pods。因此，我们需要检查pod是否正确运行。假设你正在你的应用程序所在的命名空间工作，我们可以使用以下命令检查pod的状态：

kubectl get ing

在这种情况下，应用程序重启了三次，最后一次重启是六分钟前。因此，我们需要确定问题的根本原因。为此，执行以下命令，用你的应用程序pod的名字替换POD-NAME。

kubectl logs POD-NAME

kubectl describe pod POD-NAME

kubectl get events

检查是否有任何错误，如果没有，你可以切换到kube-system命名空间，检查主要组件，在以下pods上执行相同的命令。

• ETCD

• Apiserver

• Controller-Manager

• Scheduler

如果问题仍然存在，你可能需要连接到容器来检查应用程序。尽管以下命令已被弃用，但它仍然可以用来连接到容器：

kubectl exec -it POD-NAME bash

在容器内部，我们需要检查我们的应用程序是否正在运行（在我的情况下，我检查了“nginx”是否正在运行并公开了正确的端口）。我们可以在localhost上使用curl命令来验证应用程序在容器级别是否正常工作。

curl localhost

但是，有些容器可能没有安装像curl/nc/telnet这样的命令或执行它们所需的权限。这些容器被称为无发行版的。在这种情况下，最好在我们的应用程序定义中创建一个Sidecar，以安装调试所需的所有内容。

如果我们只有一个带有“nginx”的pod，我们应该将它转换为部署并添加一个sidecar来调试它。为此，我们可以删除“nginx”pod并创建一个部署定义。

kubectl delete pod nginx

在下一部分，我们将继续学习如何像专家一样调试。

作者：JJotah

更多技术干货请关注公众号 “云原生数据库”