关键词
- kubelet 、pod持久化
- metrics/vlalphal容器
-
kube-controller、apiserver
一、故障现象
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类似集群问题故障时，确实需要关注的点会有很多，有的是自上而下的检查，有的会是自下而上的检查。自上而下的方式，有时可能会很快发现组件问题直接解决了底层故障现象，但检查过程中，多个组件多个日志，稍不注意可能就错过了关键信息；并且容易带着不明确的意识（不确认怀疑哪个服务有问题，检查的可能不是很仔细）来检查各类服务。自下而上的方式，有一种拨开云雾见日出的感觉，一层一层来排除确认，最终定位到直接原因，对整个故障原因会有比较直接的因果关系。但这种方式通常处理时间可能会拖的比较长。所以处理类似故障，可以根据情况来选择哪种方式，但建议最优的方式，是可以先仔细（仔细、仔细，重要的事情说三遍）的自上而下的方式检查一遍，如果确实找不到问题所在，再来自下而上再走一遍。
显然这次故障问题还是前人的一系列骚操作留下来的坑，故障原因分析下来比较简单。不过整个过程处理下来还是有所收获的，经验值又增加了一点，记录一下，日后可以参考。
最后，如果觉得本文对你有帮助，欢迎点赞、收藏、评论！文章来源：https://www.toymoban.com/news/detail-785934.html
There are many things that can not be broken！文章来源地址https://www.toymoban.com/news/detail-785934.html
到了这里，关于K8S容器的一则故障记录的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
