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. 性能壓測&故障演練
若有收獲，就點個贊吧