作者:kaliarch 2021-11-11 16:14:04
云计算 数据的不一致性(inconsistent)指对象的大小不正确、恢复结束后某副本出现了对象丢失的情况。数据的不一致性会导致清理失败(scrub error)。
收到测试环境集群告警,登陆Kubernetes集群进行排查。
查看Pod
查看kube-system node2节点calico pod异常。
查看详细信息,查看node2节点没有存储空间,cgroup泄露。
查看存储
登陆node2查看服务器存储信息,目前空间还很充足。
集群使用到的分布式存储为Ceph,因此查看Ceph集群状态。
Ceph修复
目前查看到Ceph集群异常,可能导致node2节点cgroup泄露异常,进行手动修复Ceph集群。
数据的不一致性(inconsistent)指对象的大小不正确、恢复结束后某副本出现了对象丢失的情况。数据的不一致性会导致清理失败(scrub error)。
Ceph在存储的过程中,由于特殊原因,可能遇到对象信息大小和物理磁盘上实际大小数据不一致的情况,这也会导致清理失败。
数据的不一致性(inconsistent)指对象的大小不正确、恢复结束后某副本出现了对象丢失的情况。数据的不一致性会导致清理失败(scrub error)。
Ceph在存储的过程中,由于特殊原因,可能遇到对象信息大小和物理磁盘上实际大小数据不一致的情况,这也会导致清理失败。
由图可知,pg编号1.7c 存在问题,进行修复。
pg修复:
- ceph pg repair 1.7c
进行修复后,稍等一会,再次进行查看,Ceph集群已经修复。
进行Pod修复
对异常Pod进行删除,由于有控制器,会重新拉起最新的Pod。
查看Pod还是和之前一样,分析可能由于Ceph异常,导致node2节点cgroup泄露,网上检索重新编译。
Google一番后发现与https://github.com/rootsongjc/kubernetes-handbook/issues/313这个同学的问题基本一致。存在的可能有:
查看系统内核却是低版本。
故障再次定位
最后,因为在启动容器的时候runc的逻辑会默认打开容器的kmem accounting,导致3.10内核可能的泄漏问题。
在此需要对no space left的服务器进行reboot重启,即可解决问题,出现问题的可能为段时间内删除大量的Pod所致。
初步思路,可以在今后的集群管理汇总,对服务器进行维修,通过删除节点,并对节点进行reboot处理。
对node2节点进行维护
标记node2为不可调度
- kubectl cordon node02
驱逐node2节点上的Pod
- kubectl drain node02 --delete-local-data --ignore-daemonsets --force
目前查看基本node2的Pod均已剔除完毕。
此时与默认迁移不同的是,Pod会先重建再终止,此时的服务中断时间=重建时间+服务启动时间+readiness探针检测正常时间,必须等到1/1 Running服务才会正常。因此在单副本时迁移时,服务终端是不可避免的。
对node02进行重启
重启后node02已经修复完成。
对node02进行恢复:
恢复node02可以正常调度。
- kubectl uncordon node02
后期可以对部署Kubernetes集群内核进行升级。
集群内可能Pod的异常,由于底层存储或者其他原因导致,需要具体定位到问题进行针对性修复。
原文链接:https://juejin.cn/post/6969571897659015205
分享名称:记一次Kubernetes排错实战
网址分享:http://www.shufengxianlan.com/qtweb/news10/328360.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联