原副标题：记一场可信赖的 K8S 排错两栖作战操作方式过程，庞克！
一 大背景
接到OWL软件产业监视系统，进占 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外泄，网上检索重新编译
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 为不可调度
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 的极度，由于底层储存或者其他原因引致，需要具体功能定位到问题展开针对性复原。
企业如何更好展开数字化转型？12月8日，DevOps 国际峰会 2022 · 北京站，您想了解的质量、效能、数字化转型，感兴趣的都在这里！
扫码，更多精彩
一文带你搞懂 CDN 的技术原理 “高效运维”公众号诚邀广大技术人员投稿
投稿邮箱：jiachen@greatops.net，或添加联系人微信：greatops1118。
点个“在看”，一年不宕机
