K8S实战——SIG PIPE问题造成kubernetes集群工作不正常的分析

前言

上家公司的微服务主要使用K8S部署和管理，由于创业公司资源有限，开发环境的所有K8S的节点都是虚拟机。在实际使用过程中，经常碰到集群节点运行一段时间在集群中显示为“NotReady”状态，然后由于K8S的高容错性，会将运行在该节点上的所有pod重新调度到其他“Ready”的节点上。如果遇上集群中同时有几个节点在集群中状态不正常，就会造成过多的pod发生漂移，然后到其他节点上与其他service产生资源竞争，进一步因为资源竞争造成节点挂点，集群进入恶性循环，可用的资源越来越少，造成能正常工作的service副本越来越少，最后造成服务不能正常提供。本文简单介绍了这个问题的发现过程，关于问题的解决需要借助集群pod状态，节点状态以及服务进程监控解决。后续会另写一篇博客介绍我们开发的一套集群监控。

一、 表象

最开始的时候集群监控、报警做得并不完善，过分依赖K8S的高可用，服务部署后，只要服务能正常提供则很少会主动检查集群运行状态。公司开发环境主要部署在内部虚拟机中，测试环境部署在阿里云上。
开发环境中，从上集群后，多次出现运行一段时间后K8S集群宕机的情况。最开始以为是因为集群节点台少（只有9个work node），而且work node和master都是跑在同一台物理机上的虚拟机，同时集群中已经跑了20来个services（都是双副本），资源过度使用造成。所以通过扩机器，同时开发环境所有service的副本数降为1。
改进后情况稍有好转，但是一段时间后还是会遇到集群大面积宕机的情况。这次仔细查看了集群状态，使用kubectl get po查看所有容器状态为pending或error等状态。查看容器描述，pending状态的容器提示“未找到匹配的selector”，error或crash off的容器提示“OOM killer”杀掉了容器进程，进而容器进入error，crash，restart状态。针对这两个问题表面上可能的原因有两个：

1. 调度器工作不正常，或者打有相应lable的节点kebelet不正常（我们所有的service通过label分组调度）
2. 资源过度使用，资源竞争造成一些service被O