阿里巴巴|阿里巴巴超大规模 Kubernetes 基础设施运维体系揭秘( 八 ) kubernetes|阿里云|中间件

KubeDefender限流：对一些核心资源，比如pod、service、node ，的操作（特别是Delete操作）按照1m、5m、1h和24h这样的时间维度设置操作令牌。如果令牌消耗完就会触发熔断。UA限流：按时间维度设置某一些服务（UserAgent来标识）操作某一些资源的QPS ，防止访问apiserver过于频繁，影响集群稳定性。 UA限流能力是ACK产品增强能力。APF限流：考虑apiserver的请求优先级和公平性，避免在请求量过大时，有一些重要控制器的被饿死。 K8S原生增强能力。KubeProbe
KubeProbe是ASI巡检/诊断平台，经过不断迭代，目前我们演进了两种架构：中心架构和Operator常驻架构。 KubeProbe也中了今年上海KubeCon议题，感兴趣的同学，到时候也可以参加一下上海KubeCon线上会议。
1）中心架构
我们会有一套中心管控系统。用户的用例会通过统一仓库的镜像的方式接入，使用我们通用的sdk库，自定义巡检和探测逻辑。我们会在中心管控系统上配置好集群和用例的关系配置，如某用例应该执行在哪些集群组上，并做好各种运行时配置。我们支持了周期触发/手动触发/事件触发(如发布)的用例触发方式。用例触发后会在集群内创建一个执行巡检/探测逻辑的Pod ，这个pod里会执行各种用户自定义的业务巡检/探测逻辑，并在成功和失败后通过直接回调/消息队列的方式通知中心端。中心端会负责告警和用例资源清理的工作。

2）常驻Operator架构
对于某些需要724小时不间断的高频短周期探测用例，我们还实现了另外一套常驻分布式架构，这套架构使用一个集群内的ProbeOperator监听probe config cr变化，在探测pod中周而复始的执行探测逻辑。这套架构，完美复用了KubeProbe中心端提供的告警/根因分析/发布阻断等等附加功能，同时使用了标准Operator的云原生架构设计，常驻体系带来了极大的探测频率提升(因为去掉了创建巡检pod和清理数据的开销)基本可以做到对集群的724小时无缝覆盖，同时便于对外集成。
另外还有一个必须要提的非常重要的点，那就是平台只是提供了一个平台层的能力支持，真正这个东西要起作用，还是要看在这个平台上构建的用例是否丰富，能不能方便的让更多人进来写各种巡检和探测用例。就像测试平台很重要，但测试用例更重要这个道理一样。一些通用的workload探测，组件探测，固然能发现很多管控链路上的问题，但是更多的问题，甚至业务层的问题暴露，依赖于基础设施和业务层同学的共同努力。从我们的实践上来说，测试同学和业务同学贡献了很多相关的检查用例，比如ACKASK的创建删除全链路探测巡检，金丝雀业务全链路扩容用例，比如本地生活同学的PaaS平台应用检查等等，也得到了很多稳定性上的结果和收益。目前巡检/探测用例有数十个，明年有机会破百，巡检/探测次数近3000万次，明年可能会过亿。可以提前发现99%以上的集群管控问题和隐患，效果非常好的。

自愈
当我们的业务规模达到一定规模，如果仅仅靠SRE团队线上Oncall去解决问题肯定是远远不够的，一定需要我们系统具备非常强的自愈能力。 K8S面向终态的设计，通过Readiness、Liveness机制能帮忙业务Pod快速自愈。但是当节点故障时，我们也需要节点能快速自愈，或者能快速将节点上的业务驱逐到正常的节点上。 ACK产品也提供了自愈能力， ASI在这个之上做了很多基于ASI业务场景的能力增强。如下是我们售卖区节点自愈能力的架构设计：

随着ASI业务形态的发展，未来我们将在如下场景下进行节点自愈能力增强：