本文作者：吴海黎 - 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。

持续演进的云原生应用交付_交付工具

云原生应用交付现状

持续演进的云原生应用交付_研发效能_02

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​​等命令完成应用部署。

持续演进的云原生应用交付_云原生_03

核心问题：通过上诉工具实现持续交付，前提需将集群密钥交由工具纳管，相比于 GitOps 密钥不出集群，相对不安全；且无法通过版本化的手段，实现交付的可追溯和可审计，出现问题较难快速恢复。

IAC

方法论：IAC（基础设施及代码）

随着云原生应用的快速发展，企业对云基础设施的交付和变更速度要求越来越高，依靠传统手工的方式，操作云控制台维护基础设施，已经无法满足企业的需求，通过抽象云基础设施，并对其通过代码编排的方式即为 IAC。

工具：TIC、Terraform、Crossplane

价值：IAC 将云的基础设施，通过代码来进行编排，并将编排代码存储于代码仓库中，实现了基础设施的版本化管理，用户可轻易的拓展应用依赖的基础设施，比如一个游戏公司将应用部署于腾讯云上海，因业务需求，客户需将应用部署至腾讯云广州，通过 Terraform 的能力，可快速实现应用依赖的基础设施跨可用区迁移：

​​持续演进的云原生应用交付_Devops_04​​

核心问题：本质上 IAC 的能力依赖于云 OPEN API 的开放性和稳定性，目前云产品处于快速演进中，一定程度上造成了 IAC 的能力不够稳定。同时 IAC 的成熟程度仅局限于单一云厂商，跨云 IAC 目前仍需要较高的人工转换成本。

GitOps

持续演进的云原生应用交付_Devops_05

方法论：GitOps

GitOps 是一种实现持续交付的模型，它的核心思想是将应用系统的声明性基础架构和应用程序存放在 Git 的版本控制库中，通过版本控制库的变更，来实现应用和基础架构的变更。

工具：ArgoCD、Flux

价值：通过版本控制库来发布应用和基础架构的变更，将使发布的复杂性降低至版本控制库的 Pull and Push 操作。GitOps 通过安装在 K8s 集群中的 Operator 实现变更物料获取，集群密钥无需出集群，GitOps Operator 中只需获取制品库凭据，即可获取应用变更的制品信息，这也同时大大简化了大型微服务应用的变更交付流程，因为对变更物料的感知，是通过 Gitops 的 Pull 模式自动实现。另外 Git 仓库天生具有可审计「MR」、可追溯「commit log」、快速恢复「回退至某一版本」的能力，使应用发布的可靠性大大提升。最后 GitOps 通过状态控制实现版本库对集群的终态控制，实现 yaml 仓库的「所见」即是 K8s cluster 「所得」。

持续演进的云原生应用交付_云原生_06

核心问题：Gitops 的出现大幅提高了云原生交付的效率和可靠性，但依然有两个问题未被解决，第一：密钥的存储问题，版本仓库的定位决定了它不适合存储密钥；第二：可视化，虽然版本仓库将所有变更存储于 history 中，但这些信息可能分布于不同分支，可读性较差。

OAM

​​持续演进的云原生应用交付_CODING_07​​

方法论：OAM（Open Application Model）

OAM 试图提供一种云原生应用的建模语言，以实现研发和运维的视角分离，K8s 的复杂性无需透传至研发，运维通过提供模块化、可移植、可扩展的特性组件，支撑各种复杂的应用交付场景，从而实现云原生应用交付的敏捷性和平台无关性。

工具：KubeVela

价值：

  • 应用（Application）：云原生应用建模语言，实现视角分离；
  • 开放（Open）：支持异构的平台、容器运行时、调度系统、云供应商、硬件配置；
  • 模型（Model）：建模标准，与底层平台无关。
总结

上述方法论尝试从不同维度优化云原生交付，但采用云原生架构的企业，依然需基于开源工具定制，才能满足企业级云原生交付需求，可见云原生交付域的发展远没有到最优解。比如云原生应用 12 要素（The Twelve-Factor App）中提及的环境隔离和治理问题，依然未被很好的解决。因此我们相信，2021 年会有更多的方法论和工具出现在云原生应用交付域，尝试解决企业级云原生交付问题。CODING 作为国内一站式 DevOps 头部品牌，将在下半年推出云原生应用交付工具，服务企业更好的落地云原生，实现研发效能升级。

​​