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