【K8s任务】集群故障排查
参考:https://kubernetes.io/zh/docs/tasks/debug-application-cluster/debug-cluster/
列举集群节点
调试的第一步是查看所有的节点是否都已正确注册。
运行
kubectl get nodes
验证你所希望看见的所有节点都能够显示出来,并且都处于 Ready 状态。
为了了解你的集群的总体健康状况详情,你可以运行:
kubectl cluster-info dump
查看日志
到这里,挖掘出集群更深层的信息就需要登录到相关的机器上。下面是相关日志文件所在的位置。 (注意,对于基于 systemd 的系统,你可能需要使用journalctl)。
主控节点
- /var/log/kube-apiserver.log - API 服务器, 提供API服务
- /var/log/kube-scheduler.log - 调度器, 负责产生调度决策
- /var/log/kube-controller-manager.log - 管理副本控制器的控制器
工作节点
- /var/log/kubelet.log - kubelet,负责在节点运行容器
- /var/log/kube-proxy.log - kube-proxy, 负责服务的负载均衡
集群故障模式的一般性概述
下面是一个不完整的列表,列举了一些可能的出错场景,以及通过调整集群配置来解决相关问题的方法。
根本原因
VM(s) 关机
集群之间,或者集群和用户之间网络分裂
Kubernetes 软件本身崩溃
数据丢失或者持久化存储不可用(如:GCE PD 或 AWS EBS 卷)
操作错误,如:Kubernetes 或者应用程序配置错误
具体情况:
API 服务器所在的 VM 关机或者 API 服务器崩溃
结果
不能停止、更新或者启动新的 Pod、服务或副本控制器
现有的 Pod 和服务在不依赖 Kubernetes API 的情况下应该能继续正常工作
API 服务器的后端存储丢失
结果
API 服务器应该不能启动
kubelet 将不能访问 API 服务器,但是能够继续运行之前的 Pod 和提供相同的服务代理
在 API 服务器重启之前,需要手动恢复或者重建 API 服务器的状态
Kubernetes 服务组件(节点控制器、副本控制器管理器、调度器等)所在的 VM 关机或者崩溃
当前,这些控制器是和 API 服务器在一起运行的,它们不可用的现象是与 API 服务器类似的
将来,这些控制器也会复制为多份,并且可能不在运行于同一节点上
它们没有自己的持久状态
单个节点(VM 或者物理机)关机
结果
此节点上的所有 Pod 都停止运行
网络分裂
结果
分区 A 认为分区 B 中所有的节点都已宕机;分区 B 认为 API 服务器宕机 (假定主控节点所在的 VM 位于分区 A 内)。
kubelet 软件故障
结果
崩溃的 kubelet 就不能在其所在的节点上启动新的 Pod
kubelet 可能删掉 Pod 或者不删
节点被标识为非健康态
副本控制器会在其它的节点上启动新的 Pod
集群操作错误
结果
丢失 Pod 或服务等等
丢失 API 服务器的后端存储
用户无法读取API
等等
缓解措施:
措施:对于 IaaS 上的 VMs,使用 IaaS 的自动 VM 重启功能
缓解:API 服务器 VM 关机或 API 服务器崩溃
缓解:Kubernetes 服务组件所在的 VM 关机或崩溃
措施: 对于运行 API 服务器和 etcd 的 VM,使用 IaaS 提供的可靠的存储(例如 GCE PD 或者 AWS EBS 卷)
缓解:API 服务器后端存储的丢失
措施:使用高可用性的配置
缓解:主控节点 VM 关机或者主控节点组件(调度器、API 服务器、控制器管理器)崩馈
将容许一个或多个节点或组件同时出现故障
缓解:API 服务器后端存储(例如 etcd 的数据目录)丢失
假定你使用了高可用的 etcd 配置
措施:定期对 API 服务器的 PDs/EBS 卷执行快照操作
缓解:API 服务器后端存储丢失
缓解:一些操作错误的场景
缓解:一些 Kubernetes 软件本身故障的场景
措施:在 Pod 的前面使用副本控制器或服务
缓解:节点关机
缓解:kubelet 软件故障
措施:应用(容器)设计成容许异常重启
缓解:节点关机
缓解:kubelet 软件故障