Kubernetes 会不会“杀死” DevOps？

> **导读**：DevOps 这个概念[最早是在 2007 年提出](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fdevops.com%2Fthe-origins-of-devops-whats-in-a-name%2F)的，那时云计算基础设施的概念也才刚刚提出没多久，而随着互联网的逐渐普及，应用软件的需求爆发式增长，软件开发的理念也逐渐从瀑布模型（waterfall）转向敏捷开发（agile）。

传统的软件交付模式（应用开发人员专注于软件开发、IT 运维人员负责将软件部署到服务器运行），再也无法满足互联网软件快速迭代的需求。于是，**DevOps 作为一种打破研发和运维之间隔阂、加快软件交付流程、提高软件交付质量的文化理念和最佳实践**逐渐普及至今。

 

DevOps 的现状
==========

DevOps 的流行得益于业界对于应用软件敏捷开发、高质量交付的诉求，所以为开发和运维开辟了一块“公共的空间”，让双方可以在这里紧密合作。那时软件研发依旧属于一个新兴行业，人们习惯于向成熟的制造业学习，制造业解决大规模生产的方式，就是构建流水线，通过流水线规范化每个步骤对接的内容，而流水线上的工人们则只需要各司其职，快速熟练的完成自己这部分生产内容。

所以，DevOps 借鉴了制造业的经验，开始构建持续集成/持续交付（CI/CD）的流水线，催生出了一系列自动化/半自动化工具（如puppet、chef、ansible等），结合编写脚本的可扩展能力，将研发和运维的大量操作规范化，从而达到彼此协作的目标。但是最终还是要有人投入到这些工具的构建中，于是就出现了 DevOps 团队。DevOps 团队构建的工具和平台，帮助研发更容易地接近生产环境，让研发在持续集成、持续交付的过程中可以一键部署、快速试错，从而很大程度提前暴露和避免了软件在实际运行过程中的问题。

从本质上讲，**DevOps是为运维服务的。**它把生产环境的运维流程通过自动化的工具提供出来了，屏蔽了基础设施细节，同时让软件本身的问题更容易暴露，从而把这些问题尽量提前交给研发去解决。这些，其实都是在帮助运维减轻负担。

这一套模式在一开始运转良好，但是问题也随着时间的推移慢慢暴露出来了。DevOps 本身不为企业带来直接的利润，也不增加产品的功能，它们是企业的成本中心，所以许多企业不愿意为 DevOps 投入太多的成本。久而久之，DevOps 的能力便无法与研发人员增长的需求所匹配，不愿意继续伴随着云和开源社区的发展向前演进，反而成为软件研发的瓶颈。试想一下，有多少大公司的技术人员，对自己公司里的“研发效能”工具表示满意呢？

 

云计算的普及
======

聪明的企业总能从自己的需求中发现业界共有的需求，[AWS 便是这么诞生的](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fwww.iyiou.com%2Fp%2F91816.html)，他们早在 2006 年便首次把软件部署需要的网络、计算、存储等基础设施当做服务提供给用户，允许任何人在不购买服务器等物理硬件的情况下构建互联网应用程序，规模化使得整体的成本比用户自建更低。而云计算IaaS、PaaS、SaaS的概念也正是在那一年开始逐渐清晰的。

云计算的初期，用户主要使用的是IaaS服务，如虚拟机、存储等，使用云计算服务的企业依旧需要运维来管理这一类基础设施，只是运维管理的对象从物理机切换到虚拟机而已，并没有太本质的区别。

而随着云计算的快速发展，云的能力不断补充、增强，渐渐将原先由运维提供的方方面面的能力都转换成为了云上的服务，这其中自然包含了管理软件完整生命周期的各类服务，从代码托管、持续集成、持续交付，到监控、报警、自动扩缩容等一系列的能力，均能在云上找到对应的服务。品类之多、数量之巨，令人瞠目结舌。

但是 DevOps 依然有着用武之地。云的对接难度实在太大了，涉及到的云服务又多，不同云厂商提供的服务还不统一，为了使用云上的产品不得不投入大量的时间学习，而为了防止云厂商的绑定又不得不做多厂商的适配，DevOps 依旧需要像过去一样为开发屏蔽实际环境的复杂性，只不过这次他们要负责管理的基础设施变成了云资源。

 

改变一切的 Kubernetes
================

Kubernetes 的本质是现代应用基础设施，它关注如何将应用与“云”天然地集成在一起，将“云”的最大价值发挥出来。Kubernetes 强调让基础设施能更好的配合应用、以更高效的方式为应用“输送”基础设施能力，而不是反之。在这个过程中，Kubernetes 、Docker、Operator 等在云原生生态中起到了关键作用的开源项目，正在在把应用管理与交付推上一个跟以前完全不一样的境况：Kubernetes 的使用者只通过声明式的方式描述自己应用的终态是什么，然后一切就结束了。Kubernetes 会处理后面的所有事情。

这也是为什么Kubernetes 非常强调声明式API。通过这种方式，Kubernetes 本身接入的基础设施能力越强，Kubernetes 的使用者能够声明的终态就越丰富，他的职责也就约单纯。现在，我们不仅能够通过 Kubernetes 声明应用的运行终态，比如；“这个应用需要 10 个实例”，我们还能够声明应用的很多运维终态，比如：“这个应用使用金丝雀发布策略进行升级”，以及 “当它的 CPU 使用量大于 50%时，请自动扩展 2 个实例出来”。

这就让传统的 DevOps工具和团队受到了挑战：如果一个业务研发自己只需要通过声明式 API 声明他的应用的所有终态甚至包括完整的 SLA，后面的一切就都会有 Kubernetes 来自动的搞定，那么他还有什么理由去对接和学习各式各样的 DevOps 流水线呢？

换句话说，长久以来，DevOps 实际上是在充当研发与基础设施之间的那一层“胶水”。而现在，Kubernetes 通过它极具生命力的声明式 API 和无限接入的应用基础设施能力，正在完美的扮演这个“胶水层”的作用。这也提醒了我们，上一个正在被 Kubernetes 体系强烈挑战的“胶水层”，其实叫做“传统中间件”：它正遭受到 Service Mesh 的巨大冲击。

 

DevOps 会消失吗？
============

近几年，Kubernetes 项目经常被描述成 DevOps 的“最佳拍档”。类似的观点认为， Kubernetes 跟 Docker 一样，解决的是软件运行时的问题。这意味着 Kubernetes 更像一种“时髦”的 IaaS，只不过运行时从虚拟机变成了容器。所以，只要能够将现有 DevOps 思想和流程对接到 Kubernetes 上来，就可以享受到容器技术带来的轻量级与弹性。这对于提倡“敏捷”的 DevOps 来说，显然是最好的组合。

不过，至少目前看来，Kubernetes 的发展路径并不是一个类 IaaS 的角色。它虽然关注接入底层的基础设施能力，但它本身却又不是基础设施能力的提供方。而且，相比于软件运行时，Kubernetes 似乎更关心软件的生命周期和状态流转。不仅如此，它还提供了一种叫做“控制器模型”的机制来将软件的实际状态与期望状态不断逼近，这显然都已经超出了一个“软件运行时”的范畴。

Kubernetes 项目对应用本身的“额外关注”，让它与一个类 IaaS 基础设施有着明显的区别，也让它“胶水”的定位更加明显。而如果 Kubernetes 的能力足够强大，那么作为研发与基础设施之间现有的“胶水层”， DevOps 是否还有必要存在？在所谓的云原生时代，应用研发与交付是不是真的会走向“一次声明”就可以“撒手不管”，从而让 DevOps 彻底消失呢？

不过，至少目前看来，Kubernetes 项目距离这个愿景，还有不少困难需要克服。

**“Platform for Platform” API 的局限性**

Kubernetes 是一个典型的 “Platform for Platform”项目，所以它的 API，距离纯研发视角还是非常遥远的。就比如一个 Deployment 对象，就既包括了研发侧关心的镜像，也包括了基础设施侧的资源配置，甚至是容器安全配置。此外， Kubernetes API 并没有提供出对“运维能力”的描述与定义方式，这也使得声明之后的“撒手不管”变得遥不可及。这也是为什么目前 DevOps 依然被需要的原因：Kubernetes 的大多数字段，还是必须经过研发和运维共同协作的流程来进行填充。

**无法对更多的云资源进行描述**

K8s的原生API只包含了云资源的很少一部分，比如用 [PV/PVC](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fkubernetes.io%2Fdocs%2Fconcepts%2Fstorage%2Fpersistent-volumes%2F) 表达存储，用 [Ingress](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fkubernetes.io%2Fdocs%2Fconcepts%2Fservices-networking%2Fingress%2F) 表达负载均衡，但这对于一个完全声明式的应用描述来说是完全不够的。比如，研发希望在K8s上找到一个概念来表达数据库、VPC、消息队列等需求的时候，就会感到非常困惑。而现有的所有方案则完全依赖于云厂商的实现从而带来了新的 vendor lock-in 困惑。

**Operator 体系缺乏互操作性**

Kubernetes 的 [Operator](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fkubernetes.io%2Fdocs%2Fconcepts%2Fextend-kubernetes%2Foperator%2F) 机制是这个项目的能力能够无限增长的公开秘密。但令人遗憾的是，目前所有 Operator 之间的关系，就像是一个又一个的烟囱，互相之间没有任何交互与协作的可能。比如，我们把云上的 RDS 通过 CRD 和 Operator 扩展到了 K8s 声明式API的体系中，但是当第三方希望写一个定时备份 RDS 持久化文件的 CRD Operator去配合的时候，却往往无从下手。这就又需要 DevOps 的体系介入来解决问题。

未来？
===

显然，现在的 Kubernetes 项目，依然需要借助 DevOps 体系来真正完成软件的高效迭代与交付工作。这是不可避免的：尽管 Kubernetes 声称自己是“以应用为中心”的基础设施，但它作为一个从 Google Borg 衍生出来的系统级项目，其本身的设计和工作层次还是更多的基础设施领域徘徊。但另一方面，我们绝不可否认的是，Kubernetes 在它的关键路径上，始终保持着对研发侧 “NoOps” 的追求。这种渴望，从它第一天提出“声明式应用管理”理论的时候就已经“昭然若揭”，而 CRD 和 Operator 体系的建立，更让这种应用级别的关心终于有了落地的机会。我们已经看到很多 DevOps 流程正在“下沉”为 Kubernetes 里的声明式对象与控制循环，比如 [Tekton CD](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fgithub.com%2Ftektoncd%2Fpipeline) 项目。

如果 Kubernetes 的未来是 100% 的声明式应用管理，那么我们有理由相信 DevOps 最终会从技术领域消失然后彻底蜕变成一种文化。毕竟，那个时候的运维工程师，可能都会成为 Kubernetes Controller/Operator 的编写者或者设计者。而研发呢？他们可能根本不会知道原来 Kubernetes 这个东西曾经如此显赫的存在过。

 

OAM
===

 
在 2019 年 10 月，阿里云联合微软一起发布了[开放应用模型 Open Application Model(OAM)](https://yq.aliyun.com/go/articleRenderRedirect?url=http%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMzUzNzYxNjAzMg%3D%3D%26amp%3Bmid%3D2247487043%26amp%3Bidx%3D1%26amp%3Bsn%3D088457a1dccd6578290c9291a968bf16%26amp%3Bchksm%3Dfae5058ccd928c9a618c2763c8dcf74348e2198ba532a1095f0d9292da44f8d1b2a9f8cf4342%26amp%3Bscene%3D21%23wechat_redirect)，打破了传统的软件交付模式，OAM 是专注于描述应用生命周期的标准规范，可以帮助应用开发者、应用运维人员和基础架构运维团队更好地进行协同。 
 
 
目前，OAM 还处于一个早期阶段，阿里巴巴团队正在上游贡献和维护这套技术，如果大家有什么问题或者反馈，也非常欢迎与我们在上游或者钉钉联系。

 

[原文链接](https://link.zhihu.com/?target=https%3A//yq.aliyun.com/articles/739645%3Futm_content%3Dg_1000094672)

本文为阿里云内容，未经允许不得转载。