如何像专业人士一样调试 Kubernetes 应用程序错误（三）

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

继续我们的调试之旅，让我们开始调试服务和入口端！

正如我们在我的第一篇博客文章中所看到的，我喜欢将Kubernetes表示为分层的洋葱。我们之前已经验证过，Kubernetes有可以公开应用程序的服务。首先让我们收集服务IP。

arduino 复制代码

kubectl get svc

然后，我们重新连接到Alpine pod并检查服务是否响应。

在这种情况下，它没有响应，所以服务可能有问题。我们首先应该做的是检查服务定义。

对于有经验的人，可能已经注意到在之前的课程中创建部署时，而不是pod时的问题。但对于新手来说，我会快速解释服务是如何工作的。

服务指向带有选择器和标签的部署或pod。在这种情况下，服务指向"run: nginx-p"，但当我们创建部署时，我们放置了"app: nginx"。

为了确认这个理论，我们将执行：

arduino 复制代码

kubectl get deploy -l app=nginx-p kubectl get deploy -l app=nginx

知道问题所在后，我们将通过在线编辑服务来快速解决它。如果您不信任这一点，您始终有选择更改服务定义文件并应用它的选项。

复制代码

kubectl edit svc SVC-NAME

保存或应用后，我们重新连接到Alpine pod并通过svc IP测试连接。

sql 复制代码

kubectl get svc kubectl exec -it alpine sh curl SVC-IP

现在我们的服务运行正常了，我们将关注指向该服务的入口部分。

我们检查入口定义。

在这里，我们看到的情况与服务相同，即入口具有"nginx-p"作为服务名称，而我们的服务称为"nginx"，并且端口是80，这是服务使用的相同端口。因此，我们需要更改服务名称为正确的名称并检查它。

一旦入口更改并保存，我们从集群外部（从我们的本地机器）检查一切是否正常运行。

复制代码

curl test.jjotah.com

为了向您展示它的运行情况，我们将更改Nginx的消息以在网络和控制台上显示它。

结论

根据我发布的第一部分，我们将从上到下和从下到上遵循调试方法。
你需要理解应用程序如何工作，代码，它需要什么要求等。
仅仅因为应用程序在运行并不意味着它工作正常。也就是说，如果应用程序正在运行，它可能没有错误控制，端口可能没有正确暴露，或者有其他原因。永远不要信任应用程序正常工作（只要您已经查看了您的范围内的所有内容）。
Kubernetes之外的外部因素非常重要。诸如CDN、防火墙、网络、存储等Kubernetes之外的因素对集群的操作至关重要。我们将不得不查看可能影响应用程序使用的所有内容。
负载均衡器和DNS对于应用程序的操作也很重要，因此我们需要检查入口控制器是否创建了负载均衡器和目标组，负载均衡器中暴露的端口，以及入口。
基本组件。尽管这很少见，但我们必须牢记，etcd、apiserver、controller-manager、调度程序和节点也可能失败。如果您看到它们失败，并且在入口控制器等中没有看到任何类型的错误，那么可能是Kubernetes的一些通用问题，我总是建议前往apiserver和其他地方查看集群的行为。
网络插件。的确，像基本组件一样，它失败的可能性很小，特别是如果网络是由公共云管理的。但是，基于我的现场经验，这是我们必须在所有场合考虑的风险因素。

自下而上的方法甚至可以通过连接到节点并使用诸如crictl或docker之类的工具在容器级别执行命令，以查看容器的实时性能，而不是pod。通过逐层进行，我们可以更有效地调试应用程序，并了解Kubernetes可能在哪里出现故障。

作者：JJotah

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