阿里巴巴超大规模Kubernetes基础设施运维体系揭秘
一 序言
第一次全面统一调度:电商、搜索、odps离线和蚂蚁业务全面上ASI统一调度架构,整个业务核数达到了惊人的数千万核。
第一次将搜索业务“无感知”平滑迁移到ASI:近千万核的业务,业务无感的搬到ASI(但是我们却经历了很多个不眠之夜)。
ASI场景的K8s单集群规模超过万台节点,数百万核,超越K8S社区的5000台规模,不断优化大规模集群的性能和稳定性。
中间件服务第一次用云产品架构支持集团业务:中间件基于ASI公共云架构,将中间件服务平滑迁移到云上,用云产品架构支持集团业务,实现“三位一体”。
一次正常的Kubernetes大版本升级流程,在升级Kubelet时把一个集群近千台业务POD全部重建;
一次线上非标操作,将大批量的vipserver服务全部删除,幸亏中间件有推空保护,才没有对业务造成灾难性影响;
节点证书过期,由于节点自愈组件故障情况误判,并且风控/流控规则判断也有误,导致自愈组件误将一个集群300+节点上的业务全部驱逐;
二 ASI 技术架构形态
三 ASI全托管运维支撑体系
元集群(KOK架构底层K):用于承载Kubernetes业务集群的核心管控组件,将业务集群管控容器化部署,能保证部署方式更加标准,部署效率也会大大提升。
Control-Plane:就是业务集群核心管控4大件:kube-apiserver/kube-controller-manager/kube-scheduler 和 etcd 集群。
Add-Ons:Serverless核心功能组件,调度增强组件(统一调度器)、网络组件、存储组件、Workload组件(OpenKruise)、coredns和其他一些旁路组件。
Data-Plane:节点管控组件,比如containerd、kubelet,kata 等,还有一些其他节点上的插件。
统一变更管控:这个是我们从ASI的第一天就开始建设的系统能力,因为从阿里巴巴技术发展过程中吸取的经验教训来看,很多重大故障都是由于变更不规范、没评审、没风险卡点导致;
集群运维管控:ACK会提供K8S集群全托管的标准产品能力,但是如何/何时做规模化升级的编排、验证、监控是我们需要考虑;并且我们还需要建设合理的备容机制,保证集群的稳定性;
ETCD运维管控:ETCD也是完全基于ACK的提供的全托管ETCD Serverless产品能力,我们会和ACK同学一起共建ETCD性能优化、备容来更好的服务ASI的超大规模集群;
组件运维管控:ASI运维体系非常核心的能力建设,Serverless全托管服务,最核心的就是各个核心组件都要有相应的研发团队进行功能扩展和运维支持。这样如何定义研发同学的研发模式,确保日常运维的稳定性和效率是ASI产品能支持大量业务的关键。所以在ASI成立之初(2019年支持集团业务上云)我们就建立起了ASI组件中心,逐渐定义和优化ASI核心组件的研发、运维模式;
节点全托管运维管控:这块是非常多云产品团队希望容器服务提供的能力,特别业务产品团队,他们对基础设施非常不了解,希望有团队能帮忙将节点运维全托管掉。节点运维能力也是ASI在支撑阿里集团过程中非常重要的能力沉淀,我们也将这部分经验输出到售卖区,并继续不断优化。云上最大的特点就是资源弹性,ASI在售卖区也为云产品用户提供了节点极致弹性能力。
1-5-10能力建设:云上用户有一个非常重要的特点,对故障容忍度非常低。这也给ASI带来了非常大的挑战,如何及时发现、排查和恢复问题,是我们一直要不断探索的。
资源运营:备容,成本优化一直都是基础设施服务要解的问题,我们既要确保服务运行稳定(比如不OOM,不出现CPU争抢),又要降低成本,更要降低云产品的服务成本。
1 集群全托管运维能力
所有变更是不是都有变更风险管控?
这么多的集群,这么多的节点(ASI单集群已经超过了上万节点),怎么做灰度稳定性风险最小?
黑屏变更无法杜绝,如何把控风险?
单个运维动作虽然不难,但是我们经常面临的是多个运维操作组合的复杂操作,系统如何方便的去编排这些运维操作?
统一变更风险管控
变更灰度能力
更新不及时:新增了一个集群,但是没有通知相关同学,没有加到对应的pipeline;
自动适配能力不够:ASI新接入了一个云产品,需要人工新加一条pipeline,经常更新不及时;
维护成本高:随着业务越来越多,各个研发owner要自己维护非常多条pipeline;
扩展能力不足:pipeline顺序不能动态调整,ASI支持云产品之后,有一个非常重要的需求就是按照GC等级进行灰度,静态pipeline完全无法支持。
组件灰度发布的时候,通过Cluster-Scheduler筛选的集群范围肯定不会漏集群;
集群发布顺序按照GC等级来进行权重设置,也能根据集群的规模数据来动态调整集群的权重;
研发发布的时候,不需要再维护多条静态pipeline,只需要选择组件发布范围,会自动进行集群发布顺序编排。
集群webshell工具
权限精细化管控:权限与用户绑定,有效期、权限范围严格管控;
安全:不会给用户提供证书,所以不会出现证书泄漏的问题;
审计:所有操作都有审计;
风控:检测危险操作,发起在线审批之后再运行操作。
变更编排能力
PipelineController:维护任务间的依赖信息 TaskController:任务状态信息维护
TaskScheduler:任务调度 Task/Worker:任务执行
小结
2 组件全托管运维能力
IaC组件模型:利用K8S声明式的设计,来将所有ASI组件类型的变更全部改为面向终态的设计;
统一变更编排:组件变更最重要的是灰度,灰度最重要的是集群/节点灰度顺序,所有组件都需要变更灰度编排;
组件云原生改造:原来节点基于天基的包变更管理改造成K8S原生Operator面向终态的设计,这样节点组件实现基本的组件变更通道、分批、暂停等能力。由上层的Ops系统来实现组件版本管理、灰度变更编排等。
3 节点全托管运维能力
节点全生命周期定义
节点生产前:售卖区比较复杂的场景是每一个云产品都有一套或多套资源账号,还有很多需要自定义ECS镜像。这些都需要在新业务接入时进行详细定义;
节点导入时:集群节点导入时需要建设节点创建/扩容/导入/下线等操作;
节点运行时:节点运行时往往是问题最多的阶段,这块也是需要重点能力建设的阶段,如节点组件升级、批量执行脚本能力、cve漏洞修复,节点巡检、自愈能力等等;
节点下线时:在节点成本优化、内核cve漏洞修复等场景下,都会需要节点腾挪、下线等规模化节点运维能力;
节点故障时:在节点故障时,我们需要有节点问题快速探测能力、问题诊断能力和节点自愈能力等。
节点能力建设大图
节点弹性
管控层面:通过控制并发度,可以快速完成几百台ECS的弹性任务处理;
组件部署优化:
daemonset组件全部修改为走Region vpc内部地址拉取; rpm组件采用ECS镜像内预装模式,并进行节点组件部署序编排来提升节点组件安装速度; 最后就是yum源带宽优化,从原来走共享带宽转为独占带宽模式,避免被其他rpm下载任务影响我们节点初始化。
业务初始化:引入dadi镜像预热技术,节点导入过程中可以快速预热业务镜像,目前能达到10g大小镜像的业务拉起只需要3min左右。
4 1-5-10 能力建设
风控:在任何场景下,ASI都应该具备踩刹车的能力; KubeProbe:快速探测集群核心链路稳定性问题;
自愈:庞大的节点规模,非常依赖节点自愈能力。
风控
KubeDefender限流:对一些核心资源,比如pod、service、node,的操作(特别是Delete操作)按照1m、5m、1h和24h这样的时间维度设置操作令牌。如果令牌消耗完就会触发熔断。
UA限流:按时间维度设置某一些服务(UserAgent来标识)操作某一些资源的QPS,防止访问apiserver过于频繁,影响集群稳定性。UA限流能力是ACK产品增强能力。
APF限流:考虑apiserver的请求优先级和公平性,避免在请求量过大时,有一些重要控制器的被饿死。K8S原生增强能力。
KubeProbe
1)中心架构
2)常驻Operator架构
自愈
诊断、自愈规则更加丰富:目前的诊断、自愈规则很多场景下都没有覆盖,需要不断优化覆盖,更多节点故障场景;
基于节点池的精细化的自愈风控、流控:节点自愈的前提是不能让现状变的更糟,所以我们需要在做自愈时,做更加精确的判断;
节点自愈能力与上层业务打通:不同业务形态,对节点自愈的要求不同。比如Flink业务都是任务类型,遇到节点问题需要我们尽快驱逐业务,触发任务重建,最怕的就是任务“半死不活”;中间件/数据库业务都是有状态服务,不允许我们随便驱逐业务,但是我们如果把自愈能力与上层业务逻辑打通,就可以做到将节点故障上透给业务,让业务来决策是否要自愈,以及业务如何自愈。
四 未来展望
五 求贤若渴
欢迎对云原生、kubernetes、SRE、容器 有兴趣的同学,您也可以加入我们,一起参与精彩的云原生激情澎湃未来。联系 [email protected]。
Cassandra数据库入门与实战
Apache Cassandra是一套开源分布式NoSQL数据库系统。它最初由Facebook开发,用于储存收件箱等简单格式数据,2008年开源后,由于Cassandra良好的可扩展性,被Digg、Twitter等知名Web 2.0网站所采纳,成为了一种流行的分布式结构化数据存储方案。和其他数据库比较,Cassandra有支持线性扩展、可以处理大量数据集、易于大规模部署、高度容错等特点,因此也常年的权威数据库榜单DB-Engines上排名前十,宽表领域排名第一。
为了更好地将阿里云的数据库技术能力回馈给开发者,和百万开发者共同成长。阿里云联合Cassandra商业公司DataStax打造了本课程,邀请中美知名数据库技术专家共同授课,带你上手Cassandra,训练营涵盖Cassandra分布式数据库、大数据分析、AI等多个前沿领域,让我们一起探索云计算与AI浪潮下的下一个职业风口,也让你在MySQL、PG、MongoDB等数据库基础上,加持海量扩展的分布式数据库技能。
关键词
问题
云原生
业务
技术
最新评论
推荐文章
作者最新文章
你可能感兴趣的文章
Copyright Disclaimer: The copyright of contents (including texts, images, videos and audios) posted above belong to the User who shared or the third-party website which the User shared from. If you found your copyright have been infringed, please send a DMCA takedown notice to [email protected]. For more detail of the source, please click on the button "Read Original Post" below. For other communications, please send to [email protected].
版权声明:以上内容为用户推荐收藏至CareerEngine平台,其内容(含文字、图片、视频、音频等)及知识版权均属用户或用户转发自的第三方网站,如涉嫌侵权,请通知[email protected]进行信息删除。如需查看信息来源,请点击“查看原文”。如需洽谈其它事宜,请联系[email protected]。
版权声明:以上内容为用户推荐收藏至CareerEngine平台,其内容(含文字、图片、视频、音频等)及知识版权均属用户或用户转发自的第三方网站,如涉嫌侵权,请通知[email protected]进行信息删除。如需查看信息来源,请点击“查看原文”。如需洽谈其它事宜,请联系[email protected]。