ceph 集群异常导致K8S的pod异常

0    15    1

👉 本文共约2038个字,系统预计阅读时间或需8分钟。

一 背景

收到测试环境集群告警,登陆 K8s 集群进行排查。

二 故障定位

2.1 查看 Pod

查看 kube-system node2 节点 calico pod 异常。

图片

查看详细信息,查看node2节点没有存储空间,cgroup泄露。

图片

2.2 查看存储

登陆 node2 查看服务器存储信息,目前空间还很充足。

图片

集群使用到的分布式存储为ceph,因此查看ceph集群状态。

图片

目前查看到 ceph 集群异常,可能导致 node2 节点 cgroup 泄露异常,进行手动修复ceph集群。

三 操作

3.1 ceph修复

数据的不一致性(inconsistent)指对象的大小不正确、恢复结束后某副本出现了对象丢失的情况。数据的不一致性会导致清理失败(scrub error)。

CEPH 在存储的过程中,由于特殊原因,可能遇到对象信息大小和物理磁盘上实际大小数据不一致的情况,这也会导致清理失败。

图片

由图可知,pg编号1.7c 存在问题,进行修复。

  • pg修复

图片

进行修复后,稍等一会,再次进行查看,ceph 集群已经修复

图片

3.2 进行 Pod 修复

对异常pod进行删除,由于有控制器,会重新拉起最新的 Pod。

图片

查看 Pod 还是和之前一样,分析可能由于ceph异常,导致node2节点cgroup泄露,网上检索重新编译

Google 一番后发现存在的可能有:

  • Kubelet 宿主机的 Linux 内核过低 - Linux version 3.10.0-862.el7.x86_64
  • 可以通过禁用kmem解决

查看系统内核却是低版本

图片

3.3 故障再次定位

最后,因为在启动容器的时候 runc 的逻辑会默认打开容器的 kmem accounting,导致3.10内核可能的泄漏问题

在此需要对no space left的服务器进行 reboot重启,即可解决问题,出现问题的可能为段时间内删除大量的pod所致。

初步思路,可以在今后的集群管理汇总,对服务器进行维修,通过删除节点,并对节点进行 reboot 处理。

3.4 对 node2 节点进行维护

3.4.1 标记 node2 为不可调度

图片

3.4.2 驱逐 node2 节点上的 Pod

  • --delete-local-data 删除本地数据,即使emptyDir也将删除;
  • --ignore-daemonsets 忽略 DeamonSet,否则 DeamonSet 被删除后,仍会自动重建;
  • --force 不加 force 参数只会删除该 node 节点上的 ReplicationController, ReplicaSet,DaemonSet,StatefulSet or Job,加上后所有 pod 都将删除;

图片

目前查看基本 node2 的 pod 均已剔除完毕

本人提供Oracle、MySQL、PG等数据库的培训和考证业务,私聊QQ646634621或微信db_bao,谢谢!

图片

图片

此时与默认迁移不同的是,Pod 会先重建再终止,此时的服务中断时间=重建时间+服务启动时间+ readiness探针检测正常时间,必须等到1/1 Running服务才会正常。因此在单副本时迁移时,服务终端是不可避免的。

3.4.3 对 node02 进行重启

重启后 node02 已经修复完成。

对 node02 进行恢复

  • 恢复 node02 可以正常调度

图片

四 反思

后期可以对部署 K8s 集群内核进行升级。

集群内可能 Pod 的异常,由于底层存储或者其他原因导致,需要具体定位到问题进行针对性修复。

参考

https://juejin.cn/post/6969571897659015205

标签:

头像

小麦苗

学习或考证,均可联系麦老师,请加微信db_bao或QQ646634621

您可能还喜欢...

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

4 − 3 =

 

嘿,我是小麦,需要帮助随时找我哦
  • 18509239930
  • 个人微信

  • 麦老师QQ聊天
  • 个人邮箱
  • 点击加入QQ群
  • 个人微店

  • 回到顶部
返回顶部