解决Kubernetes Pod故障的5个简单技巧

点击上方 "程序员小乐"关注, 星标或置顶一起成长

每天凌晨00点00分, 第一时间与你相约

每日英文

Take chances, give everything, and leave with no regrets.

抓住机会，全心付出，不留遗憾的离开。

每日掏心话

生命中遇到的每一个人都是有理由的，之前所有的错失与遗憾，都只是为了遇到最终那个对的人。

来自：frankinbj | 责编：乐乐

链接：dockone.io/article/10055

程序员小乐(ID:study_tech) 第 864 次推文  图源：百度

往日回顾：如何使用 Nginx 优雅的限流

     

   正文   

在很多情况下，你可能会发现Kubernetes中的应用程序没有正确地部署，或者没有正常地工作。今天这篇文章就提供了如何去快速解决这类故障以及一些技巧。

在阅读了这篇文章之后，你还将深入了解Kubernetes的内部机制，另外，我还将与大家分享一些关于自己操作Kubernetes的一些非常有用的技巧。

那么，我们开始吧！

首先，Pod失败的原因一般有两个：

1. Kubernetes资源配置中的错误，例如在部署（Deployment）和服务（Service）里。

2. 代码中的问题。

在第一种情况下，容器一般不会启动。在后一个实例中，应用程序代码在容器启动后失败。我们将系统地处理每种情况。

在本练习中，我们会使用kubectl来实现与Kubernetes的交互。

技巧1：检查Pod

确认Pod处于运行（Running）状态或准备就绪（Ready）的状态。

kubectl get pods

如图，一个Pod在等待（Pending）状态9个小时，肯定不是个好事！容器没有启动，我们将会使用技巧2中的describe命令对此进行深入地研究。但，在这里我们强调一下在容器启动失败时发生的其他错误代码。如下：

• Imagepullbackoff：

  Docker镜像仓库不可访问，部署中指定的镜像名称或版本不正确。

  请确保镜像名称是正确的，并且镜像仓库是可访问的以及经过身份验证的（docker login…）。

• RunContainerError：

  也是一种可能。

  原因：

  缺少ConfigMap或Secrets。

• ContainerCreating：

  容器创建时一些组件无法立刻启用，比如持久卷？

在研究其他错误之前，让我们先尝试使用错误的镜像名称启动Pod。

# start Pod from image "ngin".
# 'web' can be any name, is the name of resulting K8S deployment
kubectl run web --image=ngin --replicas=1

最后一行展示了镜像错误

果然，完全不存在的镜像“ngin”导致了ImagePullBackOff错误。使用正确的镜像名称“nginx”就能解决这个问题。

kubectl run temp --image=nginx --replicas=1


kubectl get pods

如图，Pod已经起来了。

接下来，这里有一些在容器启动后可能发生的错误。

• Crashloopbackoff：

  Pod存活检查失败或Docker镜像出错。

  例如，Docker CMD即刻退出。

  可以用下面的技巧3来检查日志。

  注意：

  此截图中的“重启（RESTARTS）”列显示了重启的次数。

  在这种情况下，你应该会看到一些重启，因为当错误发生时，Kubernetes会反复尝试启动Pod。

• 如果Pod处于运行（Running）状态，而你的应用程序仍然不能正常工作，请继续技巧3和4。

技巧2：检查和Pod相关的事件

如果你在Pod状态上看到一个错误代码，你可以使用describe命令获得更多信息。这在容器本身没有启动的情况下是很有帮助的。

kubectl describe frontend-65c58c957d-f4cqn

截图的最后一行表明，由于缺少CPU资源，Pod还没有启动，请参见底部的消息。你可以增加Pod的CPU再重新部署应用程序。

技巧3：检查日志（Log）

现在容器已经启动，可以通过检查日志来查看应用程序是否正常运行。例如，Pod frontend-65c58c957d-bzbg2：

kubectl logs --tail=10 frontend-65c58c957d-bzbg2

实时滚动查看一个正在运行的日志：

kubectl logs -f frontend-65c58c957d-bzbg2

如果kubectl logs后没有任何输出，试试使用get pod，然后会发现这很有可能是一个新启动的Pod，因此可以尝试检查一些上一次挂掉的Pod的日志。

kubectl logs frontend-65c58c957d-bzbg2 --previous

技巧4：直接在Pod中运行“sh”、“bash”或“ash”

可以进入到Pod内部并运行命令来对应用程序进行故障排除（输入exit即可退出）。

kubectl exec -it frontend-65c58c957d-bzbg2 /bin/sh

技巧5：显示集群级别的事件

Kubernetes在它管理的资源状态发生变化（正常、警告等）时触发对应的事件。这能帮助我们了解背后到底发生了什么。get events命令能提供事件的聚合透视图。

# all events sorted by time.


kubectl get events --sort-by=.metadata.creationTimestamp# warnings only


kubectl get events --field-selector type=Warning# events related to Nodes


kubectl get events --field-selector involvedObject.kind=Node

额外的技巧

这是我最喜欢的技巧！熟练掌握各种命令会使你更有信心在游走在Kubernetes集群中。

首先，输入kubectl可以列出所有kubectl的命令。

接下来，尝试用下面的命令来执行grep调试命令。

kubectl | grep -i -A 10 debugging

列出可以在Kubernetes上运行的一些基本命令。

kubectl | grep -i -A 5 Basic

接下来，列出可操作的Kubernetes资源。

kubectl api-resources

现在可以自己搞一些命令了！你可以选择一个命令（get、describe、explain）并选取一个资源然后运行它！例如，get nodes。所以，再试试别的吧！

虽然有些组合可能并没什么意义，但除了这一点，整个command系统是相当直观和一致的；你可以轻松地编写命令并进行各种探索。

只是千万要小心，不要删除或修改你不希望碰到的对象。

列出Kubernetes命名空间（namespace）：

kubectl get ns

这样，你可以使用特定的命令来更深入地研究相应的选项或示例。

kubectl get --help


# see K8S system pods in 'kube-system' namespace!


kubectl -n kube-system get pods

正如你所看到的，Kubernetes的命令系统非常容易理解，简单地测试这些命令能让我们学到很多东西。

结论

有了这些，我希望你能在Kubernetes集群中找到并修复Kubernetes资源和代码中的错误。同时我打算接下来再介绍一下Kubernetes服务（Service）和网络的调试。

如果你已经走了这么远，我想感谢你对学习Kubernetes的坚持和奉献。请在下面留下你的评论，如果你有什么想法，或者有什么想谈论的话题，也请告诉我。

最后，如果你想在Kubernetes中部署一个真实的应用程序，请阅读我的上一篇文章。然后可以使用命令和故障排除工具对其进行修补。

欢迎在留言区留下你的观点，一起讨论提高。如果今天的文章让你有新的启发，学习能力的提升上有新的认识，欢迎转发分享给更多人。

欢迎各位读者加入订阅号程序员小乐技术群，在后台回复“加群”或者“学习”即可。

猜你还想看

阿里、腾讯、百度、华为、京东最新面试题汇集

HTTP 无状态中的 "状态" 到底指的是什么？

这张「二维码」火到了GitHub热榜第一：扫一扫，打破系统边界，文件秒传

什么才是真正的架构设计？

关注订阅号「程序员小乐」，收看更多精彩内容

嘿，你在看吗？