k8s大规模集群如何保证稳定性

从事云原生底层研发近3年，经历了大大小小的容器集群故障。记录一下容器集群稳定性建设心得。首先，集群状态可以分为变更状态 + 正常

从事云原生底层研发近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部署组件的优化
  该组件监听什么资源，一定要监听这么多对象，一定要全量监听吗？部署方式是什么，大规模情况下会被打爆吗，会引起连锁反应吗？有么优化空间？