本文作者：吴海黎 – 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 的能力，可疾速实现利用依赖的基础设施跨可用区迁徙：

外围问题：实质上 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 头部品牌，将在下半年推出云原生利用交付工具，服务企业更好的落地云原生，实现研发效力降级。

点击深度摸索云原生之旅