共计 8613 个字符，预计需要花费 22 分钟才能阅读完成。
简介： Kubernetes 自身并不间接产生商业价值，你不会花钱去购买 Kubernetes。这就跟安卓一样，你不会间接掏钱去买一个安卓零碎。Kubernetes 真正产生价值的中央也在于它的下层利用生态。
“将来的软件肯定是成长于云上的”，这是云原生理念的最外围假如。而所谓“云原生”，实际上就是在定义一条可能让利用最大水平利用云的能力、施展云的价值的最佳门路。因而，云原生其实是一套领导软件架构设计的思维。依照这样的思维而设计进去的软件：首先，人造就“生在云上，长在云上”；其次，可能最大化地施展云的能力，使得咱们开发的软件和“云”可能人造地集成在一起，施展出“云”的最大价值。
云原生的概念大家并不生疏，很多企业也曾经基于云原生的架构和技术理念落地相干实际。那么，这么多企业和开发者热衷和推崇的云原生，将来的发展趋势如何？如何能力适应云原生的支流方向去倒退？怎么在云原生时代“乘风破浪”？
咱们邀请到阿里云原生资深技术专家、CNCF 技术监督委员会代表，etcd 作者李响和阿里云高级技术专家、CNCF 利用交付畛域联席主席张磊分享云原生的理念、倒退以及将来趋势，为大家关上新的思路和眼界。
以下内容共享给大家。
一、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 原生化的基础设施的发展趋势。
云计算的下一站，就是云原生；IT 架构的下一站，就是云原生架构，这是属于所有开发者最好的时代。阿里云将于 7 月上线《云原生架构白皮书》，助力所有的开发者、架构师和技术决策者们，独特定义云原生，拥抱云原生。
