这是我参与更文挑战的第3天,活动详情查看: 更文挑战
一 背景
收到测试环境集群告警,登陆K8s集群进行排查。
二 故障定位
2.1 查看pod
查看kube-system node2节点calico pod异常
2.2 查看存储
- 登陆node2查看服务器存储信息,目前空间还很充足
三 操作
3.1 ceph修复
目前查看到ceph集群异常,可能导致node2节点cgroup泄露异常,进行手动修复ceph集群。
数据的不一致性(inconsistent)指对象的大小不正确、恢复结束后某副本出现了对象丢失的情况。数据的不一致性会导致清理失败(scrub error)。
CEPH在存储的过程中,由于特殊原因,可能遇到对象信息大小和物理磁盘上实际大小数据不一致的情况,这也会导致清理失败。
ceph pg repair 1.7c复制代码
3.2 进行pod修复
对异常pod进行删除,由于有控制器,会重新拉起最新的pod
3.3 故障再次定位
最后,因为在启动容器的时候runc的逻辑会默认打开容器的kmem accounting,导致3.10内核可能的泄漏问题
在此需要对no space left的服务器进行 reboot重启,即可解决问题,出现问题的可能为段时间内删除大量的pod所致。
初步思路,可以在今后的集群管理汇总,对服务器进行维修,通过删除节点,并对节点进行reboot处理
3.4 对node2节点进行维护
3.4.1 标记node2为不可调度
kubectl cordon node02复制代码
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都将删除;
kubectl uncordon node02复制代码
四 反思
- 后期可以对部署k8s 集群内核进行升级。
- 集群内可能pod的异常,由于底层存储或者其他原因导致,需要具体定位到问题进行针对性修复。