在当今迅速发展的技术景观中，从单体架构迁移到微服务架构正变得越来越普遍。然而，对于那些在这个领域经验较少的人来说，适应这些新资源可能会带来重大的挑战。
无论您是开发团队、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端口”的连接。
现在这个问题是“无法到达主机”，所以我建议检查：
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
更多技术干货请关注公众号 “云原生数据库”
