月度归档： 2020 年 10 月

现象描述 pod一直处于terminating状态，或者很久才能删除，内核日志中持续打印unregister_netdevice: waiting for XXX to become free. Usage count = 1。 故障诊断 经过定位和排查，定位到是内核的一个bug导致网络设备无法删除。具体参考https://github.com/torvalds/linux/commit/ee60ad219f5c7c4fb2f047f88037770063ef785f。 另外在github的k8s的issues里也有该bug的相关讨论。有人给出了付现这个问题的方式，以及验证上面提到的修复方法是否有效。下面是按照他给出的方案做的复现和验证。具体可参考https://github.com/moby/moby/issues/5618#issuecomment-549333485。 问题排查 从kubelet内核日志来看是在删除pod的网卡设备时因为内核的引用计数bug，导致无法删除。后续对网卡信息的查询和再次删除操作应该也会导致超时失败（根据日志推断，暂时还未在代码中找到对应调用，线上环境也没法重启调整日志级别和调试）。 首先需要看一个概念：PLEG。 PLEG (pod lifecycle event generator) 是 kubelet 中一个非常重要的模块，它主要完成以下几个目标： 从 runtime 中获取 pod 当前状态，产生 pod lifecycle events 从 runtime 中获取 pod 当前状态，更新 kubelet pod cache 接下来分析一下造成问题的原因应该是k8s的PLEG在同步pod信息时，可能要查询网卡详情（ip地址），由于内核bug导致超时，致使syncLoop中每执行一次遍历的时间过长（4分钟左右），因此新建pod和删除pod的时候，node上的信息和server上的信息更新不及时。用busybox测试创建和删除时，通过docker ps可以看到响应容器很快就可以启动或删除掉。 从图中可以看到该日志：Calico CNI deleting device in netns /proc/16814/ns/net这条。这是在pod执行删除是产生的。在正常情况下后面会有删除完成的日志信息，如下图： 但上面的日志里的无此信息，并且10s后打印了unregister_netdevice xxx的日志。这里是触发了内核bug。通过ps aux | grep calico也可以看到在对应时间有一个calico进程启动去执行操作，目前这个进程还在（10.209.33.105），这里估计k8s也有bug，没有wait pid，导致calico成为僵尸进程。 下图是kubelet日志。其中的PLEG is not healthy日志也是在对应的时间点出现。 问题本地复现 要在本地复现这个问题，首先需要给内核打补丁来协助复现。 diff --git a/net/ipv4/route.c b/net/ipv4/route.c index a0163c5..6b9e7ee…