在阿里巴巴，我们如何先于用户发现和定位 Kubernetes 集群问题？

阅读 4月前 0 10

作者：彭南光(光南)

本文收拾自阿里云高级研制工程师彭南光(光南) 在 KubeCon China 2021 大会的讲演实录，共享了阿里巴巴是怎么经过自研通用链路勘探+定向巡检东西 KubeProbe 应对大规模集群的安稳性应战的。关于阿里如此原生团队在本次 KubeCon 上共享的悉数内容沉淀于电子书《云原生与云未来的新或许》傍边，可点击文末“阅览原文”下载。

快速发现和定位问题的才干是快速康复体系的柱石，只有先做到快速发现和定位问题，才干谈怎么处理问题，尽量削减用户损失。那么怎么在杂乱的大规模场景中，做到真实的先于用户发现和定位问题呢？我会将咱们在办理大型 Kubernetes 集群进程中快速发现和定位问题的一些经历和实践带给咱们——咱们是怎么经过自研通用链路勘探+定向巡检东西 KubeProbe 应对遇到的大规模集群的安稳性应战的。

链路勘探： 模仿广义用户行为，勘探链路和体系是否反常

定向检测： 查看集群反常目标，发现未来存在或或许存在的危险点

体系增强： 发现问题提速增效，根因剖析

发现问题之后： 后置查看和自愈，Chat-Ops

事务背景和应战

阿里如此原生运用渠道的容器服务团队，具有 ACK 、ASI 等产品，办理了大规模的 Kubernetes 集群，不只向外部公有云用户供给 Kubernetes 服务，还承当了阿里巴巴集团上云，阿里巴巴运用全面容器化的作业。

现在，整个阿里巴巴的事务都跑在 Kubernetes 集群上并完成了云原生和容器化，例如：天猫/淘宝/高德/考拉/饿了么等等。容器服务作为阿里云的管控底座，各种云服务也运转在这些集群之上，例如视频云/dataworks /MSE 微服务引擎/MQ 音讯行列等等。咱们需求对这些基础设施的安稳性担任。

现在，云原生的架构越来越流行，越来越多的产品和运用开端挑选云原生架构，这里有一张图，大致示意了现代的云原生运用架构，运用生于云上，长于云上，各级供给分层的服务，这种分层的服务能够让事务和运用专心于事务层，屏蔽渠道和基础设施层的杂乱概念。

从安稳性的视点来讲，这种运用的架构分层，上层运用的安稳性就会开端依靠底层基础设施的支撑；别的，大一统的基座既为大规模的资源调度优化和在离线混部供给场景，也对基础设施团队保护大规模集群的安稳性问题提出极大的应战。

这里有两张形象的图示能够展现出云原生运用架构下的事务运用和渠道层基础设施的联络，Kubernetes 集群是十分杂乱的，一个单集群的链路组件就稀有十个乃至上百个之多，何况是大规模的多集群办理呢？但运转在上层的事务同学并不会感知到杂乱，因为咱们现已把杂乱包掉了，留给用户的是一个简略的一致接口。就像淘宝这样的运用其实是十分杂乱的，但在用户看来仅仅一个简略的提交订单罢了，按键背面蕴含着极其杂乱的内容。为什么做到这样？因为咱们把杂乱留给了自己，把简略交给了用户。

许多时分，好的运用开发者不必定是基础设施专家，云原生让事务专心事务，基础设施专心基础设施。一起，事务许多时分也只能关怀事务本身的安稳性，事务大多数时分没有才干关怀，或许是不希望投入许多的人力关怀基础设施和渠道层的安稳性，所以，关于渠道层和基础设施的安稳性问题上，咱们需求把杂乱留给自己，把简略留给用户，为用户供给安稳的渠道层服务。一起，愈加关怀大局安稳性和大局的可用性，而不是单点可用性。

容器服务是阿里巴巴集团事务以及阿里云管控/云服务的底座，上面跑着各种各样的事务，如电商事务/中间件/二方事务/查找/阿里如此服务等等。此外还稀有百个自研和开源的组件，每年数十万次的组件改变/数千个集群/数十万台节点，乃至大的集群单集群节点规模已过万。事务架构更是纷冗杂乱，有单租集群、多租集群、vc 集群、联邦集群等等，一起还有各种在离线混布、一致调度、大促活动。在运转时也存在多种形状，如 runC，runD 等等。

因此组件的冗杂、改变频繁、用户场景各异、集群规模巨大、事务架构杂乱……都给事务带来了应战：

应战一：怎么下降体系危险。 场景杂乱，事务形状各异，任何一个不起眼细节的遗失或环节的处置不小心都有或许导致损伤的扩大化；

应战二：怎么对用户集群的安稳性担任。 怎么先于用户发现和定位问题成为容器服务出产安稳性建设的重中之重，也是大局高可用体系的柱石。

体系是如此的杂乱，任何一个不起眼的细节遗失或处理不小心都有或许导致非预期的损伤，咱们要怎样才干下降体系危险呢？别的咱们又是怎么对形状各异的用户集群运转时大局安稳性担任的呢？怎么才干先于用户发现和定位这些集群中现已存在或即将发生的问题，是确保集群的安稳性建设的重中之重，也是 Kubernetes 大局高可用体系的柱石。

考虑和方案

基于这些应战，咱们做了一些考虑和预设。下图是一个极度简化的用户发布扩容链路，虽然极度简化，但实践咱们仍能够看出，链路仍是比较杂乱的。

为了确保这次用户的扩容/发布链路疏通，咱们首要带来几个预设：

预设 1： 链路杂乱组件众多，各组件分别晋级迭代，数据监控无法无死角掩盖悉数场景；****

预设 2： 即便链路中各组件/节点监控数据正常，也不能确保集群全体链路 100% 可用，只有经过实践事务全链路勘探才干确定实践可用的结论；

预设 3： 反证法在证明集群不可用场景必定优于举证法，即便 100% 监控数据正常，但只需发布失利则证明链路不通。别的，在单集群之外，咱们还要重视多集群的办理，下面是一些多集群管控中的不安稳性要素示例，能够看到，多集群场景下，安稳性管控的杂乱度会被放大，咱们继续带来几个预设：

预设 4： 在大规模集群场景下数据一致性的问题会愈加闪现，而且或许引发严峻毛病，成为一个明显的不安稳要素；

预设 5： 集群内的监控告警链路存在自依靠危险，假如集群毛病，则监控告警也有或许一起毛病。

接下来是咱们基于以上预设的一些处理方案。

探究和处理方案

1. 链路勘探

链路勘探即模仿广义上的用户行为，勘探链路是否疏通，流程是否无反常。

想要做到先于用户发现体系问题，咱们自己首要要成为体系用户，而且是运用最多、了解最深、无时无刻不在运用和感知体系状况的用户。

所谓链路勘探，便是模仿广义上的用户行为，去对集群组件链路中的各种等候勘探的目标去做勘探。此处要特别阐明的是，这里的用户并不只仅指的是狭义上运用体系的同学，而是更广义的用户，或许能够了解和引申成为依靠下游。

别的，在完成全链路勘探的一起，拆解电路，完成全电路中的短路勘探也是十分必要的，也是对全链路勘探的一个弥补。

2. 定向巡检

定向巡检是指查看和剖析大规模集群的反常目标，找到已有或将来或许存在的危险点，就像检修管道相同。

例如有若干个集群，它分为许多集群组，不同集群组之间的 etcd 冷/热备是否装备完备，风控限流装备是否正常，webhook 版别是否正常，混部参数是否一致，包含它的证书有效期是不是快要到期了等等。不同的集群组之间或许有所不同，但同类型集群之间是有一个转衡的，因此咱们能够定向做一些巡检。

接下来是关于链路勘探的一些常见场景：

就像一个游戏策划，假如他连自己制作的游戏都不玩，他或许发现游戏机制的问题，把这个游戏越做越好吗？咱们要做到先于用户发现体系问题，那咱们自己首要就要先成为体系的用户，而且必定是运用最多的，了解最深的，无时无刻不在运用和感知体系状况的用户。

别的，所谓链路勘探，便是让自己成为自己体系的用户，模仿广义上的“用户”行为去对集群/组件/链路里的各种等候勘探的目标去做勘探。

必定要注意，这里的“用户”并不只仅指的是狭义上运用体系的同学，而是更广义的用户，或许能够了解引申为依靠下游。

例如事务同学要发布事务，就必然要经过 git 体系，再到发布体系，再到咱们底层的基础设施渠道，也便是咱们的 ASI，这便是一次全链路勘探流程。在这里事务同学便是用户，勘探目标能够是全链路。但假如咱们把 etcd 看作一个体系服务，那么 APIServer 便是它广义上的用户，咱们模仿 APIServer 请求 etcd 这条链路的勘探也就有了含义。

别的像 MSE 操作 zookeeper，外部用户经过阿里云控制台创立 ACK 集群，PaaS 渠道操作联邦集群，乃至视频云事务方建议一次转码任务，都是相同的道理。

还有一点要重视的便是，虽然全链路勘探看起来很美，但许多时分，全链路勘探一起还很长，或许比及失利的时分问题现已很大了。所以，在完成全链路勘探的一起，拆解链路，完成全链路中的短链路勘探也是十分必要的，也是对全链路勘探的一个弥补。

上图是定向巡检的场景，相比链路勘探重视于链路可用性，定向巡检的中心仍是在大规模的集群场景下，数据一致性是十分困难的问题，数据不一致，将导致一些危险，或许会在未来引发某些不确定性的毛病。

所谓定向巡检便是对整个集群或链路中的各项数据、目标做已知原因的查看，找出不一致或数据偏离的点，判别是否或许引发危险，然后做到防患于未然，治未病。

比方咱们这个里边有同一种类型的集群组，A 集群发现它的证书有效期不到三年，而其他集群的证书有效期都有三年；B 集群的 webhook 版别或许是 v2，而其他集群的 webhook 版别是 v3；C 集群的风控限流装备并没有配一个驱赶 Pod 的限流，但其他集群都配装备了驱赶 Pod 的限流，这肯定是不符合预期的；再比方 D 集群的 etcd 的冷/热备没有装备或许是运转不正常，咱们也能够先把它查看出来。

体系完成

基于上面许许多多的背景预设以及方案，咱们规划并完成了一套巡检/勘探渠道，咱们取名为 KubeProbe (并未开源，和现在社区上有相似命名的项目没有任何联络)。

咱们前期也曾考虑运用社区项目 Kuberhealthy，并为 Kuberhealthy 做过一些代码奉献，修复过一些严峻的代码 Bug，终究因为功用上不太适用于咱们的场景，咱们挑选了自研自建。

上图是一套中心架构，咱们会有一套中心管控体系。用户的用例会经过一致仓库的镜像的方法接入，运用咱们通用的 sdk 库，自定义巡检和勘探逻辑。咱们会在中心管控体系上装备好集群和用例的联络装备，如某用例应该履行在哪些集群组上，并做好各种运转时装备。咱们支撑了周期触发/手动触发/事情触发(如发布)的用例触发方法。用例触发后会在集群内创立一个履行巡检/勘探逻辑的 Pod，这个 Pod 里会履行各种用户自定义的事务巡检/勘探逻辑，并在成功和失利后经过直接回调/音讯行列的方法告知中心端。中心端会担任告警和用例资源清理的作业。

我举一个比方，比方 Kubelet 在咱们的组件运维渠道上做分批发布，每批次都会触发一次相关集群的链路勘探用例作为后置查看，一旦咱们发现某次发布的后置查看失利，咱们会阻断掉用户的当时发布，避免损伤扩大，一起第一时间告警以及告知相关搭档进入排查，是否组件新版别不符合预期。

一起，咱们也支撑第三方的事情回调，能够更快的集成进三方体系中。

别的，咱们关于某些需求 724 小时不间断的高频次短周期勘探用例，咱们还完成了别的一套常驻分布式架构，这套架构运用一个集群内的 ProbeOperator 监听 Probe Config CRD 变化，在勘探 pod 中周而复始的履行勘探逻辑。这套架构，完美复用了 KubeProbe 中心端供给的告警/根因剖析/发布阻断等等附加功用，一起运用了标准 Operator 的云原生架构规划，常驻体系带来了极大的勘探频率提升(因为去掉了创立巡检 pod 和清理数据的开销)根本能够做到对集群的 724 小时无缝掩盖，一起便于对外集成。

别的还有一个必需求提的十分重要的点，即渠道仅仅供给了一个渠道层的才干支撑，真实这个东西要起作用，仍是要看在这个渠道上构建的用例是否丰富，能不能便利的让更多人进来写各种巡检和勘探用例。就像测验渠道很重要，但测验用例比测验渠道更重要这个道理相同。一些通用的 workload 勘探，组件勘探，固然能发现许多管控链路上的问题，可是更多的问题，乃至事务层的问题露出，实践上依靠于基础设施和事务层同学的共同努力。

从咱们的实践上来说，测验同学和事务同学奉献了许多相关的查看用例，比方测验同学奉献的 ACK & ASK 的创立删去全链路勘探巡检，金丝雀事务全链路扩容用例，比方本地日子同学的 PaaS 渠道运用查看等等，也得到了许多安稳性上的成果和收益。现在咱们保护的巡检/勘探用例稀有十个，下一年有时机破百，巡检/勘探次数近 3000 万次，下一年或许会过亿。现在能够提早发现 99%以上的集群管控问题和危险，作用是十分好的。

发现问题之后：根因剖析和事情处理

接下来咱们聊聊发现问题之后的作业，这里有一个相似于问诊对话的比方，患者发现 “哎呀我不舒畅了！”这便是发现问题。医师参阅各种化验单，一起做了信息聚合剖析揣度，告知患者“你现已 24 小时没睡觉了，你睡不着是因为你很焦虑，你焦虑的根因是因为后天就要期末考试了。”这便是定位问题根因，然后针对根因去处理这个问题，他告知患者“不要担心，我刚收到的音讯，小学生现已不需求期末考试了。”这个进程必定要快！

来自勘探链路的告警内容往往是混沌的，和数据监控告警是有所差异的。就像上文说到的，链路勘探告警的告警很或许便是一句患者的我不舒畅了，需求你作为医师去判别，为什么他不舒畅了呢？根因是什么。而数据监控许多时分本身就代表了原因，比方 Etcd OOM，用已有的 oncall 经历或许得不到最好的作用。

别的快速定位问题和根因剖析，是一个树状的查找，经历加工判别的进程，也便是怎么从一个混沌的表象揣度出根因，中心是逻辑。

这和健康体检是不同的，健康体检是列出查看项 1，2，3，4，5……然后告知你一堆数值。许多时分，即便存在体检中心，咱们仍然也需求医院的专业医师来为您解读和判别病情，不是吗？

一起，根因剖析/问题自愈的关键在于专家经历的下沉，也便是把专家经历下沉到体系中去，专家经历的下沉带来的最大收益是可复用可输出。你能够想一下，假如咱们把一个最专业的医师的才干放进体系里，他是不是更便利的为每一个人剖析病情呢？

这便是 KubeProbe 发现问题之后的全流程，咱们首要会经过一个咱们自建的中心化根因剖析体系，在这里咱们会聚合剖析一切和本次失利相关的信息，包含事情/日志/改变/告警/组件晋级等等，咱们将这些信息进行聚合剖析，并对事情做相关处理，终究经过一个树状的剖析体系开始定位出某次勘探失利的原因，比方说 APIServer 超时或许 etcd 断连等等。

此外我再弥补一点，文本联想也是一个很好的根因剖析方法，咱们能够经过机器学习训练文本辨认的方法来联想出和这种失利 case 最相关的根因，这种 AIOps 的作业咱们仅仅稍微涉及，还在继续的探究中，咱们的数据量十分大，我认为这必定是未来的方向之一。

KubeProbe 根因剖析和后置处理全流程

上图的左下方是某次咱们失利的告警，它经过根因剖析体系之后发现首要最中心，最相关，最大的原因或许是 APIserver 的连接断开而且当时现已康复，所以或许仅仅偶发的网络颤动，咱们暂时不用特别重视，但此刻能够看到置信度为 90%。

别的还有一些或许的原因都会相关起来。比方某个组件，这次勘探它是由某一个组件发布出发的，它的发布人是 XXX，咱们能够调查这个发布对 API server 会发生某些影响，是否屡次 list watch 不符合预期，然后把 API server list watch 出问题了，置信度有 50%。

当咱们得到一个开始的原因之后，咱们会进入二次承认体系做二次的原因承认，比方咱们判别原因或许是 APIServer 超时/etcd 断联/节点超时等,咱们就会自动重新拉取一下 APIServer 接口，看一下此刻是否仍然超时，是否康复，假如康复了，咱们就一般告警，而且告知用户，现在没事了，可是你得重视。假如没康复，那这就很严峻了，属于最高优先级，直接电话告警。

便是这个思路，假如有体系无法定位的问题，而且继续无法定位，咱们也会触发高级别告警，而且会添加相关的根因剖析辨认树逻辑。

过多的告警等于没有告警，我是最厌烦告警海的。从经历上讲，当咱们构建了一套这样的根因剖析+二次承认+后置查看体系之后，咱们的 Oncall 成本下降了 90% 以上，而且还能够继续下降，终态能够说是无人值守，咱们也能够试试相似的作业，能够说是投入小，见效大。自从这些体系建设起来以后，咱们能够自豪的说，咱们用很小的精力 Oncall 了每一个告警条目（对，是每一条告警，是数千个集群，数千万次勘探巡检的每一条告警）而且不会有任何遗失了。

最终是一些给 Oncall 人员的小甜品，Chat-ops。

基于 NLP 语义辨认的 Chat-ops 体系

咱们利用钉钉供给的 NLP 机器人，构建了一套比较完善的 Chat-ops 体系，这样之后咱们的 Oncall 人员就能够很便利的在告警群里经过谈天的方法操作 KubeProbe 相关功用了，比方：重跑失利勘探，查询集群状况，拉取确诊信息，查询勘探日志，集群告警静默。

上图是咱们操作 Chat-ops 体系的进程。这个进程十分便利。

比方晚上我现已再被窝里了，这时分它给我了一个告警，比方某个集群之前呈现了某次失利但当时现已康复了，需求我重视一下。

既然我重视了，我便希望某一个常用例再跑一次（它或许周期比较长，例如一个钟头），因为短链路的用例或许随时都在跑，此刻我便告知机器人再跑一次，机器人就会辨认我的语义，将集群再跑一次。跑完之后，我再经过查询状况看一下这个集群当时的状况怎么样了，这样是十分便利的，有时分你晚上上班了，或许是在路上，或许是在被窝里，都也能够很舒畅的去 on-call 一个体系了。