大家好，我是灵雀云的陈恺。今天我们用这种比较特殊的方式来交流，很多人可能已经习惯这种新的工作和生活方式。疫情在带来很大挑战的同时，也在倒逼着我们去进步，就像几个月前微软CEO 萨提亚·纳德拉说的，很多企业把原本需要花两年时间来做的数字化转型，在短短两个月内一口气全都搞定了。

参加过前面几届CNBPS大会的朋友可能知道，我每年都会试图用一句话来概括下云原生在这一年的状态。2020年我觉得这句比较合适：云原生技术正在成为云计算行业的新常态。它不再是一个存在于角落的略显怪异的新事物，而变成整个云计算行业、主流云计算必不可缺的一部分。

今天主要跟大家分享如下三个话题：

云原生企业落地现状

云原生技术生态趋势

云原生对云计算行业的影响

01云原生企业落地现状

Kubernetes已成为绝对主流

最近CNCF发布了最新的中国区云原生调查报告，里面有一个亮眼的数字，72%的受访者已经在生产环境当中使用Kubernetes，同期全球调查报告的数字是78%。可以看到，在Kubernetes的使用率上，中国和全球是持平的。如果看纯容器使用率，则更加惊人，超过84%。从这些数据来看，我们可以得出结论：Kubernetes和容器已经完全进入主流市场，成为所有人都在使用的技术。

CNCF的调查可能会有一些倾向性，受众都是本来就对CNCF项目感兴趣的人群。不过其他科技类公司的报告得出的数据都跟上述差不多，容器和Kubernetes使用率在70%-80%之间。唯一相差较大的是Gartner在去年CIO峰会上针对企业CIO所做的调查报告，结论是在生产环境中使用率大概在40%，还有其他30-40%正在开发测试环境中使用。

Gartner CIO峰会的受众群体主要是传统企业的CIO，它本身就是主流市场。如果在这个群体达到40%也是很可观的，说明Kubernetes已经要进入鸿沟理论的晚期大众阶段。所以基于上述数据我们认为完全可以得出这样的结论：从普及度来说，Kubernetes和容器作为一项新兴技术已经成为绝对主流。

落地仍有挑战，深度与广度不足

那么是不是可以说，云原生在企业落地这件事情已经全部搞定了？我想大家可能会得出不一样的结论。

这里还有一组数据，关于云原生技术落地的深度。第一个数据5%来自Gartner的评估，虽然很多企业在使用容器，但在使用程度上只有不到5%的业务放在Kubernetes之类的平台上。如果按这个数据来看，还在很早期。

第二个数据来自CNCF的同一份调查报告，CNCF有13个已毕业的项目，这其中有比较严谨的项目进阶流程。在最成熟的13个项目中，使用度超过50%的在中国市场只有两个，同期全球的数据为6个。从这点来看，云原生技术使用的广度在中国市场还处在相当早期的阶段。

第三个图是做容器化应用遇到的挑战，Top2分别是复杂度和安全性，可以看出大家在做一些比较严肃的应用时，会去考虑安全性等的问题。

从这些数据当中，我们可以得出什么样的结论？首先，企业有非常强烈的意愿去拥抱云原生技术体系，而且已经开始做了，至少在Kubernetes这些最主流的技术上，大多数企业甚至已经在生产环境开始应用。但大规模的生产级落地仍然有非常大的挑战，挑战来自多方面，比如对企业运维能力的要求，云原生基础设施很大程度上是可编程的，比如做不可变基础设施，或者采用Gitops最佳实践去做基础设施和应用的变更管理，或通过扩展Kubernetes来提供一些比较有特色的运维能力，或者通过开发Operators，Operators是应用专属的Kubernetes原生操作器，来做复杂应用的全自动运维管理，这些运维类的工作都要求有开发技能，对传统的运维组织来说有不少的挑战。

安全方面也是如此。从开发流程来看，传统的安全流程相对开发来说通常是滞后的。这些安全的流程看上去像是一个个路障，像是故意让你的开发慢下来，显然传统的安全流程和DevOps是不兼容的。如果不去处理，对于安全和DevOps都不是件好事。如果要处理的话，唯一的方式是把安全平移，变成开发流程/DevOps的一部分，就是我们常说的Life Cycles。

运行时安全也会有一些新的要求，比如说云原生的工作负载通常来说是高度动态的，容器本身已经是动态的， Serverless是更极端的例子。在这种情况下，传统的基于主机和外部网络的安全机制，并不能完全满足需求，需要一些新的针对云原生工作负载的安全机制。

此外，云原生对于企业的组织文化也会提出新的要求。DevOps自然不必多说，运维层面也是如此。另外，云原生落地通常需要一个平台团队或者部门，它介于传统的运维和开发之间，很多方面要和业务开发结合的比较紧，去赋能业务开发团队，做DevOps的一些最佳实践等等。

总体来说，我们认为，要成功落地云原生的技术体系需要云原生平台。首先云原生平台自身可能就已经集成了大量相关的云原生技术，云原生平台天然地会去集成一些前沿的技术，专业的厂商跟踪社区的实时动态，确保这些技术始终保持在最前沿。更重要的是，可以很大程度上去降低运维的复杂度，消除运维层面的挑战，把一些云原生落地的最佳实践来提炼出来，自动化之后作为服务进行提供。

02 云原生技术生态趋势

接下来我们切换一下频道，来看一下云原生技术生态的现状和趋势。早在2017年，当时Kubernetes正在变成一个标准，Kubernetes变成标准，对云原生生态是非常有利的。一旦有了这个标准之后，大大降低了所有人围绕Kubernetes做技术投入的成本和风险，会吸引越来越多的技术社区和厂商不断向Kubernetes靠拢，最终在Kubernetes周围催生出一个庞大的生态。

早期我们说在Kubernetes上面跑应用，首先应用是事先已经存在的，我们把应用做容器化，让它运行在Kubernetes的平台上面。今天人们已经不再满足于这种方式，Kubernetes是一个操作系统，是很多应用的编译目标。未来对于大多数应用来说，Kubernetes可能是它最优先的编译目标，甚至是唯一的编译目标。不少新应用从第一天诞生就是在Kubernetes上面来开发，甚至把Kubernetes作为框架，直接对它做扩展，或者在Kubernetes上面开发operator来专门在Kubernetes上面去管理应用。

三年前的第一届CNBPS上，我们刚开始讨论云原生时，推出一个观点是云原生有三大要素：容器平台，DevOps和微服务。后来发现整个市场对这个观点接受度非常高，几乎所有谈论云原生的场合都会使用这个框架，这个框架又被赋予很多名字，比如黄金三角、三架马车之类的。在早期这个框架为云原生提供了一些非常具体的抓手，不然，云原生可能会感到是个非常抽象的概念。

但是云原生技术生态发展到今天，我们觉得是时候去打破这三驾马车，从更加全局、更加完整、更加全栈的角度去看整个云原生生态。

云原生基础设施

云原生的基础设施到今天已经远远不限于容器管理。今天我们做大规模企业落地时，会看到一些更加现实的业务应对。比如对存储有更高的要求，存储厂商通过 CSI将自己的存储方案和Kubernetes做集成，社区里涌现出一些全新的容器原生存储方案，分布式存储系统直接跑在Kubernetes上面，使用Kubernetes来做管理，编排存储系统。

网络也是，早期大家因为使用场景不是很严肃，会满足于使用Kubernetes默认的开源网络方案。现在大家越来越希望有一个更加严肃的企业级容器网络方案。

虚拟化在早期自然而然的架构是：最底层物理机，上面做一层虚拟化，在此之上放Kubernetes，然后上面跑容器化应用。但很多情况下我们看到虚拟化层和Kubernetes层的位置发生了互换，因为Kubernetes不光是用来做容器编排，本质上是声明式API加基于控制器的架构范式，可以用来编排任何东西，包括虚拟机。

现在出现了一些容器原生虚拟化的技术，直接用Kubernetes去管理和编排虚拟机，把跑在虚拟机和容器里的应用在一个平台上做统一管理。比如OpenStack厂商选择把OpenStack放在Kubernetes上面，用Kubernetes管理Openstack，是非常常见的现象。

操作系统也是，如果说Kubernetes最终会变成一个云的操作系统，往下管理绝大多数基础设施，容器宿主机的操作系统就会变成一个非常值得的投入。整个宿主机集群上的操作系统，都可以用Kubernetes做全自动管理。当Kubernetes集群规模足够大，这是必然会发生的事情。

然后是混合云，多云管理和边缘计算。我们知道，Kubernetes作为一个可移植层，它能够屏蔽基础设施的很多细节，可以很容易地做跨云迁移，对混合云和多云管理非常有好处。今天容器化应用远远不止停留在跨云迁移层面，Kubernetes可以去编排云服务，编排不同的云环境资源。甚至有些项目会把云的基础设施、公有云服务和容器化应用，都放在Kubernetes上面作为整体去编排，这是一个比较高级的玩法。

边缘计算也是如此，Kubernetes，甚至是轻量级的Kubernetes都非常适合作为边缘环境的运行时。Kubernetes也可以去编排管理边缘设备和设备影子，编排边缘的网关。

所以总体来说，云原生基础设施已远远超过容器管理本身，Kubernetes会变成所有技术基础设施类软件的核心，成为整个基础设施管理平台的统一工具。

云原生应用架构

应用架构在早期提出时，主要指微服务，微服务现在仍然是非常重要的用例。去年的第二届CNBPS上，我记得提到，一定要意识到微服务并不是免费的，它的本质是用运维的复杂度去换取敏捷性。

Service Mesh

所以首先要考虑的问题是企业到底需不需要这样的敏捷性，如果不需要，没有必要引入过多的复杂度。如果需要，企业的确是敏态业务，想拆分成微服务应用，做快速迭代。这时就要意识到，微服务会带入运维的复杂性，企业需要一种方式去管理这种复杂度。于是就有了微服务治理，Service Mesh就是用来做微服务治理的。在CNCF的最新的调查报告中，Service Mesh的普及度并不是很高，大概在20%左右，离Kubernetes还差很远。但Service Mesh仍然是后Kubernetes时代微服务治理的最佳实践。

到目前为止，Service Mesh最好的技术选型仍然是Istio，尤其是今年新版本发布之后，Istio对人们一直诟病的架构复杂度也做了大幅重构，解决了大家认知中在生产级应用中可能存在的一些问题，比如Mix组件的单点性能和稳定性瓶颈问题。

Operators

当然不是所有应用都能做成微服务应用，一些现实中的应用体量是非常复杂的。还有一些应用是分布式有状态的应用，Operators是应用专属的Kubernetes原生操作器，可以把应用运维的知识写成代码，将应用的运维进行完整自动化，这种做法越来越普遍。灵雀云平台本身在非常深度地使用Operators，来尽可能把所有配置的事情都通过Operators来自动化。

OAM

OAM(Open Application Model)是去年微软和阿里推出的一个开源的定义云原生应用的模型，这个项目目前普及度还不高，但从设计理念来看，有许多吸引人的地方。其一，它比较清晰地定义了不同的角色，比如应用开发、应用运维和基础设施运维，给每个角色划分出了边界，可以让每个角色去关注自己真正需要关心的事情。其二，它本身非常开放、灵活，在OAM里面可以灵活地定义自己觉得最理想的上层抽象。

也就是说，你可以在API层面为用户提供想要提供的应用抽象，并不需要所有人都非常了解Kubernetes，直接去使用Kubernetes原生的那些API。某种意义上，我觉得Kubernetes自身的API很难面向汇编语言。如果对着Kubernetes的API去写yaml，我觉得这世界上很少有人可以凭空把yaml写出来。yaml相当于Kubernetes的汇编语言，它不应该是最终的形态，在上面应该有个类似于编程中的高级语言，OAM可能是高级语言的一种选项。

多元化工作负载

云原生的工作负载也在变得多元化。Serverless是正在兴起的一种云原生工作负载，从 CNCF的调查报告来看，Serverless的普及率要高于service mesh。但是多数Serverless的使用都是在公有云上面。目前来说公有云上的 Serverless能力也会更加成熟，而且公有云才是真正的Serverless。对用户来说，公有云的规模可以带来资源无限，弹性无限的印象。

另外，Serverless需要一整套基础设施，并不只是函数计算，还需要Serverless数据服务、API网关等。目前，这些的确在公有云上会更加成熟一些，但长期来看，私有云环境也会慢慢有对Serverless编程范式和架构范式的需求。此外需要解决的问题是，目前公有云Serverless缺乏标准，导致工作负载的跨云迁移，或者从混合环境的迁移非常麻烦，几乎不可能。

在社区方面，我们看到未来Serverless会出现一个标准框架，基于Kubernetes云原生技术栈上面会包含Serverless的标准框架，比如Knative就是一个潜在的框架。当标准出现，在混合云、多云的环境里面，更标准化、可迁移的Serverless workload会更加实用。

API

API不只是企业内部集成和对外能力暴露，还有一些趋势在围绕着API聚拢。比如，SaaS厂商把API直接作为产品提供，甚至把一系列通用的业务能力包装成API作为产品提供。在客户侧，会更多把集成作为业务开发的一种模式，配合受欢迎的低代码开发。所以，API治理无论是企业内部集成，还是使用厂商提供的API，长期来说都是一个需要关注的事情。

云原生DevOps

DevOps本身是一个庞大的概念，很难说完全超越DevOps，但云原生对DevOps也会有影响。在早期，大多数容器平台聚焦在CI/CD上，CI/CD的确是平台容器化的一个主要场景和早期用例。

灵雀云在较早的时候就提出，作为云原生平台需要覆盖 DevOps完整的流程和场景。DevOps使用的各种工具，整条工具链需要和Kubernetes平台对齐打通。不仅如此，K8s可以编排一切，DevOps工具可以放在Kubernetes平台上面去做管理。另外Kubernetes编排DevOps不应只停留在工具链，可以进一步用Kubernetes去编排DevOps流程本身。Kubernetes做统一编排，可以把各种各样工具打通，在云原生平台上提供一个直观的对于整个 DevOps 流程可见度非常高的全局视角。

传统的安全流程和DevOps是有冲突的，唯一的解决方式就是把安全和开发流程相结合，把它变成DevOps的一部分，即所谓的DevSecOps。

不破不立，我们觉得是时候来主动打破云原生的黄金三角的框架，容器平台、DevOps和微服务仍然是非常重要的要素，但更应该从更加全栈、全局的视角去看云原生生态技术。

03 云原生技术对云计算行业的影响

云原生普及是云计算成熟的标志

云原生的本质是最大化发挥云计算的价值。云原生的普及是云计算行业成熟的标志。早期云计算主要关注基础设施的管理、优化，以基础设施为中心，现在应该回归到以应用为中心，早期云计算关注简单粗暴上云，现在要考虑的是如何真正发挥云计算的最大价值，早期我们关注应用跑在哪里，现在更需要关注应用如何去设计、开发、交付和运维。

云计算正在趋于多元化

云原生可以说是云计算的最佳实践，是云计算行业发展到一定阶段的必然结果。云计算本身也在发生一些变化，就是它在“去多元化”。我本身在十几年之前是做公有云，当时会有一些理想主义，觉得纯粹的公有云才是云计算的未来。直到AWS发布Outpost，作为一个重大的标志，整个行业开始形成共识，就是云计算的最终形态会是多元化的，会有公有云，也会有私有云、混合云、边缘计算等。

但是，我们发现之前传统的私有云和混合云的建设，并不是很成功。问题主要出在哪里呢？如果说混合云是云计算的最终形态，该怎么样来建设？之前做私有云大体有两种主流的方式，基于OpenStack的IaaS技术来做私有云平台，这也是占大多数的一种方式。这种做法有很大局限性，它其实只是做了IaaS，或者只是做了基础设施虚拟化，离完整的云平台还有很大距离。

公有云之所以受欢迎，并不是因为它的虚拟技术。公有云受欢迎，一是因为云作为一种新式的经济模式，很有吸引力。第二更重要的是，成熟的公有云平台全栈的能力几乎可以满足所有的企业IT的需求。如果只是做基础设施虚拟化，显然是不够的。有些企业可能会选择自己在OpenStack上去建设一些平台级别的能力，但是这种程度的定制化投入，远远比不上公有云厂商长年累月大规模的研发投入带来的公有云厂商标准化平台的能力。

另一种做私有云的方式，是由公有云的厂商把自己完整的功能做私有化部署。但这样的方式交付一两个项目可能真的没有问题，当试图去做规模化交付时，会发现非常复杂。核心的原因是如果公有云产品不做大的改动，只做一些裁剪和瘦身，公有云和私有云产品底层的设计目标是不一致的，甚至是冲突的。

公有云需要做的是规模大，可用性非常好，但不需要去考虑这么大的平台如何去交付。另外，也不需要考虑任何硬件或者其他环节的事情，因为从数据中心开始，包括硬件、芯片、操作系统，所有事情都是为自己的公有云量身定制的，只有这一种配置。而如果想做成一个成功的私有云产品，做规模化交付，会发现简单的用公有云去做私有化难度会非常大。

现在我们可以比较清晰地看到，未来的混合云大概有两种模式：

第一种，由公有云厂商来做，但不是简单粗暴地把自己的公有云做私有化，而是需要专门针对私有云和混合云的场景去重新设计。客户使用时会觉得体验和公有云差不多，但如果剥开来看，里面具体的技术、架构会有很大区别。

第二种，是基于以Kubernetes为核心的云原生平台来做，Kubernetes作为云的操作系统，可以去屏蔽下面各种各样不同的云环境、云基础设施，它自身是一个可移植层，这样在做混合云和多云管理时，对应用迁移以及其他工作负载非常有好处，可以做到跨环境的兼容。由于Kubernetes的可扩展性，本身平台之平台的属性，导致它天生适合用来作为整个混合云的控制面板，用它去编排私有云和公有云的所有环境、云基础设施和各类云服务。

我们觉得两种形式会并存，甚至对同一客户来说也可以一起使用。但无论如何，以Kubernetes为核心的云原生平台，在未来的混合云和多云管理中会起到非常关键的作用！

云计算正在重塑传统云架构

云计算发展到今天，IaaS、PaaS、SaaS三层的界限已经不再那么明显。以容器平台来说，纯粹的容器CaaS其实是虚拟化技术，理论上属于IaaS层。但如果容器平台更加注重于应用的管理，集成DevOps、微服务治理能力，以及API网关，在上面提供容器化的数据服务，它显然又是个PaaS，所以容器平台横跨IaaS和PaaS，变成一个比较完整的技术。

此外，Paas和SaaS之间的边界也变得不那么清晰。不少SaaS厂商以API形式来提供服务，把业务能力包装成一组组API，企业可以拿它的API来做集成或者开发，SaaS公司变成一个PaaS公司。

我们觉得未来基于Kubernetes的云原生平台也会是一个全栈云平台，不只是IaaS或者PaaS一层，就像主流的公有云一样，未来可以基于以Kubernetes为核心的云原生技术打造新一代全栈私有云混合云平台，最近重磅升级的ACP v3.0企业级全栈云原生平台，就是灵雀云在新一代全栈私有云混合云方面迈出的重要一步。

本文转自 https://www.kubernetes.org.cn/8715.html，如有侵权，请联系删除。