一、故障现象

    XXX反馈说某某业务服务异常，无法启动，需要进行协助排查。经常会接到这样一个需求，一开始无法清楚知道具体什么问题，需要跟一线运维人员详细做沟通，了解故障问题的细节。

    根据一线运维人员的反馈，是有一套5节点单master的k8s集群，其中一个node异常重启后，导致上面一个关键mysql服务pod（有持久化存储）无法启动，从而影响到整体业务。一线检查集群反馈服务状态都正常。

二、分析过程

     1、单pod问题？

       从当前情况看，表面现象是说mysql的pod无法启动，也没法切换。但是不是只有这一个问题呢？一开始怀疑是不是mysql做了标签绑定，只能在该node运行，检查一番并没有。

     2、单node问题？

      既然不是单单mysql容器问题，那会不会是这个故障node的问题？检查node各个服务状态和日志，看起来也没什么异常。既然日志没异常，手动做些测试看看。

       1）调度一个非持久化的pod到该节点----发现也无法调度到该节点上，表明node层确实有些问题

       2）在故障node手动创建个docker，可以运行---证明docker容器本身没问题

      3、集群问题

      单node无法调度上去，可能是node本身问题，但node相关日志检查又都无异常。怀疑是上一层集群侧有问题。先测试验证下，从其他节点调度容器或者新建容器，发现都无生产。证明了还是集群侧有问题。

    开始着重排查集群的问题，对集群各个组件进行逐一排查。PS：再温习下k8s各个组件作用

kube-apiserver ： 提供了资源的增、删、改、查等操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；

kube-scheduler ：负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；

kube-controller-manager：负责维护集群的状态，资源对象的自动化控制中心，比如故障检测、自动扩展、滚动更新、服务帐户和令牌控制器等；

etcd ：k8s的所有资源对象的数据都保存在etcd中；

 1）从前面现象看，调度出了问题，和schedule有关?检查一番schedule没发现啥。

 2)  其他几个组件服务也要检查看看，第一个看到etcd的日志有很多reject connection的错误，有些可疑，开始从这个方向排查，ntp时间、证书、配置等等一一检查，发现也不是这个问题导致。

 3）检查apiserver，日志中有个metrics资源报错。

memcache.go:couldn't get resource list for metrics/vlalphal: the server could not find the requested resource。

 4）检查controller，日志中看发现服务一直在重启中，且也有metric相关报错。

controllermanager.go:174] error starting controllers: failed to discover resources: unable to retrieve 
the complete list of server APIs: metrics/v1alpha1: the server could not find the requested resource

5）都指向了metric，那就检查这个pod的日志，发现有连不上其中一个节点kubelet的错误。

kubectl get pod -n kube-system -owide
kubectl logs **metric** -n kube-system

6）登到这个节点检查kubelet服务，确实服务报错没起起来，排查一通。发现这个节点上也有controller、api、schedule服务启动，等等，不是说单master架构么？？？怎么这里也有组件服务，后来问一线运维，这个原来是之前部署时留的坑，服务自启动没关闭，导致主机重启后服务自己启动起来，手动把这些服务关闭掉，再重启kubelet，咋还是不行？再来各种检查，发现kubelet的配置文件没有，一线运维之前做了文件备份，但原配置文件居然不在，不知道是不是用的MV命令而不是CP命令......；重新cp了下，再来重启kubelet，kubelet好了。

7）既然kubelet好了，再去看看metric容器，之前连不上的错误没了，但是还是有一堆报错。索性重启下这个pod，然后等了几分钟，集群恢复了，应用啥啥都好使了，game over！

三、经验总结

    在处理k8s类似集群问题故障时，确实需要关注的点会有很多，有的是自上而下的检查，有的会是自下而上的检查。自上而下的方式，有时可能会很快发现组件问题直接解决了底层故障现象，但检查过程中，多个组件多个日志，稍不注意可能就错过了关键信息；并且容易带着不明确的意识（不确认怀疑哪个服务有问题，检查的可能不是很仔细）来检查各类服务。自下而上的方式，有一种拨开云雾见日出的感觉，一层一层来排除确认，最终定位到直接原因，对整个故障原因会有比较直接的因果关系。但这种方式通常处理时间可能会拖的比较长。所以处理类似故障，可以根据情况来选择哪种方式，但建议最优的方式，是可以先仔细（仔细、仔细，重要的事情说三遍）的自上而下的方式检查一遍，如果确实找不到问题所在，再来自下而上再走一遍。

    显然这次故障问题还是前人的一系列骚操作留下来的坑，故障原因分析下来比较简单。不过整个过程处理下来还是有所收获的，经验值又增加了一点，记录一下，日后可以参考。