血崩之一个pod弄坏一个k8s集群

序言

何为血崩，就是一个小的东西造成了连锁反应，从而导致整个集群的崩溃，从而让服务停滞，就像大出血的那种。

在一个k8s集群中，在什么样的场景下会让一个集群崩溃呢？

雪崩

现在的业务都上云了，一般都是使用公有云的k8s集群，当你使用k8s集群的时候，一般会划分为不同的节点池，其实也就是将不同机型的机器打上了相同的标签，相当于进行分组的作用，这就是nodeslector的作用。

背景：在一个k8s集群中，有3个节点池，运行着不同的业务，pod数量大概在1000多个左右，突然某天收到告警，一堆机器呈现notready，而且所有的pod是在pending状态，还好，这是个非生产集群，没有那么紧急。

第一反应，先止血，既然是node notready，那么上来不管三七二十一，先进行扩容机器，例如当前节点池是5台机器，那么就再扩容5台，扩容之后可能会好，如果不好，那就提升规格进行扩容，例如原来是32C64G的机型，那么这次就扩容64C128G的机型，总有一种方法能止血，当node扩容进去之后，pod就逐渐运行平稳。

止血之后，就开始排查问题了，查看node的监控，发现每台机器的cpu基本到达100%，IO超限，机器不停的进行OOM，一台接着一台，最后导致所有的机器都变成了not ready状态，从而导致了机器的雪崩。

为什么知道扩容的时候，可能会有两次扩容呢？因为这种事情发生了好几次，然而每次都是扩容之后解决了，然后我们再缩容回去，然后再次发生，但是有的时候扩容没好，就尝试扩容更高的机型发现好了。

在我们的监控体系中，毕竟是非生产的，并没有进程级别的监控，一直怀疑是某个进程导致的，这个进程使用了太多的cpu或者内存或者磁盘，然后一台机器扛不住，就到了下一台，导致整个集群崩溃。再一次发生了时候，对机器安装了进程级别的监控，从而捕捉到了那个罪魁祸首。

监控，一般都不会依赖云平台的监控，自己部署了一个prometheus的pod来进行采集数据，在开始运行良好，而随着pod数量的增多，监控指标的增加，发现这个pod占用的资源越来越大，在生产环境中，扩容到了128C，发现还是不足，生产中已经下掉了，而在非生产中还是残留的，一直没关注，进程监控装上后，当再一次发生的时候，发现这个pod就是prometheus的pod。

历史残留的pod，而且最大的缺陷是这个pod没有设置limit，也就意味着它能吃光这个node的所有资源，从而将机器直接打死，即要大量的cpu，又要大量的内存，从而导致oom，也间接导致了磁盘的IO非常之高。

k8s设计原则之一：在k8s里面运行的所有pod必须强制设置limit，否则后患无穷。

在这个里面暴露出来的问题就是：

1 进程级别的监控也比较重要，但是这个需要消耗很高的成本，毕竟监控数据的存储费用很高，在关键时刻还是可以用一下。

2 故障的复现很重要，在出现故障的时候，所有的机器都无法登录，就感觉在hang死，因为机器都在OOM，内存不足，你啥命令都无法执行。

3 如果一个pod无法被限制，那么随着cpu和内存的使用，血崩是迟早的事儿，这不是运气，这是必然。

4 在生产环境中，止血很重要，想好应急预案，如何快速的恢复集群状态。

如果你在使用K8S，突然之间发了一个通知，说所有的pod必须加上request和limit来限制cpu和内存的使用，不用抗拒，因为的确是考虑到了雪崩的场景。曾几何时，我也曾质疑，直到这个故障的产生。

如果一个pod本身需要占用30C，110g的内存，如果节点池的机器小于这个规格，那么节点池就会所有机器一台接着一台崩溃。因为无法承载对应的cpu和内存，所有的进程都在被oom杀死，包括kubelet进程，从而导致node not ready。

oom导致还会导致IO hang住，并且cpu统计耗时中，system time耗时占用80%，不停的回收内存。

风言风语

在错误的土壤里苛求自己保持激情，一般结局都不太好。

在一个环境中，要考虑很多，无法改变的东西少想，能改变的东西多努力，找到努力的方向，迷茫也是正常的，走的路都是曲折的，而不是一直向上。

少一点焦虑，多一点思维连接的思考，而不是单一点的训练，你无法改变自身以外的东西，你能改变的只有你自身。

AI能解决好多技术问题，但是要让AI成为你的辅助工具，而不是让AI成为你的大脑，AI用多了，感觉脑子不够用了。