如何增强K8s集群apiserver的健壮性

kube-apiserver作为k8s平台所有请求的入口，一旦kube-apiserver不可用，整个k8s就不可用。因此保障kube-apiserver的健壮性显得尤为重要。

我们可以从部署架构、自身性能、监控报警、自动降级等维度保证kube-apiserver的健壮性。

1. 部署架构

• kube-apiserver部署多个实例，前面利用slb负载均衡
• 设置maxSurge=3升级kube-apiserver，减少升级带来的性能抖动

2. 自身性能

• list cache优化

list接口优先读缓存，减少对etcd的压力，避免etcd压力过大引起kube-apiserver雪崩；

• index优化

给常用的资源(pods/stateful)添加index，加速list效率；

• bookmark优化

通过bookmark，watch client可以及时获取apiserver的版本信息，避免watch重连时拉取全量数据；

• cache not ready

当kube-apiserver的cache不ready时，kube-apiserver不对外提供服务，避免etcd被击穿，引起系统雪崩；

• kubelet定时重连

kubelet定时重连kube-apiserver，尽量让多个kube-apiserver负载均衡

• 内存分页读优化

避免一次返回太大的数据结构，造成网络堵塞，cpu和内存抖动

3. 监控报警

除了kube-apiserver自身的性能优化，我们对kube-apiserver做全面的监控，这样才能对kube-apiserver运行情况了如指掌，同时对异常情况做报警，及时介入干预，防止系统出现雪崩。

• 基于prometheus的监控报警

目前基于kube-apiserver已暴露的指标，我们已经可以对kube-apiserver的cpu负载、memory使用、QPS、RT延时、etcd访问延时做到详细的监控报警，只要上述指标异常，立刻可以报警至钉钉群，owner及时进行处理。

• 基于sls日志的监控报警

有部分指标，比如少量pod的全量list请求，就会造成kube-apiserver的内存抖动。通过prometheus我们无法及时发现，我们可以基于sls日志做监控和报警。

4. 自动降级

• non-mutating inflight和mutating infight

通过动态修改这两个参数控制kube-apiserver可以接受的请求数，当系统负载过高时，降低这两个参数即可。

根据内存使用大小，自动调节这两个参数大小？

• 用户资源多维度限流

通过该机制，可以控制每个用户、每种资源、每种verb能提供的qps。这样紧急情况下，可以禁用某些用户、某些资源的访问。

5. 性能压测&故障演练

若有收获，就点个赞吧