临时存储超限导致的Pod集体驱逐故障排查

背景

        在某天的下午，我们突然收到告警，埋点服务的接口报大量502，持续了大约2分钟，然后就自动恢复了，于是便开始排查问题所在。

排查过程

        在上面的故障现象中，我们首先怀疑是微服务出现了问题，因此进行了以下排查：

        1.登录KubeSphere控制台后，我们发现埋点服务的所有Pod副本都是刚刚重新生成的，这意味着Pod副本集体挂了，为什么会集体挂掉呢？

        2.接着，通过查看K8s事件日志，我们发现这些Pod都是由于临时存储超限而被驱逐的，而且时间点非常接近。然而，我们已经配置了PDB和优雅停机机制，为什么这些措施没有生效呢？

        尽管我们已经找到了故障的原因，但仍需进一步分析以解决上述疑惑。请继续往下看。

问题分析结果

        经过一番分析和了解，我们终于找到答案，解决上述的困惑，具体如下：

为什么Pod副本几乎同时被驱逐？

因为程序会往Pod的/tmp目录写临时数据，由于密集产生临时文件导致临时存储（ephemeral-storage ）使用超限，导致Pod被驱逐（Evicted）。

为什么PDB和优雅停机不生效？

在非自愿中断的情况下，例如节点硬件故障或由于资源压力导致 kubelet 驱逐 Pod，则不受 PDB 控制，所以才导致此次驱逐事件业务感知较大。我根据Pod驱逐是否遵循PDB和优雅停机的主要情况进行梳理，如下图

ephemeral storage知识点

        在 K8s 中，ephemeral storage 是指在 Pod 生命周期内可用的临时存储空间。这些存储空间在 Pod 被删除或重新调度时会被清空。ephemeral storage 包括以下几种类型的临时存储：

Container Writable Layer：容器可写层，用于存储容器中产生的临时文件、缓存等。

Log Storage：K8s 会将容器的标准输出和标准错误日志写入到节点上的日志文件中。这些日志文件也被视为 ephemeral storage 的一部分。

EmptyDir Volume：EmptyDir的默认存储类型为磁盘，属于ephemeral storage，但如果将EmptyDir的medium定义为Memory，则EmptyDir的大小将受Memory Limit限制，如下是官方的文档截图：

结语

        通过此次故障的排查和分析，不仅让我们深入了解Pod的驱逐场景，也让我们更加重视临时存储（ephemeral storage）的使用情况，并迅速补充了对Pod临时存储的监控。本次分享就到这里，谢谢！

 欢迎订阅我的公众号「SRE运维手记」，可扫下方二维码，或者微信搜“SRE运维手记”