【转载】浅谈大规模k8s集群关于events的那些坑

原文链接：一流铲屎官二流程序员【浅谈大规模k8s集群关于events的那些坑】

背景

随着k8s集群规模的增加，集群内的object数量也与日俱增，那么events的数量也会伴随其大量增加，那么当用户请求这些events的时候apiserver的负载压力就会增加，很可能造成apiserver处理请求延迟，首先需要分析一下请求events的几种方式：
1、用户通过kubectl list events
2、kubernetes-dashboard list events
3、admin用户直接在集群内list events
下面我会针对每一种情况提出一些可行的解决方案

一、用户通过kubectl list event

对于用户通过kubectl来list events，比如某个pod一直处于terminating的状态，用户需要排查原因，一般会describe该pod，然后可以查看到相应的异常events信息，这个操作就会list该pod的events，一般情况，k8s集群的events是存储在etcd中的，用户kubectl后会请求apiserver，然后apiserver会查询etcd，再将查询结果返回给用户。
优化方法：
首先我们可以考虑将events保存在其他地方，比如es等数据库，然后可以通过在k8s-proxy或者webhook对用户的event请求进行拦截，将用户的请求转至查询es或者其他数据库，然后再将查询结果转换为需要的方式返回给用户，这样一方面可以减轻apiserver的负载压力，而且还可以减轻etcd的压力，该方式经过验证是可性且有效的。

二、kubernetes-dashboard list events

在工作中，有段时间发现apiserver经常有延迟，经过监控分析发现dashboard list events的请求数量非常大，通过分析源码，发现dashboard中list其他object时，比如node，也会将该node上的所有pod的events都list一遍，这部分在dashboard界面上其实是没有显示的，我们可以考虑修改一下dashboard的代码，将这部分list events的请求禁止掉；另外可以和上面用户通过kubectl请求一样，我们将dashboard的请求拦截一下，转至查询es或者其他数据库。

三、直接在集群中list events

对于直接在集群中list events，目前还有比较好的解决方案，不过其实我们将上述两种情况解决后会有效地减轻apiserver的负载压力。https://blog.csdn.net/qq_40159308/article/details/114701703