如何像专业人士一样调试 Kubernetes 应用程序错误(一)
如何像专业人士一样调试 Kubernetes 应用程序错误(二)
【squids.cn】 全网zui低价RDS,免费的迁移工具DBMotion、数据库备份工具DBTwin、SQL开发工具等
继续我们的调试之旅,让我们开始调试服务和入口端!
正如我们在我的第一篇博客文章中所看到的,我喜欢将Kubernetes表示为分层的洋葱。我们之前已经验证过,Kubernetes有可以公开应用程序的服务。首先让我们收集服务IP。
kubectl get svc
然后,我们重新连接到Alpine pod并检查服务是否响应。
在这种情况下,它没有响应,所以服务可能有问题。我们首先应该做的是检查服务定义。
对于有经验的人,可能已经注意到在之前的课程中创建部署时,而不是pod时的问题。但对于新手来说,我会快速解释服务是如何工作的。
服务指向带有选择器和标签的部署或pod。在这种情况下,服务指向“run: nginx-p”,但当我们创建部署时,我们放置了“app: nginx”。
为了确认这个理论,我们将执行:
kubectl get deploy -l app=nginx-p
kubectl get deploy -l app=nginx
知道问题所在后,我们将通过在线编辑服务来快速解决它。如果您不信任这一点,您始终有选择更改服务定义文件并应用它的选项。
kubectl edit svc SVC-NAME
保存或应用后,我们重新连接到Alpine pod并通过svc IP测试连接。
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
更多技术干货请关注公众号 “云原生数据库”