本篇文档是介绍集群故障排查的;我们假设对于你碰到的问题,你已经排除了是由应用程序造成的。
对于应用的调试,请参阅应用故障排查指南。
你也可以访问troubleshooting document来获取更多的信息。
调试的第一步是查看所有的节点是否都正确的注册。
运行
kubectl get nodes
接下来,验证你的所有节点都能够显示出来,并且都处于Ready
状态。
现在,挖掘出集群更深层的信息就需要登录到相关的机器上。下面是相关log文件所在的位置。
(注意,对于基于systemd的系统,你可能需要使用journalctl
)
下面是一个不完整的列表,列举了一些可能出错的场景,以及通过调整集群配置来解决相关问题的方法。
根本原因:
具体情况:
Apiserver 后端存储丢失
Kubernetes服务组件(节点控制器,副本控制器,调度器等等)所在的VM关机或者崩溃
单个节点(VM或者物理机)关机
网络分裂(Network partition)
Kubelet软件故障
集群操作错误
缓解措施:
措施:对于IaaS上的VMs,使用IaaS的自动VM重启功能
措施: 对于具有apiserver+etcd的VM,使用IaaS提供的可靠的存储(例如GCE PD或者AWS EBS卷)
措施:使用(实验)高可用性的配置
措施:定期的对apiserver的PDs/EBS卷进行快照
措施:在pods的前面使用副本控制器或服务
措施:应用(容器)设计成容许异常重启
措施:多个独立的集群(并且避免一次性地对所有的集群进行有风险性的修改)