【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 软件故障
