[转帖]记一次靠谱的 K8S 排错实战过程,硬核!

一次,k8s,排错,实战,过程,硬核 · 浏览次数 : 0

小编点评

**故障分析** **2.1 Pod 查看 kube-system node2 节点 calico pod 异常** * 异常原因:node2 节点没有存储空间,cgroup 泄露。 **2.2 存储登陆 node2 查看服务器存储信息** * 存储空间充足。 **3.1 ceph修复ceph 集群异常** * 由于 pg编号1.7c 存在问题,导致清理失败。 **3.2 Pod 修复对异常pod进行删除** * 容器重新拉起最新的 Pod。 **3.4 修复节点** **3.4.1 不可调度** * 停止所有与 node2 节点的 pod。 **3.4.2 驱逐 Pod** * 删除本地数据。 **3.4.3 强制删除** * 删除该节点上的所有 pod。 **3.4.4 恢复** * 重新启动 node2 节点。 **3.4.5 重新绑定 Pod** * 重启容器,并确保它们从新的 pod 中恢复。 **结论** 由于 node2 节点 cgroup 泄露,导致ceph 集群异常,需要进行修复。修复步骤包括: 1. 确保 node2 节点有足够的存储空间。 2. 处理 pg编号1.7c 问题。 3. 对 node2 节点进行维护和恢复。

正文

http://blog.itpub.net/31545813/viewspace-2925035/

 

一 背景

收到测试环境集群告警,登陆 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 集群已经修复

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 均已剔除完毕

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

3.4.3 对 node02 进行重启

重启后 node02 已经修复完成。

对 node02 进行恢复

恢复 node02 可以正常调度

四 反思

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

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

与[转帖]记一次靠谱的 K8S 排错实战过程,硬核!相似的内容:

[转帖]记一次靠谱的 K8S 排错实战过程,硬核!

http://blog.itpub.net/31545813/viewspace-2925035/ 一 背景 收到测试环境集群告警,登陆 K8s 集群进行排查。 二 故障定位 2.1 查看 Pod 查看 kube-system node2 节点 calico pod 异常。 查看详细信息,查看nod

[转帖]记一次靠谱的 K8S 排错实战过程,硬核!

http://blog.itpub.net/31545813/viewspace-2925035/ 一 背景 收到测试环境集群告警,登陆 K8s 集群进行排查。 二 故障定位 2.1 查看 Pod 查看 kube-system node2 节点 calico pod 异常。 查看详细信息,查看nod

[转帖]记一次线上Oracle连接耗时过长的问题

https://www.cnblogs.com/changxy-codest/p/15670495.html 问题现象 1、远程Oracle数据库通过IP:PORT/SERVICE_NAME连接 2、应用服务通过Docker容器部署,访问Oracle联通性测试接口,需要50s左右才能返回连接成功;

[转帖]记一次flannel网络调整

https://www.jianshu.com/p/a772e4b951f2 背景 最近给一个子公司部署一套k8s集群,集群搭建完之后有几个新需求需要新增几个node节点,在新增节点时发现添加失败,经过查询发现是网络规划问题导致。 flannel启动失败,报错信息如下:Error registeri

[转帖]记一次使用nacos2踩到的坑

https://cloud.tencent.com/developer/article/2077110?areaSource=104001.26&traceId=7WZNP412yK3vh7ebw4th0 前言 本文素材来源朋友学习nacos2.1.1踩到的坑。直接上正菜 坑点一:出现端口被占用 因

[转帖]记一次压测引起的nginx负载均衡性能调优

https://xiaorui.cc/archives/3495 这边有个性能要求极高的api要上线,这个服务端是golang http模块实现的。在上线之前我们理所当然的要做压力测试。起初是 “小白同学” 起头进行压力测试,但当我看到那压力测试的结果时,我也是逗乐了。 现象是,直接访问Golang

[转帖]记一次使用gdb诊断gc问题全过程

https://www.cnblogs.com/codelogs/p/17092141.html 简介# 上次解决了GC长耗时问题后,系统果然平稳了许多,这是之前的文章《GC耗时高,原因竟是服务流量小?》然而,过了一段时间,我检查GC日志时,又发现了一个GC问题,如下:从这个图中可以发现,我们GC有

[转帖]记一次vcsa6修复过程

一、 某天发现一台vmware vCenter Server Appliance services 6偶尔能登陆了,但极不稳定,连shell都偶尔能进...... 然后利用各种手段想方设法进到shell里,这是必须的,否则白谈.... 首先查看空间:df -h,发现/和/storage/log都用了

[转帖] 记一次使用gdb诊断gc问题全过程

记一次使用gdb诊断gc问题全过程 原创:扣钉日记(微信公众号ID:codelogs),欢迎分享,转载请保留出处。 简介# 上次解决了GC长耗时问题后,系统果然平稳了许多,这是之前的文章《GC耗时高,原因竟是服务流量小?》然而,过了一段时间,我检查GC日志时,又发现了一个GC问题,如下:从这个图中可

[转帖]记一次sst文件损坏修复过程

https://tidb.net/blog/54e388c8 【2023-07-14 14:26:28】应用系统报警删除数据失败,查看日志报Region is unavailable,同时企业微信群也收到数据库告警信息。 二、问题定位 首先查看集群进程都正常,登录tidb dashboard查看日志