ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

k8s故障检测与自愈(一)

2022-01-14 11:02:00  阅读:201  来源: 互联网

标签:node kernel kubernetes 运维 故障 自愈 k8s 节点


微信公众号:运维开发故事,作者:夏老师

组件故障

组件故障可以认为是节点故障的子类,只是故障来源是K8S基础组件的一部分。

DNS故障:6个DNS Pod中的2个出现无法解析外部DNS名称的情况。后果是大量线上业务因域名解析。

CNI故障:少数几个节点的容器网络和外部断开,节点访问自身的Pod IP没有问题,但是其它节点无法访问故障节点的Pod IP。这种情况下,Pod本机的健康检查无效,导致故障实例持续存在,一定比例的业务请求失败。

kubenurse会对ingress、dns、apiserver、kube-proxy进行网络探测。

可以参考:

使用KubeNurse进行集群网络监控

乔克,公众号:运维开发故事使用KubeNurse进行集群网络监控

节点故障

  • 硬件错误: CPU/Memory/磁盘故障

  • kernel问题: kernel deadlock/corrupted file systems

  • 容器运行时错误: Docker假死

  • 基础设施服务故障: NTP故障

node-problem-detector

  • 根源: 在kubernetes集群上,通常我们只是管制集群本身以及容器的稳定运行。但是这些稳定性都是强依赖节点node的稳定的。可是node的管理,在kubernetes是比较弱的,因为可能对于kubernetes的初始设计来说,这些应该是IaaS的事。但是随着kubernetes的发展,它越来变成了一个操作系统,它管理的内容将越来越多,所以对于node的管理也将纳入kuberntes里管理。所以延伸出了node problem detector这个项目。

  • Kubernetes支持两种上报机制:

1、NodeCondition(节点状况): 这是指永久性的错误,它将造成pod无法在这个节点运行。这个节点状况只有在节点重启后才会被重置

2、Event(事件): 影响节点的临时性问题,但是它是对于系统诊断是有意义的。NPD就是利用kubernetes的上报机制,通过检测系统的日志(例如centos中journal),把错误的信息上报到kuberntes的node上。图片故障节点上的事件,会记录在宿主机的某些日志中。这些日志(例如内核日志)中噪音信息太多,NPD会提取其中有价值的信息,可以将这些信息报送给Prometheus,也会生成离线事件。这些信息可以推送到企业微信,人工处理。也可以对应到自愈系统的方法库,自动恢复。在裸金属K8S集群中,由于缺乏基础设施的支撑,自动扩充节点可能无法实现,只能通过更加精细的自动化运维,治愈节点的异常状态。图片以CNI故障为例,可能的治愈流程如下:

  1. 查询运维方法库,如果找到匹配项,执行对应的运维动作

  2. 如果上述步骤无效,尝试删除节点上负责CNI的Pod,以重置节点的路由、Iptables配置

  3. 如果上述步骤无效,尝试重启容器运行时

  4. 告警,要求运维人员介入

部署NPD实践你需要有一个k8s集群,必须有1个以上的worker节点。大家可以参考https://github.com/kubernetes/node-problem-detector。

主要参数:
--prometheus-address: 默认绑定地址127.0.0.1,如果需要推送给promethues,需要修改。
--config.system-log-monitor: 节点问题检测器将为每个配置启动一个单独的日志监视器.案例: config/kernel-monitor.json。
--config.custom-plugin-monito: 节点问题检测器将为每个配置启动一个单独的自定义插件监视器。案例: config/custom-plugin-monitor.json

将代码克隆到本地,按照自己的需求更改deployment文件中的DaemonSet,执行以下内容:

创建ConfigMap:
kubectl create -f node-problem-detector-config.yaml
创建DaemonSet:
kubectl create -f node-problem-detector.yaml

如何验证NPD捕获信息这部分,可以在测试集群的node几点上做。

sudo sh -c "echo 'kernel: BUG: unable to handle kernel NULL pointer dereference at TESTING' >> /dev/kmsg"
可以在kubectl describe nodes x.x.x.x 中看到KernelOops事件的告警。
sudo sh -c "echo 'kernel: INFO: task docker:20744 blocked for more than 120 seconds.' >> /dev/kmsg"
可以在kubectl describe nodes x.x.x.x 中看到DockerHung事件的告警。

如果事件告警接到了promethues,可以配置策略,发送到微信。

- END -

公众号:运维开发故事

github:https://github.com/orgs/sunsharing-note/dashboard

爱生活,爱运维

如果你觉得文章还不错,就请点击右上角选择发送给朋友或者转发到朋友圈。您的支持和鼓励是我最大的动力。喜欢就请关注我吧~

图片

扫码二维码

关注我,不定期维护优质内容

温馨提示

如果你喜欢本文,请分享到朋友圈,想要获得更多信息,请关注我。

                                          ........................

标签:node,kernel,kubernetes,运维,故障,自愈,k8s,节点
来源: https://blog.csdn.net/wanger5354/article/details/122485116

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有