现象
ES节点的pod跑了一段时间就偶尔会出现一次cpu throttle。
进而触发写入、查询队列的堆积，然后出现一些请求reject的情况。
图中可以看出来throttle的时间是25s，由于采集是1min一次，即1min内累计了 25s 的时间是被throttle的。
CPU限流（throttle）
k8s使用CFS（Completely Fair Scheduler，完全公平调度）限制负载的CPU使用率：
- CPU使用量的计量周期为100ms，100ms作为一个时间片；
- CPU limit决定每计量周期（100ms）内容器可以使用的CPU时间的上限；例如分配了1cpu，即当前周期（100ms）内，线程总共允许消耗100ms；以此类推，0.2 CPU = 20ms CPU时间每计量周期，2.5 CPU = 250ms CPU时间每计量周期；
- 24 CPU = 2400ms CPU时间每计量周期，当前周期（100ms）允许2400ms的CPU时间被消耗。
- 如果程序用了多个核，CPU时间会累加统计。（上面描述的 2400ms，指所有线程在周期内可消耗的累积值，重叠/并行的部分都需要叠加计算）
- 本周期内若容器的CPU时间用量达到上限，CPU限流开始，容器只能在下个周期继续执行；
分析
1.监控图粒度较大，1min采集1次，累计throttle时间25s，如果并发请求在100ms（周期）的开始就拿到了大量的时间，那后续时间就只能被阻塞。
2.并行（非并发）的请求如果占满了核心数，其余线程只能等待，一般不会出现，一般API主要是IO密集型。在一个周期内如果时间被消耗完，那所有线程都要阻塞，等到下一个周期开始执行。
3.容器环境io相互影响导致的wait，可能导致cpu消耗的情况
4.ES是个java程序，会有jit、gc，这两个都十分消耗CPU
结论
1.ES大部分请求还是IO密集型，磁盘推荐使用SSD。
2.核心应用尽量不做超分。
3.核心应用给足够的内存，防止频繁GC、频繁缺页中断。
4.throttle的问题几乎无法彻底解决，只能尽可能调优。根据业务请求的并发来调整cpu limit（或request）
