记录 Kubernetes 排错实战

背景
ASP站长网收到测试环境集群告警，登陆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这个同学的问题基本一致。存在的可能有：
 
Kubelet宿主机的Linux内核过低 - Linux version 3.10.0-862.el7.x86_64
可以通过禁用kmem解决
查看系统内核却是低版本。
 
 
 
故障再次定位
 
最后，因为在启动容器的时候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
--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服务才会正常。因此在单副本时迁移时，服务终端是不可避免的。
 
对node02进行重启
 
重启后node02已经修复完成。
 
对node02进行恢复：
 
恢复node02可以正常调度。
 
kubectl uncordon node02
 
 
反思
后期可以对部署Kubernetes集群内核进行升级。