本文作者:吴海黎 - CODING 研发总监
负责持续部署产品设计,帮助多个行业客户完成研发效能的方案设计与最终落地。
什么是云原生
云原生是指导企业应用上云的方法论和技术体系,包含应用的开发、交付、运行时等阶段, Cloud Native 可以理解为:
-
Cloud 表示应用运行在云端,而非传统的 IDC;
-
Native 表示应用从设计之初即考虑到云的环境,原生为云而设计,在云上以最佳姿势运行,充分利用云平台的弹性和敏捷。
对云原生的理解,各家厂商在不同时间有不同的定义:
-
2013 年,Pivotal 公司的 Matt Stine 首次提出云原生“CloudNative”的概念;
-
2015 年,Matt Stine 在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征:12 因素、微服务、自敏捷架构、基于 API 协作、扛脆弱性;
-
2017 年,Pivotal 最新官网对云原生概括为 4 个要点:DevOps + 持续交付 + 微服务 + 容器;
-
2018 年,CNCF 更新了云原生的定义,新增服务网格“Service Mesh”和声明式 API。
可以简单的总结为: 云原生 = DevOps + 持续交付(Continuous Delivery)+ 微服务(Micro Services)+ 敏捷基础设施(Agile Infrastructure)+ 12 要素(The Twelve-Factor App)+ 服务网格(Service Mesh)+ 声明式 API。
云原生应用交付现状
CNCF 发布的「Continuous Delivery, June 2020」主要结论如下:
-
开源工具难以满足企业级发布需求
中大型企业的发布场景,开源工具较难匹配,一般的解决方案是选择上图中 2-4 种,基于企业自身场景,深度定制满足需求。 -
Helm 不仅仅是包管理工具
虽然 Helm 自身的定位是解决 K8s 应用的安装包管理,但也被广泛应用发布场景,关于这点其实不难猜想,基础架构由单体迁移至微服务,同时也将应用的交付切分为细粒度的服务交付,但企业面向最终用户的价值交付,需由完整的应用承载,单一微服务价值为 0,因此从交付的完整性考虑,Helm 被广泛应用于发布场景并不奇怪。 -
Jenkins 正逐步被替代
Jenkins 及其生态(Jenkins X、Jenkins Blue Ocean)依然是持续交付中主要被采纳的工具,但企业也在逐步使用新工具替代,如承载 GitOps 理念的 Flux。Jenkins 定位于持续集成,用来做发布的场景是略显无力的,针对 Jenkins 发布下文也做出了分析。
持续演进的云原生应用交付
从 CNCF 的调研报告中得出的核心结论是企业需求未被满足,持续交付的方法论和工具建设依然处于持续演进中,下面我们回顾一下云原生应用持续演进的重要方法论及相关工具。
Continue Delivery
方法论:持续交付
持续交付主张应用被更频繁、更快速的交付至客户,但快并不意味着对质量要求的降低,通常在持续交付实践中,会辅之以质量左移的手段,如代码审查、代码扫描、单元测试、自动化测试,保障应用交付的可靠性。
工具:Jenkins、Gitlab Ci、Tketon
价值:通过持续交付的引入,用户可通过上诉工具实现部署流程的自动化和可视化,通常的持续交付流水线如下,「Deploy」阶段使用:kubectrl apply
或 helm install
等命令完成应用部署。
核心问题:通过上诉工具实现持续交付,前提需将集群密钥交由工具纳管,相比于 GitOps 密钥不出集群,相对不安全;且无法通过版本化的手段,实现交付的可追溯和可审计,出现问题较难快速恢复。
IAC
方法论:IAC(基础设施及代码)
随着云原生应用的快速发展,企业对云基础设施的交付和变更速度要求越来越高,依靠传统手工的方式,操作云控制台维护基础设施,已经无法满足企业的需求,通过抽象云基础设施,并对其通过代码编排的方式即为 IAC。
工具:TIC、Terraform、Crossplane
价值:IAC 将云的基础设施,通过代码来进行编排,并将编排代码存储于代码仓库中,实现了基础设施的版本化管理,用户可轻易的拓展应用依赖的基础设施,比如一个游戏公司将应用部署于腾讯云上海,因业务需求,客户需将应用部署至腾讯云广州,通过 Terraform 的能力,可快速实现应用依赖的基础设施跨可用区迁移:
[图片上传失败…(image-b4ae36-1627369255418)]
核心问题:本质上 IAC 的能力依赖于云 OPEN API 的开放性和稳定性,目前云产品处于快速演进中,一定程度上造成了 IAC 的能力不够稳定。同时 IAC 的成熟程度仅局限于单一云厂商,跨云 IAC 目前仍需要较高的人工转换成本。
GitOps
方法论:GitOps
GitOps 是一种实现持续交付的模型,它的核心思想是将应用系统的声明性基础架构和应用程序存放在 Git 的版本控制库中,通过版本控制库的变更,来实现应用和基础架构的变更。
工具:ArgoCD、Flux
价值:通过版本控制库来发布应用和基础架构的变更,将使发布的复杂性降低至版本控制库的 Pull and Push 操作。GitOps 通过安装在 K8s 集群中的 Operator 实现变更物料获取,集群密钥无需出集群,GitOps Operator 中只需获取制品库凭据,即可获取应用变更的制品信息,这也同时大大简化了大型微服务应用的变更交付流程,因为对变更物料的感知,是通过 Gitops 的 Pull 模式自动实现。另外 Git 仓库天生具有可审计「MR」、可追溯「commit log」、快速恢复「回退至某一版本」的能力,使应用发布的可靠性大大提升。最后 GitOps 通过状态控制实现版本库对集群的终态控制,实现 yaml 仓库的「所见」即是 K8s cluster 「所得」。
核心问题:Gitops 的出现大幅提高了云原生交付的效率和可靠性,但依然有两个问题未被解决,第一:密钥的存储问题,版本仓库的定位决定了它不适合存储密钥;第二:可视化,虽然版本仓库将所有变更存储于 history 中,但这些信息可能分布于不同分支,可读性较差。
OAM
方法论:OAM(Open Application Model)
OAM 试图提供一种云原生应用的建模语言,以实现研发和运维的视角分离,K8s 的复杂性无需透传至研发,运维通过提供模块化、可移植、可扩展的特性组件,支撑各种复杂的应用交付场景,从而实现云原生应用交付的敏捷性和平台无关性。
工具:KubeVela
价值:
- 应用(Application):云原生应用建模语言,实现视角分离;
- 开放(Open):支持异构的平台、容器运行时、调度系统、云供应商、硬件配置;
- 模型(Model):建模标准,与底层平台无关。
总结
上述方法论尝试从不同维度优化云原生交付,但采用云原生架构的企业,依然需基于开源工具定制,才能满足企业级云原生交付需求,可见云原生交付域的发展远没有到最优解。比如云原生应用 12 要素(The Twelve-Factor App)中提及的环境隔离和治理问题,依然未被很好的解决。因此我们相信,2021 年会有更多的方法论和工具出现在云原生应用交付域,尝试解决企业级云原生交付问题。CODING 作为国内一站式 DevOps 头部品牌,将在下半年推出云原生应用交付工具,服务企业更好的落地云原生,实现研发效能升级。