如何找到真实的故障原因,每个人都有自己的实践总结。而 Kubernetes 集群的复杂性会在排查的过程中造成干扰,会让你忽视真正需要洞悉的信号。在考虑 Kubernetes 中的故障排查时,笔者通常采取分层的方法,依次 check 如下因素:
- 节点(控制面板和 node)
- 集群原生组件(apiserver、controller-manager、scheduler、kubelet、etcd、容器运行时等)
- 集群附加组件(网络和网络策略 Calico 等、服务发现 coreDNS 等)
- 终端用户应用程序(实际部署的 apps)
- 检查 kube-system 命名空间下的 Pod 状态:
kubectl get pods -n kube-system -o wide
; - 检查是否安装了 Pod 网络附加组件,如 Calico 等;
- 检查节点组件 kubelet 是否正常运行,
systemctl is-active kubelet
; PLEG
: 容器运行时是否工作正常,节点服务器的 Docker 或者 containerd 是否运行正常。
参考:https://aws.amazon.com/cn/premiumsupport/knowledge-center/eks-node-status-ready/
- OOM(内存不足)事件:1)优化应用程序内部的逻辑,优化内存使用;2)内存用量达到预警值时驱逐 pod,以减少对系统的冲击并防止系统 OOM 的发生;
kubectl describe
可以重点关注对象的 Event 事件信息;kubectl get events
查看 Event 事件列表;kubectl logs
查看应用程序的标准输出;kubectl exec
进入容器内,查看一些必要的信息或执行相关 debug 命令;kubectl port-forward
将服务转发至本地端口,方便调试;