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. 性能压测&故障演练
若有收获，就点个赞吧