2024年6月17日,我们的运维团队突然收到了一连串的告警。监控大屏上,代表着不同
Sealos
可用区的绿点中,零星地闪烁起了一两个红点。

“奇怪,
怎么有几台服务器突然 hang 住了?
” 值班的小辉皱起了眉头。

这次故障的诡异之处在于它的随机性。并非所有节点都受到影响,而是在不同可用区中,时不时地有个别服务器突然 “失联”。更令人不解的是,这些突然 hang 住的服务器资源都很充足,CPU、内存、磁盘 IO 等各项指标都处于健康水平。

“正常情况下它们不是都会自愈么?” 小谢问道。

“不会,我们已经观察了10分钟,还是没有恢复正常。” 小杨摇摇头,“这不太正常。”

常规手段失效,真凶难寻

面对这种间歇性但严重的故障,我们立即启动了应急预案。首先,
我们祭出了我们的 “传家宝”——dmesg 命令
,希望能从系统日志中找到一些蛛丝马迹。

然而,这次 dmesg 没有给我们任何有价值的信息。日志中看不到任何异常,服务器看起来完全正常,太诡异了。我们对比了之前遇到的所有已知问题,发现这次的情况与以往都不同,问题主要发生在
北京

广州
节点,但发生的概率较低,这更增加了排查的难度。

我们继续深入排查,检查了网络连接、系统负载、进程状态等多个方面,但所有指标都显示正常。

“等等,我发现了一个共同点!” 小李突然喊道,“
所有出问题的节点,内核版本都是 5.15.0-91-generic!

这个发现让我们眼前一亮,难道真凶就藏在这个特定的内核版本中?

意外的 “内核恐慌”

为了进一步确认猜测,我们联系了云服务提供商的技术支持团队。在他们的协助下,我们终于在串口日志中发现了关键线索。

就在系统 hang 住之前,日志中打印了一段特殊的堆栈信息:

这段堆栈信息清楚地显示,系统触发了一个内核 bug,导致了严重的内核恐慌。正常情况下,当发生内核 panic 时,系统应该会崩溃并进入 kdump 流程,将 Vmcore 写入磁盘,然后重新启动。但是,我们的系统却陷入了持续的 hang 状态,这显然不太对劲。

进一步分析 kdump 的日志,我们发现了问题的真相:

原来,kdump 在启动第二内核时出现了异常。我们怀疑,这可能是由于 crashkernel 配置的内存不足,导致第二内核启动失败,系统最终陷入了 hang 状态。

好家伙,
这不就像是消防车在赶往火灾现场的路上自己也出了故障。。。

内核升级大法

既然找到了问题的根源,接下来就是对症下药的时候了。我们的解决方案很直接——升级内核到已经修复了这个 bug 的最新版本:

apt install linux-image-5.15.0-112-generic

然而,事情并没有像我们预想的那样一帆风顺。在升级内核后的恢复过程中,我们又遇到了一个新的挑战——Cilium (我们使用的网络方案) 开始频繁重启,并报出了这样的错误:

Cilium 的小插曲

仔细查看 Cilium 的错误日志,我们发现问题出在一个叫做 “kube-ipvs0” 的网络接口上。这个 “kube-ipvs0” 设备其实是 Kubernetes 的 kube-proxy 组件在使用 IPVS 模式时创建的。

等等,我们的集群不是已经不再使用 kube-proxy 了吗?

经过一番排查后发现,原来
在我们迁移到 Cilium 网络方案的过程中,忘记了清理这个遗留的网络接口
。就是这个小小的疏忽导致了 Cilium 无法正确获取节点上的 IPv4 地址,进而引发了我们遇到的错误。

Cilium 源码中的相关片段:

// https://github.com/cilium/cilium/blob/8c7e442ccd48b9011a10f34a128ec98751d9a80e/pkg/datapath/loader/loader.go#L183
if option.Config.EnableIPv4Masquerade && bpfMasqIPv4Addrs != nil {
    ipv4 := bpfMasqIPv4Addrs[ifName] // nil checking is missing here
    opts["IPV4_MASQUERADE"] = uint64(byteorder.NetIPv4ToHost32(ipv4)) // ipv4 is nil
}

这段代码中,Cilium 尝试获取网络设备的 IPv4 地址,但是由于 “kube-ipvs0” 设备并不包含有效的 IP 地址,导致了空指针异常,最终就会导致 ip 进行类型转换时溢出:

func NetIPv4ToHost32(ip net.IP) uint32 {
        ipv4 := ip.To4()
        _ = ipv4[3] // Assert length of ipv4.
        return Native.Uint32(ipv4)
}

参考 issue:
https://github.com/cilium/cilium/issues/30746

解决方法很简单:删除这个多余的网络接口。

ip link delete kube-ipvs0

完成这个操作后,Cilium 终于恢复了正常,我们的服务也重新上线了。

总结

这次的故障给我们上了很重要的一课:
要保持警惕,不放过任何细节。

即使是一个看似无害的遗留网络设备,也可能成为系统稳定性的隐患。在进行重大架构变更时,我们需要更加细致地清理旧的组件和配置。

标签: none

添加新评论