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

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

图片

文|李大元 (花名:达远)

Kusion 项目负责人

图片

来自蚂蚁集团 PaaS 核心团队,PaaS IaC 基础平台负责人。

本文 4331 字 阅读 11 分钟

PART. 1 后云原生时代

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

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

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

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

PART. 3 传统架构不再适用

在传统的运维思路中,解决上述问题的方法一般是构建一个 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 个应用,这要和多少个团队沟通协作?要花费多少时间?没有好的协作机制,这就变成了一个不可能完成的任务。

PART. 4 探索与实践

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

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

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

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

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

PART. 5 我们的实践

图片

经过在蚂蚁内部 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.以应用为中心

  • 应用全方位配置管理,包括计算、网络、存储等所有与应用有关配置;
  • 应用全生命周期管理,从第一行配置代码到生产可用。

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

  • Kubernetes 友好的工作流,为 Kubernetes 资源提供可观测性、健康检查等高阶能力,释放云原生技术红利;
  • 复用 Terraform 生态,统一的工作流运维 Kubernetes、Terraform 多运行时资源。

3.规模化协同平台

  • 灵活的工作流,用户可利用平台的基本能力,自己组合、编排来解决自己的问题;
  • App Dev 和 Platform Dev 关注点分离,底层能力迭代无需平台介入,直接供 App Dev 使用;
  • 纯客户端方案,风险“左移”,尽早发现问题。

PART. 6 一切才刚刚开始

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

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

| 相关链接 |

Kusion:

https://github.com/KusionStack/kusion

KCL:

https://github.com/KusionStack/KCLVM

Konfig:

https://github.com/KusionStack/konfig

官网:https://kusionstack.io

PPT:KusionStack:“后云原生时代” 应用模化运维解决方案

https://kusionstack.io/blog/2022-kusionstack-application-scale-operation-solution-in-the-post-cloudnative-era/

了解更多...

KusionStack Star 一下✨:
https://github.com/KusionStack/kusion

本周推荐阅读

从规模化平台工程实践,我们学到了什么?

KusionStack 开源有感|历时两年,打破“隔行如隔山”困境

Go 代码城市上云——KusionStack 实践

KusionStack 开源|Kusion 模型库和工具链的探索实践

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
5月前
|
边缘计算 运维 Kubernetes
云原生时代的运维转型之路
【8月更文挑战第29天】 在数字化转型的浪潮中,企业IT部门正面临前所未有的挑战。本文将探讨如何通过拥抱云原生技术,实现运维工作的现代化,提升系统稳定性和效率,同时降低运营成本。我们将分享实际案例,揭示成功转型的关键因素,并展望未来运维的发展趋势。
69 3
|
5月前
|
运维 监控 Cloud Native
自动化运维的魔法书云原生之旅:从容器化到微服务架构的演变
【8月更文挑战第29天】本文将带你领略自动化运维的魅力,从脚本编写到工具应用,我们将一起探索如何通过技术提升效率和稳定性。你将学会如何让服务器自主完成更新、监控和故障修复,仿佛拥有了一本能够自动翻页的魔法书。
|
3天前
|
运维 监控 Cloud Native
云原生之运维监控实践:使用 taosKeeper 与 TDinsight 实现对 时序数据库TDengine 服务的监测告警
在数字化转型的过程中,监控与告警功能的优化对保障系统的稳定运行至关重要。本篇文章是“2024,我想和 TDengine 谈谈”征文活动的三等奖作品之一,详细介绍了如何利用 TDengine、taosKeeper 和 TDinsight 实现对 TDengine 服务的状态监控与告警功能。作者通过容器化安装 TDengine 和 Grafana,演示了如何配置 Grafana 数据源、导入 TDinsight 仪表板、以及如何设置告警规则和通知策略。欢迎大家阅读。
19 0
|
2月前
|
边缘计算 运维 Cloud Native
云原生技术的崛起:重新定义软件开发与运维
云原生技术的崛起:重新定义软件开发与运维
|
5月前
|
运维 Cloud Native Devops
一线实战:运维人少,我们从 0 到 1 实践 DevOps 和云原生
上海经证科技有限公司为有效推进软件项目管理和开发工作,选择了阿里云云效作为 DevOps 解决方案。通过云效,实现了从 0 开始,到现在近百个微服务、数百条流水线与应用交付的全面覆盖,有效支撑了敏捷开发流程。
19383 30
|
4月前
|
运维 监控 Cloud Native
云原生时代的运维策略:从反应式到自动化
在云计算的浪潮下,运维领域经历了翻天覆地的变化。本文将带你领略云原生时代下的运维新风貌,探索如何通过自动化和智能化手段,实现从传统的反应式运维向主动、智能的运维模式转变。我们将一起见证,这一变革如何助力企业提升效率,保障服务的连续性与安全性,以及运维人员如何适应这一角色的转变,成为云原生时代的引领者。
76 9
|
4月前
|
弹性计算 运维 Cloud Native
云原生时代的运维转型之路
在云计算飞速发展的今天,传统的运维模式已难以满足现代企业的需求。本文旨在探讨如何在云原生时代下进行有效的运维转型,从传统运维到云运维的转变不仅仅是技术的升级,更是思维和方法论的革新。通过实际案例分析,我们将深入了解这一转型过程中可能遇到的挑战与解决策略,以及如何利用云原生技术提高运维效率,保障系统稳定性和安全性,从而为企业带来持续的业务创新和价值增长。
55 6
|
4月前
|
运维 监控 Cloud Native
云原生时代的运维新范式
在数字化转型的浪潮中,云原生技术成为推动企业IT架构现代化的重要力量。本文将探讨如何在云原生时代下重新定义运维工作,包括自动化部署、微服务治理、容器化管理以及DevOps实践等关键领域,旨在为读者提供一套适应新时代运维需求的新思路和新方法。
|
4月前
|
运维 Cloud Native Devops
云原生架构的崛起与实践云原生架构是一种通过容器化、微服务和DevOps等技术手段,帮助应用系统实现敏捷部署、弹性扩展和高效运维的技术理念。本文将探讨云原生的概念、核心技术以及其在企业中的应用实践,揭示云原生如何成为现代软件开发和运营的主流方式。##
云原生架构是现代IT领域的一场革命,它依托于容器化、微服务和DevOps等核心技术,旨在解决传统架构在应对复杂业务需求时的不足。通过采用云原生方法,企业可以实现敏捷部署、弹性扩展和高效运维,从而大幅提升开发效率和系统可靠性。本文详细阐述了云原生的核心概念、主要技术和实际应用案例,并探讨了企业在实施云原生过程中的挑战与解决方案。无论是正在转型的传统企业,还是寻求创新的互联网企业,云原生都提供了一条实现高效能、高灵活性和高可靠性的技术路径。 ##
236 3
|
4月前
|
运维 Kubernetes Cloud Native
云原生时代的运维转型之路
在云原生技术日益成熟的今天,传统的运维模式正面临着前所未有的挑战与机遇。本文旨在探讨如何在云原生大潮中实现运维的平滑转型,通过分析当前运维面临的困境、介绍云原生的基本概念及其对运维的影响,以及提供转型实践的策略和案例,为运维人员指明方向,帮助他们拥抱变化,乘风破浪。