云原生五大趋势预测，K8s 安卓化位列其一

做者 | 李响、张磊

Kubernetes 自己并不直接产生商业价值，你不会花钱去购买 Kubernetes 。这就跟安卓同样，你不会直接掏钱去买一个安卓系统。Kubernetes 真正产生价值的地方也在于它的上层应用生态。

“将来的软件必定是生长于云上的”，这是云原生理念的最核心假设。而所谓“云原生”，实际上就是在定义一条可以让应用最大程度利用云的能力、发挥云的价值的最佳路径。所以，云原生实际上是一套指导软件架构设计的思想。按照这样的思想而设计出来的软件：首先，自然就“生在云上，长在云上”；其次，可以最大化地发挥云的能力，使得咱们开发的软件和“云”可以自然地集成在一块儿，发挥出“云”的最大价值。

云原生的概念你们并不陌生，不少企业也已经基于云原生的架构和技术理念落地相关实践。那么，这么多企业和开发者热衷和推崇的云原生，将来的发展趋势如何？如何才能顺应云原生的主流方向去发展？ 

咱们邀请到阿里云资深技术专家、CNCF 技术监督委员会表明，etcd 做者李响和阿里云高级技术专家、CNCF 应用交付领域 co-chair 张磊分享云原生的理念、发展以及将来趋势，为你们打开新的思路和眼界。

如下内容共享给你们。

Kubernetes 项目的安卓化

云原生里有一个很是关键的项目，就是 Kubernetes。Kubernetes 的发展很是迅速，它是整个云原生体系发展的基石。今天咱们来观察 Kubernetes 项目的发展特色，首先，Kubernetes 无处不在，不管是在云上，仍是用户自建的数据中内心，甚至一些咱们想象不到的场景里，都有 Kubernetes 的存在。

第二，全部云原生的用户使用 Kubernetes 的目的，都是为了交付和管理应用。固然这个应用是一个泛化的概念，能够是一个网站，也能够是淘宝这样很是庞大的电商主站，或者是 AI 做业、计算任务、函数、甚至虚拟机等，这些都是用户可使用 Kubernetes 去交付和管理的应用类型。

第三，今天咱们来看 Kubernetes 所处的位置，其实是承上启下。Kubernetes 对上暴露基础设施能力的格式化数据抽象，好比 Service、Ingress、Pod、Deployment，这些都是 Kubernetes 自己原生 API 给用户暴露出来的能力。而对下，Kubernetes 提供的是基础设施能力接入的标准接口，好比说 CNI、CSI、DevicePlugin、CRD，让云可以做为一个能力提供商，以一个标准化的方式把能力接入到 Kubernetes 的体系中。

这一点其实跟安卓很是相似，安卓虽然装在你的设备里，可是它可以让你的硬件、手机、电视、汽车等都能接入到一个平台里。对上则暴露统一的一套应用管理接口，让你可以基于安卓系统来编写应用，去访问或者享受到这些基础设施能力，这也是 Kubernetes 和安卓的类似之处。

最后， Kubernetes 自己并不直接产生商业价值，你不会花钱去购买 Kubernetes。这就跟安卓同样，你不会直接掏钱去买一个安卓系统。Kubernetes 真正产生价值的地方也在于它的上层应用生态。对安卓来讲，它今天已经具有了一个庞大的移动端或设备端应用的开发生态，而对于 Kubernetes 来讲也是相似的，只不过如今还在于比较早的阶段。但咱们已经可以看到，今天在 Kubernetes 上构建的商业层不少是垂直解决方案，是面向用户、面向应用这一侧真正可以产生商业价值的东西，而不是 Kubernetes 自己这一层。这就是为何我说 Kubernetes 发展跟安卓很像，固然这可能也是谷歌比较擅长的一个“打法”：全力地去免费推广一个“操做系统”，真正获取商业价值的方式则是是去“收割”操做系统上层的生态价值而不是操做系统自己。

基于这些现象，咱们将 Kubernetes 的发展趋势归纳为如下几点：

1. 云的价值回归到应用自己

用户使用 Kubernetes 的本质目的是去交付和管理应用。从这个现象来看，若是 Kubernetes 发展下去，那么世界上全部的数据中心和基础设施上面都会有一层 Kubernetes ，天然而然用户就会开始以 Kubernetes 为基础去编写和交付以及管理其应用，就跟如今咱们会以安卓这样一个操做系统为基础去编写移动应用是相似的。

这就会致使云上的大多数软件和云产品都是第三方开发的。第三方开发是指全部人均可以面向一个标准界面去开发和交付软件，这个软件自己既能够是本身的软件，也能够是一个云产品。将来，愈来愈多的第三方开源项目，如 MongoDB、Elasticsearch 等，都会以云原生理念去开发、部署和运维，最后直接演进成为一种云服务。

2. 云端“豌豆荚”的出现

有了 Kubernetes 这样一个标准，开发者面对的就是一个相似于操做系统的界面。因为有更多的应用是面向 Kubernetes 诞生的，或者说面向 Kubernetes 去交付的，那么就须要有一个相似于“豌豆荚”的产品，来做为云上的应用商店或者云上的应用分发系统，它的关键能力在于把应用无差异地交付给全世界任何一个 Kubernetes 上面，就跟用豌豆荚把任何一个安卓应用交付在任何一个安卓设备上的原理是同样的。

其实今天谷歌已经在作这类产品的尝试了，好比 Anthos （面向混合云的应用交付平台），虽然是一款混合云产品，但它本质上是把谷歌云的服务，好比数据库服务、大数据服务，去直接交付于任何一个基于 Kubernetes 的混合云环境里面去，其实就至关于一款云端的“豌豆荚”。

3. 基于 Kubernetes 可扩展能力的开放应用平台会取代 PaaS 成为主流

因为将来整个应用生态会面向 Kubernetes 去构建，那么基于 Kubernetes 可扩展能力的开放应用平台会逐渐取代传统 PaaS 而成为主流。基于 Kubernetes 可扩展能力去构建一个开放的应用平台，其能力是可插拔的，可以去交付和管理的应用类型是多样化的，这才更符合 Kubernetes 所构建的趋势和生态，因此一些真正高可扩展的平台层项目会大量产生。

另外，今天咱们看到的 Kubernetes ，跟“理想”中的云原生应用生态之间其实还有不少路要走，这也是阿里云原生团队一直在作的事情，基于 Kubernetes 在应用层构建更丰富的应用生态，帮助用户实现多样化的需求。

应用与能力的“ Operator 化”

纵观云原生时代应用或者云的能力的发展方向，你会发现另外一个趋势，就是 Operator 化。Operator 是 Kubernetes 的一个概念，是指 Kubernetes 交付的一个实体，这个实体有一个基础模型存在，这个模型分为两部分：一部分是 Kubernetes 的  API  对象（CRD），另外一部分是一个控制器（Controller），以下图所示：

这里要区分两个概念，自定义和自动化。不少人会说 Operator 能够帮助我作自定义，由于不少人都会以为 Kubernetes 内置的能力是不够用的，因此用户会利用它的可扩展能力去写一个 Controller ，从而实现跟多自定义的需求。但自定义只是 Operator 中很小的一部分价值，咱们今天对应用和能力作 Operator 化的核心动力在于实际上是为了实现自动化，并且只有自动化了，咱们才能讲云原生。

这是由于，云原生带来的最大的红利是可让咱们最大限度、最高效地使用云的能力，二这种最高效、最大化的方式必定没办法经过人工来实现的。换句话说，只有经过自动化的方式去开发、运维应用以及与云进行交互，才能真正把云原生的价值发挥出来。

而若是要经过自动化的方式跟云进行交互，那么在云原生生态里，必须有一个相似于Controller 或者 Operator 这样的插件的存在。今天阿里巴巴在云上交付的 PolarDB、OceanBase 等，其实都有一个跟 Kubernetes 衔接的 Controller 的存在。经过 Controller 与基础设施、云进行交互，把云的能力输入到产品里面去。

在将来，会有大量的云上的应用和对应的运维能力、管理能力都会以 Kubernetes Operator 的方式交付。在这个背景下， Kubernetes 真正扮演的一个角色就是能力的接入层和标准界面。以下图所示，这是一个很是典型的用户侧 Kubernetes 集群的样子。

一个用户的 Kubernetes 只有红框里面这部分是 Kubernetes 原生提供的 API ，而大量的能力都是以插件化或者说 Operator 化的方式存在。就好比上图右边全部这些自定义的资源和能力所有来自于第三方开发，经过 Operator 这样一个标准的形态开发出来的能力来服务最终用户的。这就意味着在将来云原生的生态里面，基于 CRD Operator 的而非 Kubernetes 原生 API 的应用和能力会占到绝大多数。

随着这个趋势的不断演进，愈来愈多的软件和能力经过 Kubernetes Operator 去描述和定义，云产品也会开始默认以 Kubernetes 为底座，基于 Operator 进行交付。

正是由于愈来愈多的 Operator 的出现，这里就会逐步须要一个中心化的方式去解决 Operator 潜在的稳定性、可发现性和性能问题，也就是说在将来极可能会有一个横向的 Operator 管理平台出现，对全部基于 Kubernetes Operator 开发的应用和能力进行统一管理，从而更好、更专业地服务用户。

此外，因为将来每个能力、每个应用都须要去编写 Operator ，因此说对开发者友好的 Operator 编写框架也是将来一个很重要的趋势。这个编写框架能够支持不一样语言，如 Go、Java、C、Rust 语言等，而且编写过程是专一于运维逻辑和应用的管理、能力的管理，而不是专一在 Kubernetes 的语义和细节上面。

最后，随着云原生生态的普及，云服务也将实现 Operator 化，而且面向多集群/混合云场景出现面向应用层的云服务标准化定义与抽象，并在云原生领域逐渐取代 IaC 项目（好比 Terraform 等）成为云服管理与消费的主流方式。 

应用中间件能力进一步下沉

随着云原生以及整个生态的发展，咱们看到应用中间件领域也随之发生了不少改变。从原先最开始的中心化 ESB ，到后来的胖客户端，逐步演化到今天咱们常常提到的 Service Mesh 这样一种 Sidecar 化的方式。

其实今天你会发现，不管是云的能力仍是基础设施的能力，都在不断丰富，不少原先只能经过中间件作的事情，如今能够很容易经过云服务来实现。应用中间件再也不是能力的提供方，而是能力接入的标准界面，而且这个标准界面的构建再也不基于胖客户端，而是经过很是普通的 HTTP 协议、 gRPC 协议去作，而后经过 Sidecar 方式把整个服务的接入层跟应用业务逻辑作一个解耦，这其实就是 Service Mesh 的思想。

目前 Service Mesh 只作了传统中间件里面的流量治理、路由策略、访问控制这一层的事情。而实际上， Sidecar 这个模型能够应用到全部中间件的场景里，实现中间件逻辑跟应用业务逻辑彻底解耦，让应用中间件能力“下沉”，变成 Kubernetes 能力的一部分。这样应用自己会更加专注化，更多的关注业务逻辑自己。

伴随着这个趋势，在 Kubernetes 这一层还会有另一个趋势出现，就是 Sidecar 的自动化的、规模化的运维能力会成为一个必选项。由于 Sidecar 的数量会极其庞大，应用中间件极可能会演化成 Sidecar 集群，那么这些 Sidecar 的管理和规模化的运维能力，会是集群或者云产品的一个必备选项。 

下一代 DevOps 模型与体系

随着云原生生态的不断发展，云原生理念的不断普及， DevOps 的思想极可能也会发生一个本质的变化，即下一代 DevOps 模型与体系。随着 Kubernetes 的能力愈来愈多、愈来愈强大，基础设施也会变得愈来愈复杂，那么基于这样一个强大的基础设施去构建一个应用平台就会很是简单，而且这个应用平台最终会取代传统的PaaS平台。

咱们如今之因此在用 DevOps 这一套思想，其实是因为基础设施自己不够强大，不够标准化，不够好用，因此咱们须要在业务研发侧作一套工具去黏合研发人员和基础设施。例如，基础设施提供的能力是一个虚拟机，怎么能让虚拟机变成研发侧想要的蓝绿发布或者一个渐进式的应用交付系统呢？这就须要一系列的 DevOps 的工具、 CI/CD 的流水线来完成。

可是如今的状况已经发生了变化。基于 Kubernetes 的基础设施自己的能力已经很是丰富，像蓝绿发布这些能力自己就是 Kubernetes 能够提供的能力。在这样的背景下， DevOps 的发展趋势也会发生很大的改变：

1. 关注点分离

在 Kubernetes 的背景下，“软件”再也不是一个由应用 Owner 掌控的单一交付物，而是多个 Kubernetes 对象的集合，而这一堆 Kubernetes 里面的对象只有不多一部分其实才跟研发有关，因此说有不少对象会不在应用 Owner 的认知范围内，这就致使平台必须去作关注点分离，研发侧的关注点和运维侧、系统侧的关注点是彻底不同的东西。也就是研发不用再考虑运维方面的细节，好比蓝绿发布怎么作，水平扩容什么策略，只要把业务代码写完交付就好。

伴随着 Kubernetes 和基础设施愈来愈复杂，概念愈来愈多，做为平台层是不大可能让研发了解全部的概念，所以将来云原生生态必定会作抽象和分层。每一层的角色只跟属于本身的数据抽象去交互，研发侧有一套本身的声明式 API 对象，运维侧有一套本身的声明式 API 对象，每一层的关注点也是不同的，这会是将来整个 DevOps 体系里发展的一个重要的背景。

2. Serverless 泛化

云原生自己的关注点就是应用，在这样一个背景下，Serverless 自己再也不是一个独立场景，再也不局限在某几个很是垂直的领域，而会变成云原生应用管理体系的一种泛化思想和自然组成部分。我从两个层面解释一下：一是在能力侧，“轻运维”“ NoOps ”以及“自助式运维能力”会成为应用运维的主流方式。云原生生态上的应用管理会体现出一种轻运维的状态，就是说应用运维再也不是一我的工的、很是复杂的过程，而是一组开箱即用的、很是简单的模块化操做。不管是经过 Kubernetes 仍是经过云原生能力，都是对下层基础设施的一个模块化的分装，这跟 Serverless 所提倡的 NoOps 理念很是相似。

二是在应用侧，应用描述会普遍地进行用户侧的抽象，事件驱动和 Serverless 理念被拆分和泛化，能够被应用于多样化的场景中而不只仅是今天狭义的 Serverless 场景好比 FaaS 或者 Container Instance，将来全部的应用均可以实现 scale-to-zero 。

3. 基于 Infrastructure as Data（IaD）思想的应用层技术渐成主流

第一，基于 Infrastructure as Data（IaD）的思想会成为一个主流技术，IaD 实际就是 Kubernetes 的声明式 API ，声明式 API 的核心在于把基础设施、应用、能力以一个声明式的文件、声明式的对象去描述，那么这个文件或者对象自己就是“数据”。而 Kubernetes 或者基础设施这一层是经过数据去驱动的，这就是 Infrastructure as Data。这样的思想会延伸出不少技术和前沿的思想，好比 GitOps 、管道型 YAML 操做工具（Kustomize/kpt）等。这样的管道型应用管理会成为云原生生态里面一个很是主流的应用管理方式。

第二，声明式应用定义模型（好比 OAM），以及声明式的 CI/CD 系统和 Pipeline 会成为一个新的应用交付的模式。好比传统的 Jenkins 是一个命令式的组织方式，而随着声明式的 Pipeline 的出现，加上云原生生态、Kubernetes 的普及，基于 Infrastructure as Data 思想的流水线和下一代的 CI/CD 系统也会成为业界的主流。这跟之前的 CI/CD 和流水线有本质的区别，由于这个 CI/CD 系统里面全部的操做都是一个声明式描述。正由于是声明式描述，全部这些操做以及 CI/CD 里面的环节均可以托管到 Git 上，哪怕一我的工审核（Manual Approve）这样的动做均可以托管在 Git 里面，经过 Git 去审计和作版本管理等。

Infrastructure as Data 的出现就是告诉咱们，将来云原生的系统。一切皆对象，一切皆数据。随着对象和数据愈来愈多，对他们的管理、审计、验证等就变得愈来愈复杂，那么围绕它们的策略引擎（Policy Engine）会成为一个很是重要的需求。策略引擎会成为一个很是重要的组件，将来 Kubernetes 全部的应用平台可能都须要一个策略引擎的存在，帮助用户处理不一样场景下对数据的操做策略。

4. 构建于 IaD 之上的最终用户体验层

须要注意的一点是，虽然 Infrastructure as Data 会成为应用层的主流技术，可是它有一个“硬伤”，就是对最终用户并不友好。由于人的大脑比较容易去处理流程化的、规则化的事情，而不是去处理一个静态的数据，因此说在 IaD 之上会有一层面向最终用户的体验层的存在。这就意味着 Kubernetes 不会把声明式的数据直接交给最终用户，而是经过其余方式来操做这些数据，好比经过一种可以理解 Kubernetes 数据模型的动态配置语言（DSL）来完成，或者经过基于 API 对象的 CLI 或者 dashboard 来完成，也多是经过一种以应用为中心的交互与协做流程来完成。而最终用户体验层会决定产品有没有黏性，这是云原生的这套体系有没有黏性，是否是用户友好的一个关键环节。

5. DevSecOps

随着如前所述的下一代 DevOps 体系的发展，安全会从一开始就变成应用交付的一部分。在业界你们称之为 DevSecOps ，就是从 day zero 开始就把安全策略、对安全的考量、安全配置做为应用的一部分，而不是等到应用交付出去了甚至应用已经上线了再去作过后的安全审计和管理。

底层基础设施的 Serverless 云原生化

随着云原生体系的发展，云的价值逐渐走向应用层，不断向基于声明式 API 、基于 IaD 的理念去发展，那么下层的基础设施也会发生相应的变化。第一个变化是基础设施能力声明式 API 化、自助化。今天的云是基础设施能力的集大成者，能够认为是一个无限的能力层，今天咱们能想象到的基础设施上全部的能力，云均可以提供，这跟之前的基础设施彻底不同。之前云的能力很薄弱，基础设施的能力也很薄弱，因此才须要一个庞大的中间件体系和精密的 DevOps 体系来作一个“胶水层”，去弥补基础设施跟应用、研发、运维人员之间的鸿沟。

而将来，应用才是整个云原生生态的主角。应用须要使用某个能力，那么云就会提供这个能力，而且是经过一个标准化的接入层来提供，而不是直接跟基础设施打交道。云原生生态的发展会使得用户侧的视角发生很大的改变，从面向基础设施变为面向应用，从基础设施有什么用户才能用什么，变成用户要什么，基础设施就能够提供什么。以应用为中心的基础设施会是将来基础设施的一个基本形态。

这个理念跟 Serverless 理念很是相似，咱们能够将它称为底层基础设施的 Serverless 原生化，这意味着基础设施会在将来也逐渐的声明式 API 化，而声明式 API 化带来的一个直接结果就是他会变成一个自助化的基础设施。

另外，因为基础设施可以实现声明式 API 化，实现自助化，那么打造更加智能化的基础设施就成为一个重要方向。由于基础设施系统的模块化能力变成了一个数据化的定义方式，那么就能够和容易的经过监控数据、历史数据来驱动基础设施的运转，也就是“自动驾驶的基础设施”。数据驱动的智能化基础设施会在将来成为可能，固然其前提是基础设施自己实现声明式 API 化和自助化。

与此同时，因为应用层自己会 Serverless 泛化，像 “scale to 0” 和 “pay as you go” 这些功能，会成为应用的一个基础的假设，致使资源层也会走向极致弹性+无限资源池的方向。做为一个智能化的基础设施，能够去作更加智能的调度与混部，从而提供极致的资源利用效能，实现成本的极低化。

与此同时，因为要实现极致的资源效能，就意味着底层必定是一个强多租架构，而且这个强多租架构是面向 Kubernetes 的，跟 Kubernetes 有一个自然的、很是融合的集成。这体如今两个方面：第一，在运行时这一层，这个基础设施会倾向走基于硬件虚拟化的容器运行时而非传统虚拟机的方向，好比 Kata Container ，而且认为神龙裸金属服务器更适合作宿主机。伴随着这套技术的发展，轻量化的 VMM（虚拟化管理技术）会成为优化容器运行时、优化整个基础设施敏捷度的一个关键技术和关键链路。

第二，强多租的控制面会针对不一样租户作物理隔离，而不仅是逻辑隔离，这是 Kubernetes 数据模型的要求，即租户的控制面板之间须要有强的物理隔离，这就是为何咱们讲将来的强多租架构必定会面向 Kubernetes 来构建。阿里内部也是看到了这样的趋势，在不断作一些尝试，去更好地响应将来 Serverless 原生化的基础设施的发展趋势。

另外，咱们团队正在招聘2021年毕业的应届生，欢迎各位同窗加入咱们：

• 简历投递：yaowei.cyw@alibaba-inc.com
• 邮件标题：云原生-岗位名称

详情可点击查看：https://mp.weixin.qq.com/s/aMGMme2-p296798wlGQQfQ。

“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，作最懂云原生开发者的公众号。”