alibaba(阿里巴巴总部在哪里)

alibaba(阿里巴巴总部在哪里)

前言

ASI:阿里巴巴没有服务基础设施，阿里巴巴的统一基础设施是为基于云的应用设计的。基于阿里云公有云容器服务ACK，支持集团的Serverlessian基础设施平台应用基于云的生化和云产品。

2021天猫双11是ASI难忘的一年，今年我们完成了很多第一：

第一次全面统一调度：蚂蚁业务的电商、搜索、ODPS线下和ASI统一调度架构，整个业务的核数达到了千万核。搜索业务第一次“不顺利”地向ASI“示好”:近万个核心业务，业务经常迁移到ASI(但我们经历了许多不眠之夜)。K8S单集ASI场景拥有超过10000个节点，数百万个核心，超过5000个K8S社区，持续优化大规模集群的性能和稳定性。中间件服务使用云产品架构支持集团业务：基于ASI公有云架构的中间件，中间件服务平滑迁移到云端，支持集团业务和云产品架构的“三融合”。在大规模生产应用的锤炼下，ASI推动了大量K8S稳定运营，但也有很多创新能力支持无服务器场景。如果你对K8S有很深的感悟(尤其是对大规模集群的运维)，你会非常容易使用K8S，你想用好K8。ASI使用K8S调度系统架构经历了多场热血课程，在这个过程中不断成长、学习、成熟。示例：

在Kubernetes版本的正常升级过程中，Kubelet升级时，集群中重建了近1000个业务pods在不规范的线上操作中，大量的VIP服务被删除。幸运的是，中间件已经充满了保护，这对业务没有灾难性的影响。证书过期是因为节点的自修复组件失效，风控/流控规则不正确，导致自修复组件使集群300节点上的所有服务失效。对于以上列举的所有故障场景，即使专业的K8S团队未被发现，但如果是K8S的极小用户，当然无法防范和规避风险。所以对于所有使用K8S或者想使用K8S服务的用户，我知道我可以运我的K8S集群，多少坑我不想做，专业的人做专业的事，让专业的产品和SRE团队去运营。在这里，我也强烈推荐用户使用阿里云容器服务ACK，因为我们在阿里巴巴的大规模场景中对其进行了增强，自动运维和功能会借用ACK，有助于更好的维护K8S用户集群。

ASI能运行这么多庞大的K8S集群，肯定有“两把刷子”。今天为大家提供详细的ASI介绍ASI，为阿里集团搭建云基础设施，支持阿里云产品Serverles，我们的运维体系和稳定性工程能力。

ASI技术建筑形式

在介绍ASI的全托管运维体系之前，我花了一点。ASI是基于ACR的云产品的群组和免服务平台ACK，旨在支持阿里巴巴应用云的主要生化和阿里云产品无服务器。以下是容器服务家族的几个成员：ACK、ASK和ACR。

对于阿里巴巴和云的产品，我们将为用户提供K8S集群的增强功能，如增加调度能力、增强网络能力、增强网络能力和多租户安全架构等。无服务器无运维经验，如集群版本升级、组件升级、节点组件升级、节点CVE漏洞修复、节点批量操作等。对于用户的K8S集群来说是稳定的。

ASI旅游操作和维护支持系统

ASI是大规模K8S集群，提供全托管、免运费的用户体验。这些能力不是K8S本地的，而是在大量的实践和失败中沉淀出来的系统稳定性增强能力。并且通过全行业，就是阿里巴巴的大型复杂场景，从而挖掘K8S在大型场景的运维服务体系。

在说ASI运维系统之前，我先强调一下系统能力建设过程中的重要原则：不要重复开机，但也不能依赖其他系统。没有产品，系统可以适应所有的业务问题(尤其是ASI的体量)。依赖于构建上游环节的系统功能，但不完全依赖，做好系统层面的设计。如果系统有好的工作渠道，我们绝对不会做一天，而是根据运维渠道来改变自己的业务。如果我们监控系统和报警链路的容量，我们将管理它、报警规则和路由分布。

还有一点非常重要：如果一个稳定的团队想要运营和维护控制系统，我们必须对业务架构有非常全面和深入的了解。稳定性团队不仅可以操作，还可以在架构外执行1-5-10个功能，这就很难控制整个架构的稳定性。虽然ASI SRE是一个有稳定的ASI基础架构的团队，但是很多SE的同学可以通过Docke的新业务独立确定ASI ASI的架构。事实上，很多时候，如果SRE和R & ampd一起工作，问题会少一些，因为两个角色很互补：R & ampd是在技术框架内判断的，SRE是对建筑的合理性和稳定性风险的一个非常好的判断。

如上所示，ASI集群部署架构完全基于基于ACK产品的基础架构的Kok(kube on Kube)基础。整个架构级联：

元集群(KOK架构底层的k):用于承载K8S业务集群的核心控制组件，为业务集群的控制付费，可以保证部署更加规范，部署效率也会大大提高。控制平面：它是一个业务集群，有四个核心管理规程：Kube-API server/Kube-controller-manager/Kube-scheduler和ETCD集群。附加组件：不必要的核心功能组件、调度增强组件(统一调度器)、网络组件、存储组件、工作负载组件(OpenKruise)、Coredns等旁路组件。数据：节点控制组件，如ContainerD、Kubelet、Kata等。也

有其他节点上的插件。

基于ASI的整个架构，我们连续探索，摘要，抽象ASI操作和维护系统，摘要到一个大模块中，如下所示：

统一变更控制：这是我们从ASI的第一天开始的系统能力。卡点引线;集群运输管理：ACK将提供K8S集群的标准产品功能，但如何/何时进行规模升级，验证，监控是我们需要考虑的;我们还需要建立合理的储备机制，以确保集群稳定;ETCD操作和管控制：ETCD也是一个完全托管的ETCD无服务器产品功能基于ACK，我们将建立ETCD性能优化和保留更好的服务ASI的超大群集与ACK学生。组件操作和维护控制：ASI操作和维护系统是非常核心容量建设，无服务器完整托管服务，最具核心的核心是拥有相应的研发团队来执行功能扩展和操作和维护支持。通过这种方式，如何定义研究和开发模式的研发，确保日常运营和维护的稳定性和效率是ASI产品的关键，支持大量业务。因此，在ASI的建立开始时（2019年，我们支持集团的业务）我们建立了ASI组件中心，逐步定义和优化ASI核心组件的研发和操作模式;节点完全托管操作和维护控制：这是一个非常多云的产品团队希望容器服务提供的容量，特殊的商业产品团队，他们不了解基础设施，我希望有些团队可以帮助节点操作和维护。节点操作和维护能力也是ASI在支持ALI组的过程中沉淀的能力。我们还将这部分经验输出到销售区，并继续优化。云上的最大特点是资源弹性，ASI还为我们在我们销售中提供了云产品用户的节点的最终弹性。1-5-10容量建设：云上有一个非常重要的功能，对故障参数非常低。这也为ASI带来了非常重要的挑战，如何发现，调查和恢复问题，我们一直都能够探索。资源操作：储备，成本优化一直是解决基础设施服务的问题，我们必须确保服务操作稳定（如不是OOM，不要出现CPU竞争），并降低成本，也降低了云产品的成本

接下来，我将详细阐述ASI旅游操作和维护系统中的关键系统/技术能力的设计理念和特定方案，并将其介绍我们如何逐步逐步构建大规模的K8S全管理操作和维修服务。

集群完全托管操作和维护

当我们在运营和维护时，最深刻的感觉是，规模将为单一的操作和维护带来大量复杂性，并且可以大大扩展单一操作和维护的风险爆炸的半径。我们经常受到以下问题的挑战：

所有变化是否会改变风险控制？这么多群集，这么多节点（ASI单个集合组超过了数万节点数千码），如何进行灰度稳定性最小？黑屏无法消除，如何控制风险？虽然单一的操作和维护动作并不困难，但我们经常面临多种操作和维护组合的复杂操作，系统如何安排这些操作和维护操作？

通过这四个问题，我将详细介绍，我们如何在实践中不断地抽象和优化我们的系统能力，并促使ASI全托管服务的当前稳定性系统能力。

统一变更风险管理

2019年，当我们刚刚设置ASI SRE团队时，我们探讨了如何控制控制变革的风险。那时，稳定系统仍然非常弱。这真的是浪费钱。新的SRE团队的同学来自阿里巴巴的Sigma调度系统耗尽，所以每个人的容器K8S，这些技术都很精细，但如何做SRE，如何做稳定是一种脸。我记得ASIOPS系统的开头（当时称为ASI部署，我将换乘额度更改批准2到3周。在新的架构（Sigma - > ASI），新场景（集团业务云）和如此复杂，巨大的K8s业务量，我们在外界没有太多的经验。

当时，我们认为改变风险管理的系统绝对不再，而且集团业务已经完全启动，大量的新技术解决方案出来了，大量的在线更改只能依赖“人们”。因此，我们必须在整个ASI团队中批准批准，但SRE不了解ASI的所有技术架构细节，以制定完美的风险评估。为此，我们已经开始建立“改变审查”会议，并邀请每个领域的专家参与审查会议的变更计划的风险审查。它也是因为这种变化审查机制，在风险阻塞系统非常不足的情况下帮助ASI，“困难”时期是“困难”。 ASI的变更审查会议持续到今天，并且没有特别的脚，将按预定举行。也是时候，SRE也通过参与每个在线变革的批准，SRES也沉淀了大量的安全生产规则。

与此同时，我们开始实现这些非常明确的规则，这些规则将风险更改为ASIOPS系统。刚刚开始在ASI基础系统架构实现风险阻塞功能，后来发现只发现了许多更改的底层ASI指示符/检测，没有办法将一些风险联系起来触发业务级别。阻止规则判断，以便我们可以确保我们的变化不会影响上层业务。因此，我们开始实施ASIOPS中的风险规则库的管理，并实现了联系了上业务方面的检查检测/ E2E测试的Webhook机制。

在ASI具有此在线更改风险阻止系统功能之后，我们从未在密封网络中进行私人变更，并且变化不会制作灰度，非验证等。这种类型的暴力发生了变化。

更改灰度能力

从实际经验中，每个在线更改，无论我们的早期计划审查如何小心，完成了强大，风险块，编写了操作和维护功能。代码在线后，我们始终出现“意外”。对于已经知道的事情，我们会做得很好，可怕的是我们所考虑的东西，这不是一个问题，真正的建筑他就足够了。

因此，该函数在线上必须是灰色的。当然，我们还必须保证变革的决定歧视，并不能说改变是灰度的顺序。 ASI更改灰度能力，我们也使用它。

Sigma Era，集群在房间/交叉区域部署，所以如此庞大的业务量，Sigma也只需要10个无重相称的簇携带。对于研发，因为没有许多群集，群集的使用是什么，业务类型的类型，所以它不是很清楚，所以成本不是很高（当然，由于大半径大爆炸，释放也不断）。但是，在不断发展到ASI架构之后，群集计划根据区域/计算机室严格切割，并且由于K8S群集本身的可扩展问题，因此不可能像群集一样携带超过100,000个节点一个sigma集群。给予K8S社区。它是一种不能超过5,000个节点的单一的剧集大小（尽管ASI已经针对数千个节点的单个群集优化，但稳定性和爆炸半径的过度簇也更高）。在这种架构形式下，ASI集群的数量肯定会大于Sigma集群的数量。研发同学仍处于Sigma晚期，早期ASI，许多研发习惯或Sigma在Sigma时的模型，释放工具或Sigma时代产品，无法支持大规模的K8S集群精制成分。各队伍的研究和发展也害怕各种团队的研究和发展。

那时，当ASI集群的人数尚未成长时，我们已经意识到我们必须解决改变决定论的问题。 ASI是如此多的群集，数以万计的节点，如果每个研发同学都会决定如何改变，必须有问题。但是，当时，我们的系统能力非常不足，并且没有办法智能地确定用于改变研发的最佳变化的灰度序列。那我们该怎么办？系统不再，但它必须解决问题。因此，我们提出了一种管道的概念：通过SRE领先和核心R＆D TL确定线核心集群的释放顺序，定义为管道，然后所有在制作组件升级时开发，您必须绑定此管道，发布时间，灰度可以根据我们的规定释放，这是管道概念的起源。这个“看起来非常低”的功能，当时消耗非常强大的投资，制作初始版本。但是，当我们“充满信心”促进促进研究和发展同学的管道时，他没有收到“鲜花和掌声”我们想象着，但很多“呕吐和优化建议”。因此，我们改变促销策略：逐渐促销，逐渐修改，然后拓宽，直到每个人都得到充分接受。管道已成为ASI研究和开发的不可或缺的释放工具。现在我想到了，我觉得非常有趣。让我们也了解一个真理：任何新功能都不能“关闭门”，你必须设计，从我们的用户的角度来看，只有用户满意，证明我们的系统/产品的价值。

以下图片是R＆D组的核心事务群集的发布顺序：

静态管道已安排ASI群集顺序，只有当组并不多群组时，问题不大。但是，在ASI业务扩展到阿里巴巴云产品之后，特别是在我们一起孵化ASI硬度租金VC架构之后，用户有一个小集群，群集数量增加，并且这种人工人口集群暴露。题：

更新不及时：添加了一个群集，但没有通知相关的同学，没有添加相应的管道;自动适应能力还不够：ASI新进入云产品，需要人工新管道，经常更新并不及时;高维护成本：由于业务越来越多地，所有者的研究和发展必须保持大量的管道;扩展不足：管道订单无法动态调整，并且在ASI支持云产品之后，存在非常重要的需求，这是根据GC级的灰度，静态管道完全无法支持。

根据上述静态管道的缺点，我们还开始了技术解决方案的优化和探索。 ASI核心是资源调度，我们的调度能力非常强大，特别是现在正在进行的统一调度项目，收集集团的电子商务，搜索业务，脱机业务和蚂蚁业务，所有使用统一的调度协议ASI。我在思考中，ASI统一调度程序是资源CPU，内存调度，群集信息，节点号，POD的数量，用户GC信息也是“资源”，为什么不能使用调度想法来解决ASI簇灰度顺序编排问题？因此，我们指的是调度程序的设计来实现群集调度程序，集成群集的各种信息，分数，排序和绘制群集流水线，然后提供研究和开发的同学执行灰度级别。

Cluster-Scheduler实现“动态”管道功能，可以解决静态管道中遇到的各种问题：

释放组件灰度时，通过集群调度器过滤的集群范围绝对不会泄漏;根据GC级别设置群集释放顺序，也可以根据群集的刻度数据动态调整群集的权重;当R＆D释放时，无需维护多个静态管道，只需选择组件释放范围，自动执行群集释放序列。

当然，静态管道具有很大的优势：可以缓冲集群发布顺序，在一些新功能中，研发需要具有这种自助容量。因此，在未来，我们也是静态/动态管道在一起，互相补充。

群集WebShell工具

当SRE受到稳定的控制时，它必须是所有变化都是白色筛选和在线。但是，从我们的操作和维护K8S的实际情况，无法实现所有操作操作。我们无法直接向R＆D提供集群证书。亚洲还可以在初始期间看到业务POD的行为。虽然我们无法设置K8S所有操作和维护操作以在系统上开发它，但我们可以使用Kubectl工具用于开发，然后提供基于在线工具的稳定性，安全性，风控制。等待能力。

因此，我们在OPS系统中提供集群着陆工具，R＆D可以首先应用于群集资源访问，然后通过WebShell访问群集。在WebShell中，我们将记录所有用户的操作并上传到审计中心。

在线WebShell，与用户本地证书访问集群相比，我们已经完成了很多安全/稳定性强化：

权限完善控制：许可和用户绑定，有效期，严格控制;安全：不会向用户提供证书，因此证书泄漏没有问题;审核：所有业务都有审核;风控制：检测危险操作，在线批准后发出操作。

改变容量

早期的风险阻塞，改变灰度和黑屏改变融合，正在解决ASI稳定性问题。但是，谁可以帮助解决我们的SRE学生面临的挑战？

做稳定性的同学你知道在你改变白屏/在线之后，我们可以控制这些变化中心，控制风险。但是，对于ASI的这种非常大的复杂基础设施服务，有许多场景和复杂。我们的SRE负责构建整个ASIOPS操作和维护平台，这是面对每日重型运营和维护工作的必要条件，也是建立一个系统，而且更多的注定是我们的同学诞生，OPS系统的需求做前端界面。写前端是后端工程师的梦想，通常是后端功能1H，首页将要绘制至少一天。

SRE团队是一支技术服务团队，不仅让我们的服务器满意，而且让我们感到满意。因此，我们一直在探索如何降低系统能力建设过程中的运行和维护系统成本。每个人都应该知道操作和维护能力和业务系统是不同的，操作和维护操作更集成，例如解决在线ECS上的eni网卡问题。完整的操作和维护容量是：首先，在节点上执行扫描脚本，扫描泄漏的eni网卡;然后它是一个程序将被扫描为eni网卡引入的程序;最后一个ENI网卡被清除，并且报告了相应的状态。因此，我们想成为一件事：实施一系列操作操作，该操作快速实现复杂的操作和维护逻辑，以快速操作多个独立操作。那时，我们还调查了很多项目，如Tekton，Argo。我发现它是一个项目pr非常好，但功能太基本，无法满足我们的场景;无论是在设计中更适合商业场景，这对我们的底层基础设施非常陌生。

因此，我们决定采取项目的本质，参考他们的设计，并实现ASI自己的操作和维护引擎工具。这是ASIPS中任务流打样引擎的原点，架构如下图所示：

PipelInecontroller：依靠维护任务TaskController：任务状态信息维护Taskscheduler：任务派遣任务/工作者：任务执行

节点扩展功能的示例，如果它是单个节点的功能完整生命周期管理，则必须写入所有操作功能。但是，在使用任务污染功能后，只需实现3个执行程序逻辑：ess扩展，节点初始化，节点导入。 TaskFlow将流到这三个executors以完成主节点扩展操作。

目前，TaskFlow已广泛用于ASIOPS，涵盖诊断，计划，节点导入，VC群集开放服务，一次性操作和维护，发布和其他场景，大大提高了新的操作和维护场景系统能力开发。效力。

经过两年多的运动后，SRE团队的核心研究和发展基本上是一个“完整堆栈工程师”（在现场之前，后端研发）。特别是，前端界面的研究和发展，不仅没有成为我们团队的负担，而且相反成为我们团队的优势。许多系统功能要求将前端接口暴露于用户，并且ASI中的大多数研发是后端工程师团队。 SRE团队的前端开发资源已成为我们非常重要的“竞争力”。它也完全证明：技术如何没有压缩。

概括

关于ASI集群完全托管操作和维护功能，我的核心介绍了如何更改风险块，更改安排，更改灰度和融合黑屏更改系统能力实现。当然，我们远远超过ASI控制全管理级别的系统功能，并且架构升级中有许多大型变化，因为我们有这么多的场景累积，以解决许多重要的系统能力。

组件旅游操作和维护

关于ASI组件的完整蜂兴能力，我们发布了详细介绍：ASI组件灰度系统建设，每个人都对细节感兴趣，确实在如此大规模的场景中，将有技术和经验。沉淀。所以我这里没有过度的技术计划，但更多地引入技术演变的过程。 ASI股票在组件灰度容量建设中，它也被选为2020 Kubecon主题：“我们如何管理我们在阿里巴巴中的广泛变化的Kubernetes基础设施”，感兴趣的学生可以找到相关的视频。

ASI全托管模式是与当前半托管集装箱服务云产品非常重要的区别：ASI将负责维护K8S集群中的核心组件（研发，问题调查和操作）。这实际上与ASI的起源有关，ASI起??源于集体业务的综合云期，我们提供了一个大型集群+公共资源池模型，以逐渐从Sigma架构迁移ASI。对于小组业务，它肯定不会在K8S集群中维护和集群中的各种组件，因此这件作品由ASI团队完全管理，但也使ASI逐步孵育组件的系统能力。

如上所示，ASI的整个架构的各个级别现在基于基于ASIOPS的变化灰度管理。事实上，ASI的所有组件现在都在平台中维护，并且统一执行灰度容量建设是理所当然的。然而，当时，我们已经过去了很长的“斗争”来制作今天的架构如此合理。在许多激烈的讨论和各种稳定的稳定性中，我们终于探索了更具可比的顶级设计：

IAC组件模型：使用K8S声明设计将所有ASI组件类型更改为面向面向面向面向设计的设计;统一变更安排：最重要的组件变化是灰度，最重要的灰度是群集/节点灰度顺序，所有组件都需要更改灰度排列;组件云原始翻新：原始节点基于天上的基础，更改为K8S原始操作员为导向的设计，使节点组件实现基本组件更改通道，批处理，暂停等。 OPS系统的上层实现了组件版本管理，灰度变化布置等。

经过两年多的发展，ASI系统下的组件变化也在平台下完全统一，并且基于云的容量也构造了一个非常完整的灰度能力：

节点完全托管操作和维护

我还介绍了前面，我们在构建系统功能时，我们不会重复车轮，但你不能完全依赖其他产品。 ACK提供节点生命周期管理的基本产品功能，而ASI则是ACK的无服务器平台，有必要在ACK的基本产品功能上构建缩放操作和维护功能。从Sigma Era到ASI支持组，ASI沉淀了非常多种尺度操作和维护节点的能力和经验。接下来，我们将介绍我们如何构建销售区的节点集合。

节点全生命周期定义

要构建一个相对完整的节点全管理的操作和维护功能，我们必须首先打击您需要执行全生活周期的每个阶段，如下所示，我们将大致分为节点全生命周期的5个阶段：

在节点生产之前：相对复杂的方案是每个云产品的集合或更多资源帐户，许多需要自定义ECS镜像。这些需要新的商业访问时需要详细的定义;导入节点时：导入群集节点以构建要创建/展开/导入/脱机操作的节点;节点运行时：节点通常是最有问题的阶段，这也在关键容量构建中暂存，如节点组件升级，批量执行脚本功能，CVE漏洞修复，节点检查，自我修复等。当节点脱机时：在节点成本优化的情况下，内核CVE漏洞修复和其他方案，将需要节点，并且诸如节点之类的节点设计为打开。当节点出现故障时：当节点有故障时，我们需要快速检测能力，问题诊断和自我修复以及问题的能力。

节点容量构建大图片

ASI销售区节点托管能力超过1年。它带有所有ASI的云产品在销售区，而大部分核心竞争力都更加完美。我们已经不断优化。

节点灵活性

云上最大的功能之一是资源弹性，节点弹性也是为云产品用户提供ASI的非常重要的能力。 ASI的节点弹性能力依赖于ECS资源的最终弹性，并且可以根据分钟级别购买ECS资源，帮助云产品细化控制资源成本。视频云云产品目前依赖于ASI的ASI节点弹性，以执行资源成本控制。视频云平均节点灵活3000多次，并已优化，ASI节点弹性可以在几分钟内完全拉动视频云业务。

在节点灵活性上，我们在节点的生命周期中执行性能优化：

受控级别：通过控制并发性，可以快速完成数百个EC的弹性任务处理;组件部署优化：Daemonset组件都被修改为步行区域VPC的内部地址;RPM组件使用ECS镜像模式，并执行节点组件部署序列以增强节点组件安装速度;最后，yum源带宽优化，从原始共享带宽到独占带宽模式，避免了通过其他rpm下载任务初始化我们的节点。业务初始化：介绍DADI镜预热技术，快速预热业务镜在节点进口过程中，目前可达到10g尺寸镜像，仅需3分钟。

1-5-10能力建设

ASI全托管模式的服务是最重要的是为云产品用户执行潜在的集群稳定性问题。这是ASI的1-5-10能力要求非常高，然后向您介绍3个核心稳定性功能：

风控制：在任何情况下，ASI都应该能够踩到制动器;kubeprobe：群集核心链路的快速探测稳定性问题;自我修复：大节点，非常依赖节点。

风控

随时，ASI必须有能力“踩到制动器”。无论是我们自己的同学还是上层业务块，系统必须及时停用。在文章的开头时，我还介绍了ASI一次发生的大规模重启，意外删除了Pod。由于以前的血液眼泪，我们创造了我们许多风力控制能力的诞生。

KubedeFender是有限的：一些核心资源，如POD，服务，节点，操作令牌1M，5米，1h和24小时，按照1m，5m，1h和24h的时间尺寸。如果令牌消耗，它将触发打击。UA限制：设置一些服务（使用者来识别）以操作一些资源的QP，以防止访问Apiserver过于频繁，影响集群稳定性。 UA限流容量是ACK产品增强功能。APF电流限制：考虑Apiserver的要求优先和公平，避免在请求过大时饥饿的一些重要控制器。 K8S本机增强能力。

kubeprobe

KubeProbe是一个ASI巡逻/诊断平台，这是一个迭代，我们已经演变了两种架构：*架构和操作员居民架构。 Kubeprobe还有今年上海库波顿的主题，对同学感兴趣，也可以参加上海库邦顿在线会议。

1）中心架构

我们将拥有一个*控制系统。用户的用例可以通过统一仓库的镜像访问，使用我们的Universal SDK库，自定义巡逻和探测逻辑。我们将在*管理系统上配置群集的关系配置和用例。如果应在群集组上执行豁免并执行各种运行时配置。我们支持循环触发器/手动触发器/事件触发器（例如发布）用例触发方法。使用示例触发后，创建在群集中执行巡逻/探测逻辑的POD。此POD执行各种用户定义的业务检查/检测逻辑，并且在成功且失败后，通过直接回调/消息队列通知中心结束。该中心负责警报的工作和资源清洁的使用。

2）某事验光架构

对于需要7 * 24小时不间断的一些高频短期检测案例，我们还实现了另一个常驻分布式架构。该架构在群集中使用探针仪来监视探测配置CR的变化，在检测POD中执行执行检测逻辑。这套架构，与kubeprobe等的闹钟/ root分析/释放阻塞完美（因为创建巡逻吊舱和清洁数据的开销基本上是集群7 * 24小时的无缝覆盖，它方便的外部集成。

还有一个非常重要的观点必须提及。也就是说，平台只是支持平台层的能力。它真的在这个平台中的角色，或者有必要看看在这个平台上建立的用例是否丰富，不能方便让更多的人进来写各种各样的检查和检测。就像测试平台很重要一样，测试案例更为重要。一些普遍的工作负载探测，组件检测，或者在控制链路上发现问题，但甚至是商业层曝光的问题，取决于基本设施和业务团队学生的共同努力。从我们的实践中，测试同学和商业学生贡献了很多相关的检查案例，如ACK和ASK的创作删除全链路检测检测检查，而Kelique Care则创建一个全链路扩展使用，如当地生活方式PAAS平台应用检查等，也有很多稳定的结果和福利。目前，有几十种检查/检测例子。明年将有机会打破100。检查/检测近3000万次，明年可能超过1亿。它可以预先发现超过99％的集群控制问题和隐患，效果非常好。

真诚

当我们的业务规模达到一定规模时，如果它只依靠SRE团队在线解决问题，它必须远远不够，它必须是一个非常强烈的自我修复能力。K8S正在为最终设计设计，通过准备好，活力机制可以帮助商业植物速度快速自我修复。但是当节点有故障时，我们还需要一个节点来快速自我修复，或者快速快速将节点上的业务驱逐到正常节点。ACK产品还提供自我修复，ASI基于ASI商业场景对此进行了许多能力。以下是我们销售区域的自我修复能力的架构设计：

随着ASI业务表单的开发，我们将以下一个方案增强：

诊断，自我修复更丰富：目前的诊断，自我修复很多方案没有覆盖，需要不断优化覆盖，更多的节点故障场景;基于细节池的精致风格，流量控制：节点的前提不能使现状更差，所以我们需要在自我修复时做出更准确的判断;节点自我修复和上部业务：不同的业务形式，节点的不同要求。例如，Flink业务是任务类型。如果您遇到节点问题，我们需要尽快驱逐业务，触发任务重建，最担心的是任务“半死”;中间件/数据库业务是有状态，不允许我们驱逐业务，但如果我们使用上层业务逻辑转动您的自我修复能力，我们可以使节点失败的业务，使业务将成为自我修复以及业务如何自我修复。

期待未来

ASI作为集装箱服务ACK在阿里巴巴中连续抛光统一无法统一的基础设施，连续构建更强大的自动驾驶K8S集群，为整个行业提供全面的群集，节点，组件和输出更多经验的完整致敬能力。 。 ASI作为ALI Group，Alibaba云基础设施基础，为增加云产品提供更多专业服务，托管底层K8S集群，屏蔽复杂K8S阈值，透明几乎所有基础设施复杂性，专业的产品技术稳定，只能让云产品稳定需要对自己的业务负责，专业的平台部门做专业的事情。

原始链接：http：//click.aliyun.com/m/1000316409/

本文是阿里巴巴云原始内容，并且不允许重新打印。