一 背景

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

二 故障定位

2.1 查看 pod

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

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

2.2 查看存储

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

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

三 操作

3.1 ceph 修复

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

数据的不一致性（inconsistent）指对象的大小不正确、恢复结束后某副本出现了对象丢失的情况。数据的不一致性会导致清理失败（scrub error）。CEPH在存储的过程中，由于特殊原因，可能遇到对象信息大小和物理磁盘上实际大小数据不一致的情况，这也会导致清理失败。

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

• pg 修复

ceph pg repair 1.7c

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

3.2 进行 pod 修复

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

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

1. Google 一番后发现与https://github.com/rootsongjc/kubernetes-handbook/issues/313 这个同学的问题基本一致。存在的可能有，

• 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 为不可调度

kubectl cordon node02

3.4.2 驱逐 node2 节点上的 pod

kubectl drain node02 --delete-local-data --ignore-daemonsets --force

• --delete-local-data 删除本地数据，即使 emptyDir 也将删除；

• --ignore-daemonsets 忽略 DeamonSet，否则 DeamonSet 被删除后，仍会自动重建；

• --force 不加 force 参数只会删除该 node 节点上的 ReplicationController, ReplicaSet, DaemonSet,StatefulSet or Job，加上后所有 pod 都将删除；

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

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

3.4.3 对 node02 进行重启

重启后 node02 已经修复完成。

对 node02 进行恢复

• 恢复 node02 可以正常调度

kubectl uncordon node02

四 反思

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

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

参考链接

• https://blog.csdn.net/yanggd1987/article/details/108139436