【QCon】精华内容上线92%,全面覆盖“人工智能+”的典型案例!>>> 了解详情
写点什么

已来到 “后云原生时代” 的我们,如何规模化运维?

  • 2022-12-14
    北京
  • 本文字数:3821 字

    阅读完需:约 13 分钟

已来到 “后云原生时代” 的我们,如何规模化运维?

作者 | 李大元(Kusion 项目负责人)


后云原生时代


距离 Kubernetes 第一个 commit 已经过去八年多了,以其为代表的云原生技术早已不再是什么新技术,而是现代化应用的“标配”。现代化应用依赖的基础服务远不止 Kubernetes 一种,稍微复杂点的应用往往会同时使用到 Kubernetes 生态云原生技术、IaaS 云服务、企业内部自建系统等各种异构基础设施,可能还会有多云、混合云的部署需求,我们已经进入到了 ”后云原生时代”,只针对 Kubernetes 的运维工具早已不能满足我们的诉求。



更复杂的是,在企业内部,这些服务一般是由不同团队维护的,一次规模化运维需要多个团队的成员互相配合才能完成,但是 App Dev,Platform Dev,SRE 各个团队之间缺少高效的协作方式。技术自身的复杂性加上低效的团队协作,使得 “后云原生时代” 的规模化运维难度有了指数级的提高。


规模化运维的问题一直都在


复杂异构基础设施的规模化运维,这并不是后云原生时代特有的问题,自分布式系统诞生以来,一直都是一个难题,只是在后云原生时代,这个问题变得更加困难。十多年前业界提出了 DevOps 理念,无数企业基于此理念构建了自己的 DevOps 平台,希望解决此问题,但在实际落地的过程中往往不尽人意,Dev 团队和 Ops 团队之间如何合作?职责如何划分?几十人的平台团队,如何支持几万工程师的运维诉求?底层基础设施复杂多样,能力日新月异,如何快速让一线 Dev 享受到技术红利?这些问题一直没有得到很好的解决,最近又有人提出了 DevOps 已死,Platform Engineering 才是未来的说法。抛开概念定义,无论是 DevOps 还是 Platform Engineering,本质上都是企业规模化运维这同一命题下的不同理念,我们更需要的是一个符合技术发展趋势,能解决当前问题的解决方案。


传统架构不再适用


在传统的运维思路中,解决上述问题的方法一般是构建一个 PaaS 平台,例如我们早期的蚂蚁 PaaS 平台,他是一个 Web 控制台,有 UI 界面,用户(通常是 App Dev 或 SRE)通过 UI 交互可以完成诸如发布、重启、扩缩容等操作。在技术实现上大体可以分为三部分,一个前端系统,提供用户交互的能力,作为系统入口;中间是一个后端系统,对接各个基础设施;底层是各个基础设的 API。这种架构运行了近十年,一直运行的很好,既有用户友好的交互界面,又可以屏蔽基础设施复杂性,而且各个团队之间还职责分明,但是到了如今后云原生时代,这种架构不再适用,暴露出有两个致命缺点,“费人”、“费时”



举一个常见的例子,网络团队为其负责的 Loadbalancer(负载均衡器)开发了一种新的负载算法,需要提供给用户使用。在上述架构下,整个工作流程是这个样子:


  1. 网络团队开发好能力,提供出 API

  2. PaaS 后端通过编码对接底层 API,进行互联互通,屏蔽复杂性,提供面向用户的更高级别 API

  3. PaaS 前端根据新功能修改 UI,利用后端 API 把能力透出给最终用户


这里存在一个问题,即使一个再小的功能,也需要 PaaS 后端和前端修改代码,整个流程下来最快也要一周才能上线,而且涉及的基础设施团队越多,效率越低。这个问题在十年前并不算是一个问题,但是在今天就是一个很大的问题,一个后云原生时代的现代化应用,使用三个云原生技术(Kubernetes + Istio + Prometheus),两个云服务(Loadbalancer + Database),一个内部自建服务,已经是一个很常见的形态了,复杂应用只会依赖的更多。如果每个基础设施都由 PaaS 团队硬编码对接一遍,PaaS 团队的人再扩大十倍也不够用。



“费人”讲完了,我们再看看“费时”的问题。上面例子里的一个小功能,需要进行两次跨团队的协作,一次基础设施和 PaaS 后端,另一次是 PaaS 后端与 PaaS 前端。团队协作是一个很难的问题,有时候比技术本身还要难。应用的架构已经很复杂了,如果要做一次规模化运维,一次运维 100 个应用,这要和多少个团队沟通协作?要花费多少时间?没有好的协作机制,这就变成了一个不可能完成的任务。


探索与实践


我们在蚂蚁集团内部进行了近两年的探索,kustomize、helm、argoCD、Terraform 这些常见的工具我们都实践过,甚至还为一些工具自研了一些辅助系统,但结果并不尽人意。这些工具要么太局限于 Kubernetes 生态,运维不了其他类型的基础设施,要么就是支持了异构基础设施,但对于 Kubernetes 生态支持的不友好,无法发挥出云原生技术的优势,而且只是运维工具的升级对于团队协作效率几乎没有提升,我们需要一套更加体系化的方案。


回到问题本身,针对“费人”、“费时”的问题,我们提出两个思路:


  1. 能否不让 PaaS 做中转,而是由 App Dev 通过一种高效自助的方式,使用到互联互通的各种基础设施能力?

  2. 能否构建一个中心化的协作平台,用技术的手段规范大家的行为,标准化的进行沟通?


从技术的角度来看,PaaS 平台需要提供灵活的工具链和工作流,基础设施所有能力都通过模块化的方式暴露出来,App Dev 利用这些平台的基本能力,自己组合、编排来解决自己的问题,过程中不需要平台层的参与。并且整个过程中涉及的所有团队,都使用统一的语言和接口进行交流,全程无需人工参与。


我们的实践



经过在蚂蚁内部 PaaS 平台近两年的探索与实践,沉淀出一套端到端的完整方案, 取名为 KusionStack,目前已经开源。试图从统一异构基础设施运维与团队协作两个角度解决传统 PaaS “费人”、“费时”的问题。整个体系主要分为三个部分:


  1. Konfig:Git 大库,是多团队协作的中心化平台,存放着各个团队的运维意图

  2. KCL:蚂蚁自研的配置策略 DSL,所有团队间交流的工具

  3. Kusion:KusionStack 引擎,负责所有的运维操作


Platform Dev 通过 KCL 定义好基础能力模型,App Dev 通过 import、mixin 等语言特性在应用配置模型(AppConfig)里复用这些预定义好的能力,快速在 Konfig 里描述运维意图。AppConfig 是一个精心设计过的模型,只暴露 App Dev 需要关心的属性,屏蔽基础设施的复杂性。


永远不要低估基础设施的专业性与复杂性,即使已经成为云原生技术标准的 Kubernetes,对普通用户来说依然有很高的门槛,一个 Deployment 就有几十个字段,再加上自定义的 labels、annotations 就更多了,普通用户根本无法全部理解。或者说普通 AppDev 不应该去了解 Kubernetes,他们需要的只是发布,甚至不需要关心底层是不是 Kubernetes。


AppConfig 经过编译后会生成多个异构基础设施的资源,通过 CI、CLI、GUI 等方式把数据传输给 KusionStack 引擎。引擎是整个体系的核心,负责所有运维操作,是运维意图真正生效到基础设施的地方。他通过统一的方式对接异构基础设施,并对这些资源进行校验、编排、预览、生效、观测、健康检查等一系列操作。


值得一提的是,整个过程对运维 Kubernetes 资源非常友好。使用过 Kubernetes 的同学都知道,由于其面向终态、自调和的特点,apply 成功并不代表资源已经可以用,需要等资源调和成功后才能提供服务,如果调和失败了,还需要登陆到集群中,通过 get、describe、log 等命令查看具体报错,整个过程十分繁琐。我们通过技术的手段对这些操作进行了简化,把调和过程中的重要信息以用户友好的方式透露出来。下面的动图是一个简单的示例,当命令下发后,可以清晰的看到所有资源及其关联资源调和过程,直到资源真正的可用。



整个体系有如下几个特点


  1. 以应用为中心


  • 应用全方位配置管理,包括计算、网络、存储等所有与应用有关配置

  • 应用全生命周期管理,从第一行配置代码到生产可用


  1. 统一运维“后云原生时代”应用的异构基础设施

  • Kubernetes 友好的工作流,为 Kubernetes 资源提供可观测性、健康检查等高阶能力,释放云原生技术红利

  • 复用 Terraform 生态,统一的工作流运维 Kubernetes、Terraform 多运行时资源


  1. 规模化协同平台

  • 灵活的工作流,用户可利用平台的基本能力,自己组合、编排来解决自己的问题

  • App Dev 和 Platform Dev 关注点分离,底层能力迭代无需平台介入,直接供 App Dev 使用

  • 纯客户端方案,风险“左移”,尽早发现问题


一切才刚刚开始


这套体系经过近两年的探索,已广泛应用在蚂蚁多云应用交付运维,计算及数据基础设施交付,建站运维,数据库运维等多个业务领域,目前 400+ 研发者直接参与了 Konfig 大库代码贡献,累计近 800K Commits,其中大部分为机器自动化代码修改,日均 1K pipeline 任务执行和近 10K KCL 编译执行,全量编译后可产生 3M+ 行的 YAML 文本。


不过,这一切才刚刚开始,后云原生时代也才刚刚到来,我们把这套系统开源的目的也是希望邀请业内各方的力量,一起构建一个符合技术发展趋势,能真正解决当下企业规模化运维这个难题的解决方案。蚂蚁 PaaS 团队还有很多经过内部规模化验证的技术沉淀,后续也会开源出来,只有我们远远不够,真诚的邀请大家一起来玩。


作者简介


李大元(花名:达远),Kusion 项目负责人,来自蚂蚁集团 PaaS 核心团队,PaaS IaC 基础平台负责人。


Ref


Github:欢迎 Star⭐️



官网:https://kusionstack.io


PPT:KusionStack:“后云原生时代” 应用模化运维解决方案(https://kusionstack.io/blog/2022-kusionstack-application-scale-operation-solution-in-the-post-cloudnative-era/)


今日好文推荐


重磅!阿里开源自研高性能核心搜索引擎Havenask


程序员离职后为泄私愤远程锁公司服务器硬盘;前程无忧宣传语嘲讽“996”职场人;Twitter 开源工作停摆| Q资讯


再不重视软件开发工具就晚了


“睡车间”、削减一切,马斯克为SpaceX定制的文化,不能照搬到互联网公司


2022-12-14 20:034895

评论 5 条评论

发布
用户头像
我是文章的作者,感兴趣的可以加微信:SparkYuan0929 进一步交流~
2022-12-15 22:10 · 上海
回复
用户头像
咱感觉看起来是造轮子,目标指向OKR
2022-12-15 09:22 · 江苏
回复
您说的轮子,具体是指哪个产品?
2022-12-15 09:27 · 上海
回复
比如kubevela
2022-12-15 18:16 · 广东
回复
Kubevela是一个很优秀的项目,有广泛的生态,我们私下也有交流,也在规划合作,和他的区别主要两个方面吧

在解决的问题方面:
1. Kubevela 来源于 OAM,重点在于 App 运维。KusionStack 除 App 运维外,还关注计算及数据基础设施交付,建站运维,数据库运维等非 App 运维领域

2. Kubevela 的定位类似于一个CD系统,KusionStack目前是三个系统组合在一起的,包含Konfig配置管理,KCL语言,Kusion运维引擎三个部分,CI/CD的内容都有包含


技术架构上

1. KusionStack 在 K8s 之上,是一个纯客户端方案,风险“左移”,Kubevela是部署在K8s里的服务化方案,各有优劣

2. 还有一些其他技术实现上的区别,感兴趣的话可以github上看看,就不展开了
展开
2022-12-15 21:54 · 上海
回复
没有更多了
发现更多内容

模块5-微博评论高性能高可用计算架构分析

小何

「架构实战营」

超基础的机器学习入门-原理篇

凹凸实验室

机器学习 AI 低代码平台

后端程序员福利套餐,22份资料合集,你能想到的关键技术,都在这里

奔着腾讯去

c++ golang Linux 音视频 学习资料

新晋 CNCF 沙箱项目 OpenClusterManagement 带来了它的最新特性

阿里巴巴中间件

阿里云 中间件 KubeVela cncf OCM

架构实战训练营|课后作业 模块 5

Geek_6bb688

SpringCloudAlibaba微服务技术栈精讲大合集

XiaoLin_Java

内容合集 签约计划第二季 技术专题合集

解密 Dubbo 三大中心的部署架构

阿里巴巴中间件

阿里云 微服务 云原生 dubbo 中间件

Android C++系列:Linux进程间关系

轻口味

c++ android 28天写作 12月日更

架构实战营模块五作业

渐行渐远

架构实战营

11 张图 | 讲透原理,最细的 Eureka 增量拉取

悟空聊架构

悟空聊架构

硬核图解 SpringCloud 源码系列

悟空聊架构

SpringCloud 悟空聊架构 内容合集 签约计划第二季 技术专题合集

说出你和「云原生」的故事,获得年度云原生顶级盛会通行证

阿里巴巴云原生

阿里云 开源 云原生 投稿

邀请函|2021 云原生实战峰会,邀请您免费现场参会报名

阿里巴巴云原生

阿里云 云原生 峰会

模块五作业

侠客行

架构实战营 「架构实战营」

趣谈“分布式链路追踪“组件发展史

悟空聊架构

分布式 链路追踪 28天写作 悟空聊架构 12月日更

linux之cp强制复制文件

入门小站

Linux

车用能源的终极:氢能车落地普及还要多久?

脑极体

一场关于元宇宙公司之死的剧本杀

脑极体

快速云原生化,从数据中心到云原生的迁移最佳实践

阿里巴巴云原生

阿里云 云原生 实践 迁云方案

四步轻松玩转微服务敏捷开发

阿里巴巴中间件

阿里云 微服务 云原生 敏捷开发 中间件

RocketMQ这样做,压测后性能提高30%

中间件兴趣圈

RocketMQ 性能 Apache RocketMQ

未来,区块链将在这些领域广泛应用!

CECBC

还在担心流量防护问题?Sentinel来帮你!

XiaoLin_Java

SpringCloud Alibaba 流量防控 签约计划第二季

模块5作业

Asha

32 K8S之DaemonSet/Job/CronJob控制器

穿过生命散发芬芳

k8s 28天写作 12月日更

040022-week5-design

InfoQ_70156470130f

[Pulsar] 设置JWT认证

Zike Yang

Apache Pulsar 12月日更

6000字 | 深入理解 Ribbon 的架构原理

悟空聊架构

悟空聊架构

资产数字化的当下,数据隐私危如累卵

CECBC

架构训练营第3期模块5作业

吴霏

架构训练营

互联网公司如何塑造一支有创业精神的技术团队?

阿里巴巴中间件

创业 阿里云 中间件

已来到 “后云原生时代” 的我们,如何规模化运维?_开源_李大元_InfoQ精选文章