cherryの技术文档

某电商平台生产环境的Kubernetes集群在促销活动期间突发大规模Pod驱逐，具体表现如下：Pod频繁重启：超过30%的Pod进入状态，核心服务（如订单支付、购物车）的Pod被反复驱逐。节点资源耗尽：多个Worker节点的内存使用率超过95%，kubelet日志持续输出警告。监控告警：业务影响：用户支付失败率从0.1%上升至15%，直接影响营收。关键日志：结论：节点内存不足触发kubelet的主动驱逐机制。步骤1：识别高内存消耗Pod发现：的Pod内存占用异常高。步骤2：检查Pod资源限制配置问题

K8S + 容器的云原生生态，改变了服务的交付方式，自愈能力和自动扩缩等功能简直不要太好用。有好的地方咱要夸，不好的地方咱也要说，真正的业务是部署于容器内部，而容器之外，又有一逻辑层 Pod。对于容器和 K8S 不怎么熟悉的人，一旦程序发生了问题，排查问题就是个头疼的问题。

该病毒有可能是挖矿类的病毒，占用机器资源进行任务，因此导致CPU使用率暴涨。同时，病毒较为狡猾，具有以下特点：1.隐藏自己的进程，无法通过TOP命令来发现。2.加入开机启动项，保证重启服务器后依然会生效。3.文件名随机，在不同机器上都不一样，增大了排查难度。目前，通过本文档记录的方法，可以有效清除病毒。已知经过处理后的机器未再出现重复中毒情况。

可以根据需求调整下 limit。如果容器的镜像本身或者容器启动后写入的文件存在 “i” 文件属性，此文件就无法被修改删除，而删除 Pod 时会清理容器目录，但里面包含有不可删除的文件，就一直删不了，Pod 状态也将一直保持 Terminating，kubelet 报错。podAntiAffinity: Pod 反亲和性，用于避免将某一类 Pod 调度到同一个地方避免单点故障，比如将集群 DNS 服务的 Pod 副本都调度到不同节点，避免一个节点挂了造成整个集群 DNS 解析失败，使得业务中断。