共计 6370 个字符,预计需要花费 16 分钟才能阅读完成。
前言
2021 年,极氪 001 迅速锋芒毕露,仅用 110 天便创下了首款车型交付量“最快破万”的纪录。2022 年 11 月,极氪 009 在短短 76 天内便率先实现了首批交付,刷新了中国奢华纯电品牌交付速度的纪录。2023 年 6 月,极氪汽车再次交付 10620 辆,成为放弃五个月间断同比增长的惟一奢华纯电品牌。至此,极氪 001 已成为寰球最快冲破 10 万辆销售的豪华车,再次稳居 30 万元以上纯电车型销冠。
在过来的两年里,极氪汽车业务减速倒退,数字化倒退部门面临微小挑战。作为反对公司履约交付、整车交付、领取结算等诸多外围零碎的技术部门,团队简直每天都须要应答不同规模的利用公布,且利用零碎所需的云资源耗费日益减少。之前,为确保业务疾速倒退失去无效反对,基础设施的整体架构不足顶层统筹规划,局势犹如横蛮成长。公司尽管在行业赛道中一直突破交付纪录,但疯狂增长背地,则是濒临失控的基础设施框架及老本收入,这种情况正对将来业务的可继续倒退,带来了极大的危险和隐患。
因而,从去年开始,技术中台团队制订了明确的技术指标,力求尽快成立专项小组,深度整治现有基础设施的问题。团队期待通过改良基础架构,为极氪汽车将来基础架构的可继续倒退保驾护航。
治理挑战
摆在面前的第一个问题,就是云原生场景下的资源管理。
事实上,自 2021 年起,咱们便开始了微服务和容器化革新打算,90% 以上的服务以容器的模式构建和部署。晚期在探讨如何优化计算资源的配置时,惯例的做法是对服务器进行资源利用率检测,对利用率不超过肯定阈值的资源,依照 CPU / 内存峰值用量调整即可。但在云原生环境下,因为 Kubernetes 为容器资源管理提供了资源申请(Request)与资源限度(Limit)的语义形容,使得利用能够超额分配在对应的服务器资源上,若只是简略的剖析计算资源利用率,而疏忽了资源的分配率,可能导致在下一次利用公布时,因资源有余而无奈调度容器到对应节点。
公司以后应用到阿里云及多个公有云平台,运行了数十个 K8s 集群,同时这些集群上承载了数千个 Pod 节点,在理论运行利用零碎时,许多服务的利用率并不高,造成了极大的资源节约。然而当咱们着手制订打算,心愿优化这部分资源时,发现诸多挑战:
- 资源管理复杂度高:相比于利用间接部署在服务器上,云原生架构的劣势在于对底层计算资源的治理更为精细化,以集群为单位的资源调度形式,对于晋升集群利用率有显著的作用。但与之带来的问题便是治理复杂度的问题。通过一个集群对立治理利用,尽管升高了总体资源老本,但使得分账、拆账变得更为简单,晚期为了可能解决各业务的分账以及权限管控等场景,职能团队别离创立了不同的 K8s 集群,给到对应的项目组,用于部署利用零碎,但集群的资源利用率并没有失去无效晋升。同时,随着业务的一直扩大,这些集群波及到不同部门、不同环境,版本已存在越来越大的差别。在利用部署时,因为管理人员的程度参差不齐,导致在日常运维及问题诊断时,非常耗时。
- 资源分配不够智能:业务类别千差万别,有 B 端经营治理,也有 C 端的高并发利用,尽管 K8s 提供了资源分配的形式,然而对于运维公布人员来说,难以预判将来利用的实在流量状况,以至于难以正当调配 CPU / 内存资源大小,仅依照教训参数对立给出默认规格配置。
- 如何实现长期主义:在制订策略时,咱们放心此类静止式的架构优化流动,即使投入了大量的人力老本,也只能在短期内使得资源管理“看上去很美”,而随着业务架构的一直调整,又或者因优化资源产生稳定性影响之后,对将来继续经营治理资源的信念将会消减,从而使得本来的老本投入的边际收益趋向于零。
业务指标
为应答云资源治理方面的有余,以及不同云平台的能力差异,咱们曾思考过是否须要建设一套 CMP 多云治理平台,对所波及到的云平台及账号对立治理。然而在评估是否要立项时,咱们认为云原生时代下“以资源为核心”的多云治理理念,难以满足咱们对于利用架构设计的期待。这种治理形式,不仅开发成本极高,还须要适配多个云厂商的不同接口,并且对于资源管理的意义并没有设想中的大,只是解决了一部分资源开明创立的工作,但这并非是云原生环境下利用治理的外围场景及工作。
极氪以后的基础设施架构次要是以 K8s 集群为底座,这意味着只有可能治理好这些集群,便可能治理好资源,从而为下层的业务零碎提供更大的价值。于是,咱们在设计资源管理计划时,彻底摈弃了 CMP 的以资源为核心的多云资源管理理念,投向了聚焦于云原生基础设施的治理这一方向。
平台技术团队将此次在资源管理域的我的项目指标定义为:老本可见、用量可控、配置可管,而以后须要解决的问题包含:
- 老本洞察与剖析:设计更为精细化的老本均摊模型,看清各业务的老本收入状况,同时为不同业务提供 Pod 资源利用率的智能剖析,辅助运维部署工程师在利用公布时,正当设置资源规格;
- 配置基线查看:针对现有部署脚本配置合规性问题,做基线查看,确保调整优化后的配置可能满足日常监控、故障自愈等场景;
- 收敛 K8s 集群数量:在不影响业务的状况下,对局部业务量较小的闲散 K8s 集群进行合并,收敛集群数量,升高架构复杂度及治理老本;
- 基础设施无状态化:思考到将来的出海业务可能部署在以后未笼罩的云厂商,咱们心愿以 K8s 作为规范技术底座,将基础设施尽可能做到无状态化,在利用公布过程中,仅须要改变大量参数即可实现利用的上线工作。
计划选型
老本摊销
因为极氪以后大多数的利用部署在阿里云,基于二八准则,咱们首先调研了对于阿里云 ACK FinOps 的解决方案。对于极氪的以后的基础设施现状来说,ACK FinOps 套件是一个不错的抉择,其别离蕴含了集群、命名空间(Namespace)、节点池和利用四个维度的老本剖析计划。
借助于命名空间和利用维度的老本剖析,这种基于理论资源用量的分账逻辑,使得账单摊派不再局限以服务器为单位,从而也为将来 K8s 集群数量收敛,提供了必要的能力反对。
但在云原生的场景下,针对容器级别的老本摊销,须要思考更多维度的业务场景。举例来说,一台 4C32G 的服务器,资源被调配进来 3C/8G,那么这个时候,CPU 资源影响了这台服务器残余资源的瓶颈,反之亦然。此外,K8s 的 pod 资源模型反对 request、limit 两个维度的资源分配,而影响到调度资源的则是 request。对于一些被设置为 BestEffort 或是 Burstable QoS 等级,资源被超卖的节点来说,难以齐全基于某个指标去判断逻辑合理性。
ACK FinOps 的老本摊派模型为咱们提供了更丰盛的抉择,别离可能提供基于 CPU、内存单维度资源摊派模型和权重混合资源摊派模型等多种不同的逻辑实现。
单维度资源摊派模型的劣势在于解释成本低,Pod 老本的计算逻辑大体为:
Pod 老本 =(Pod 申请资源(Request)/ node 资源总量)*node 节点单价即可。
业务团队仅需为理论使用量付费,当 K8s 集群规模较大时,未被调配的残余闲置资源数越少,则也能侧面阐明云平台团队治理能力的体现。
对于权重混合资源摊派模型,实质上要解决的是在同一集群内,同时充斥了多样化的业务场景及开发技术栈。例如,对于一台 4C8G 的服务器,同时部署一个 1C6G 的服务和一个 2C1G 的服务,则这个应用,无论基于内存还是 CPU 的申请资源作为老本摊销的根据,均显著不合理。
在调研完了两种不同的摊派模型之后,思考到极氪以后业务开发语言次要为 Java 技术栈的现状,利用 Pod 会向集群申请大量内存资源,导致内存的调度水位升高。尽管内存的单位成本较 CPU 而言,便宜的多,但对于该业务场景而言,内存成为了集群是否须要被扩容的瓶颈点。同时,不同于 CPU 的 QoS 存在显性的超卖,内存资源的利用率简直约等于分配率,因而在此场景下,咱们应用繁多资源模型作为部门的老本摊派模型。
另一个问题是老本分账的颗粒度,将来整体平台架构的布局在实现了集群数量的收敛之后,会依照零碎维度在命名空间层面做逻辑隔离,通过命名空间的分账形式可能满足业务需要。
$$
ACK 老本洞察
$$
至此,云原生利用容器老本摊派的整体策略方向根本确定下来。
资源水位剖析
对于利用容器资源配额的优化,次要集中在 CPU 和内存两个方面:
- CPU 资源优化:若只是调整 Pod 的 QoS 等级,将 CPU 的 Request 值做出调整,尽管短期可超卖更多的 CPU 资源用于资源部署,但对于线上利用来说一旦工作负载过高,易于呈现资源争抢,以致服务被驱动的状况。
- 内存资源优化:因为 Java 的内存资源在启动 JVM 时会被长时间占用,随着利用运行工夫减少,一些代码品质较差的服务会逐步呈现内存未被及时回收的状况,从而导致 OOM 内存溢出。为防止 Pod 内存资源分配资源有余导致业务受损,工程师在启动 Pod 时设置的 Request/limit,通常会比 JVM 的堆栈内存要高出肯定的比例。优化内存的同时,也须要思考到业务潜在的 OOM 危险。
而容器服务 ACK 自带收费的老本套件 ack-koordinator 提供的资源画像能力,可能帮忙咱们长周期、持续性的辨认到集群内未被正当应用的资源,并给出推荐值作为参考根据,实现容器粒度的资源规格举荐,升高容器配置的复杂度。
ACK 资源画像会为工作负载的每个容器资源规格生成画像值,通过比照画像值(Recommend)、原始资源申请量(Request),以及画像配置的资源耗费冗余(Buffer),资源画像控制台会为工作负载生成操作的提醒,例如对资源申请进步或升高(即升配或降配)。若工作负载有多个容器,则会提醒偏差幅度最大的容器。
当画像值大于原始资源申请量:示意容器长期处于资源超用状态,存在稳定性危险,应及时进步资源规格,控制台晋升倡议升配,防止将来运行过程中的稳定性危险。而当画像值小于原始资源申请量时,则示意容器可能有肯定水平的资源节约,能够升高资源规格。
其底层算法会继续一直地收集容器的资源应用数据,取 CPU 和内存的聚合统计值生成画像后果,并针对工夫因素采纳了周期衰减算法;在聚合统计时,会给较新的数据采样点调配更高的权重,同时参考了容器呈现 OOM 等运行状态信息,进一步提高了利用画像给出推荐值的准确性。最初,是从资源的可继续治理的视角登程,咱们心愿可能将现有的公布平台与资源画像的性能买通,做到主动举荐配置调优,从而躲避将来业务量变动后,响应调整绝对滞后的弊病。因而在同阿里云的云原生利用平台团队提出该需要之后,很快失去了响应,目前已可能提供 API 的能力,与极氪现有公布流程联动。
$$
利用公布资源配额优化
$$
资源管理
多云环境下的 K8s 多集群治理,最初是对于如何解决极氪分布式云现状下的资源管理问题。因为咱们以后存在着公有云和 IDC,不同的环境下的计费模型存在比拟大的差别,财务模型也各不相同,这些都对多云运管立体的老本剖析能力提供了更多的挑战。
为此,咱们抉择了 ACK One 对立治理极氪以后波及到的数十个线上、线下 K8s 集群,以便在业务倒退过程中,为工程师治理集群带来更好的一致性的云原生利用治理体验。ACK One 是阿里云面向混合云、多集群、分布式计算等场景推出的分布式云容器平台,可能对立治理阿里云上、边缘、部署在客户数据中心以及其余云上的 Kubernetes 集群,并简化集群治理界面,从而灵便地依据本身业务和数据管控等需要。
联合 ACK One,阿里云容器服务 FinOps 套件提供了对立的云服务厂商的账单与询价接入与默认实现,反对支流的云服务厂商、IDC 自建机房的费用数据的接入,并通过统一的云原生容器场景老本摊派与估算模型,进行老本治理。此外,还提供了多集群、多环境的对立集群治理、对立资源调度、对立数据容灾和对立利用交付能力,也提供了对立的财资治理能力。
$$
ACK One 多集群治理利用场景
$$
最初,ACK FinOps 套件可能下发至线下及混合云环境,非常适合剖析云下 IDC 节点及利用的老本。因为 ACK FinOps 无奈获取线下以及其它云厂商的单位价格,为此,ACK One 为每个节点提供基于标签 Label 的形式,配置独自价格的相干配置计划。
kubectl label nodes node.kubernetes.io/price-per-day="100"
在抉择 ACK One 作为极氪云原生 K8s 多集群治理解决方案时,除了对于老本管控以外,配置检查和备份治理等性能也是咱们以后所重点关怀的。以配置查看为例,基于阿里云容器平安最佳实际,可能一键收费查看多云 / 混合星散群利用配置平安危险,保障多云 / 混合星散群容器利用的安全性、有效性和稳定性,并及时发现了早前的存量利用配置潜在的平安稳定性隐患。
利用 Pod 配置查看包含:
- 安全性:特权参数配置,高危内核 Capabilities,root 用户启动,未开启 TLS 的 Ingress,匿名用户权限绑定等。
- 有效性:CPU / 内存资源配额限度缺失等。
- 稳定性:liveness 和 readiness 探针缺失,单正本启动等。
建设成绩
通过阿里云容器服务提供的 ACK One 多集群治理、云原生资源画像等性能,极氪得以对线上及线下近 30 套 K8s 集群实现对立治理。获得了多方面的实质性的业务成绩:
- 高效的资源利用
通过利用资源画像功能分析数千个 Pod 的资源应用状况,企业辨认并查看了闲暇资源、找到了潜在的资源配置问题。在修复这些问题后,部署策略失去优化,从而为企业缩小了近 25% 的资源用量。这一动作每年帮企业节俭了数百万元的 IT 老本投入,并显著进步了资源利用效率。
- 零碎稳定性和业务连续性的保障
联合业务需要,企业制订了多种备份策略。针对这些策略,在 ACK One 平台上执行数据备份和复原操作。这一做法进步了企业的业务连续性和数据安全性,进一步增强了零碎的稳定性。
- 跨云和混合云资源的集中管理
ACK One 多集群治理性能使得企业可能在阿里云容器治理平台上实现对多个 K8s 集群的集中管理和保护,包含线上和线下环境。这种对立的治理架构升高了企业操作复杂性,进步了工作效率。
- 麻利的业务拓展和疾速响应
通过优化 K8s 集群和资源配置,企业可能在业务需要变动时更加敏捷地进行资源调整及扩大。这种弹性架构确保了企业可能在市场环境变动时迅速调整策略,进步竞争力。
- 利用公布策略的优化
借助 ACK One 的剖析性能,企业得以优化利用公布策略,从而使零碎更加稳固和高效。企业不仅升高了故障率,还开释了更多的工夫和精力来关注外围业务的翻新和倒退。
- 晋升团队技能和单干效率
在应用 ACK One 进行对立治理的过程中,企业外部团队对于 K8s 集群和相干产品技术的把握水平逐步进步。此外,因为各个职能团队之间在 ACK One 平台进行合作,也进步了团队的单干效率。
将来瞻望
明天,云计算曾经成为全社会的数字经济基础设施,而云原生技术正在粗浅地扭转企业上云和用云的形式。极氪汽车作为新能源汽车的头部企业之一,在过来两年的高速倒退过程中,围绕着云原生基础设施架构做了大量的技术、架构以及产品的要害选型,并整体落地了微服务、K8s、DevOps 等云原生代表技术及能力。与此同时,在分布式云技术设施架构的大背景之下,也面临了多重的挑战,也踩过不少的坑。
云原生时代的 FinOps 老本治理是一个很大的话题,FinOps 基金会将其定义为老本剖析(Inform)、老本优化(Optimize)、继续经营(Operate)三个阶段。尽管前两个阶段可能更加显性的达到疾速降本的指标,但如若不坚持不懈的精细化管控资源,很快便会回到原样,只有将资源管理纳入到利用公布流程管控之中,能力真正管好云,用好云。面向未来,确保基础设施架构具备可继续倒退的能力,赋能业务以更加稳固、高效、低成本的形式运行,充分发挥云的微小价值,开释技术红利,仍有更长的路要走。
作者:极氪汽车吴超
点击立刻收费试用云产品 开启云上实际之旅!
原文链接
本文为阿里云原创内容,未经容许不得转载。