从事云原生底层研发近3年，经历了大大小小的容器集群故障。记录一下容器集群稳定性建设心得。
首先，集群状态可以分为变更状态 + 正常运行状态。
0. 监控指标+告警的完善
无论是变更时，还是平时。监控指标的完善必不可少，通过监控指标可以提前发现异常情况。apisever, kcm, kubescheduler, kubelet, etcd组件的监控指标必须到位
https://docs.datadoghq.com/integrations/kube_apiserver_metrics/
https://docs.datadoghq.com/integrations/kube_controller_manager/
1. 变更状态
变更状态是人为发起的，因为组件更新，bug修复，功能上线等需求而对集群的apiserver, kcm, kubelet, etcd等等核心组件进行的主动变更。
这个过程保证集群的稳定性，个人认为核心是变更流程，变更规范的建设。
（1）对于核心组件（apiserver, kubelet, kcm等）变更而言，一定要规范变更流程，千万不要马虎。
例如，某个node节点需要调整一个kubelet参数，这个时候运维同学A手动调整，将Kubelet重启。但是由于kcm开启了污点驱逐，导致这台kubelet上所有pod全部被驱逐，业务方找上门来了。。。
所以kubelet变更流程就应该为：
停止kcm -> 停止kubelet -> 修改配置参数 -> 启动kubelet -> kubectl 观察nodeReady后启动kcm
（2）稳态环境的搭建
搭建一个和线上业务方版本一直的k8s集群，模拟业务方跑一下代表性的pod和svc（例如设置就绪探针，开启了驱逐，使用了volume等等）
实现稳态告警，稳态环境的svc 访问超时，访问不同，pod状态异常都需要告警出来
自动化的反复变更测试
提前模拟业务变更。比如在变更kubelet之前，通过将稳态环境的版本设置为线上一致，然后通过反复自动变更，观察是否有异常，然后再迭代完善变更流程
（3）变更过程小批量灰度进行，并时刻观察监控指标是否异常
在大规模集群中，特别要注意kubelet或者其他deamonset组件的变更。ds/kubelet组件大部分场景都是对集群的某些资源进行list-watcher。这个时候大规模的更新可能会给apiserver一瞬间造成巨大的压力。所以这类组件的变更一点要注意按批次，小规模变更
2. 正常运行时状态
（1）监控告警体系的完善
（2）黑盒白盒的巡检
监控体现的完善并不能发现所有的问题。巡检可以模拟业务场景，实现整个链路上的检查。比如定期凌晨在线上集群进行一波巡检。包括但不限于
检查pod是否可以正常创建
pod网络是否正常
是否有pod长时间处于terminting
是否有控制面组件重启次数过高
etcd集群是否健康
（3）核心组件的cpu, mem监控
（4）k8s组件稳定性建设
-
元数据与event拆分，必要时pod数据也可以用独立的etcd集群
建议对组件产生的event进行梳理，减少不必要的event
设置event-tll=10min, 而不是使用默认的1h。这样集群event爆炸的时候，可以快速恢复
EventRateLimit机制
kube-apiserver，kcm qps的合理设置
APF机制，或者自研的优先级限流机制
-
对其他自研组件，特别是需要ds部署组件的优化
该组件监听什么资源，一定要监听这么多对象，一定要全量监听吗？部署方式是什么，大规模情况下会被打爆吗，会引起连锁反应吗？有么优化空间？
