专业网站设计网站,wordpress多个single,WordPress评论楼层,公司网站如何做维护作者#xff1a;极氪汽车吴超 前言
2021 年#xff0c;极氪 001 迅速崭露头角#xff0c;仅用 110 天便创下了首款车型交付量“最快破万”的纪录。2022 年 11 月#xff0c;极氪 009 在短短 76 天内便率先完成了首批交付#xff0c;刷新了中国豪华纯电品牌交付速度的纪录…作者极氪汽车吴超 前言
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 的以资源为中心的多云资源管理理念投向了聚焦于云原生基础设施的管理这一方向。
平台技术团队将此次在资源管理域的项目目标定义为成本可见、用量可控、配置可管 而当前需要解决的问题包括
1. 成本洞察与分析 设计更为精细化的成本均摊模型看清各业务的成本支出情况同时为不同业务提供 Pod 资源利用率的智能分析辅助运维部署工程师在应用发布时合理设置资源规格
2. 配置基线检查 针对现有部署脚本配置合规性问题做基线检查确保调整优化后的配置能够满足日常监控、故障自愈等场景
3. 收敛 K8s 集群数量 在不影响业务的情况下对部分业务量较小的闲散 K8s 集群进行合并收敛集群数量降低架构复杂度及管理成本
4. 基础设施无状态化 考虑到未来的出海业务可能部署在当前未覆盖的云厂商我们希望以 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-day100在选择 ACK One 作为极氪云原生 K8s 多集群管理解决方案时除了对于成本管控以外配置检查和备份管理等功能也是我们当前所重点关心的。以配置检查为例基于阿里云容器安全最佳实践能够一键免费检查多云/混合云集群应用配置安全风险保证多云/混合云集群容器应用的安全性、有效性和稳定性并及时发现了早前的存量应用配置潜在的安全稳定性隐患。 应用 Pod 配置检查包括
安全性特权参数配置高危内核 Capabilitiesroot 用户启动未开启 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三个阶段。虽然前两个阶段能够更加显性的达到快速降本的目标但如若不持之以恒的精细化管控资源很快便会回到原样只有将资源管理纳入到应用发布流程管控之中才能真正管好云用好云。面向未来确保基础设施架构具备可持续发展的能力赋能业务以更加稳定、高效、低成本的方式运行充分发挥云的巨大价值释放技术红利仍有更长的路要走。
