2020 年注定是不凡的。它在阴郁中开始，在惊叹中完结，也让将来变得更加错综复杂。那么，容器与云原生的 2020 年呢？你是否记得它是怎么开始的？它又将走向何方？

Kubernetes：企业基础设施的规范形象

在 2020 年，没有人再会去质疑一个平台团队驳回 Kubernetes 作为本人的基础设施的合理性。事实上，2020 年的 Kubernetes 我的项目曾经十分靠近于地实现了它最重要的使命，即：为云计算基础设施带来一层能够让平台团队基于此结构 “ 所有 ” 的平台层形象。

咱们曾经可能看到，明天的云原生社区曾经开始宽泛认可 Kubernetes 我的项目作为“The platform for platform”的定位与价值，越来越多的平台团队正在基于 Kubernetes 构建各种各样的下层平台，比方 PaaS / Serverless / AI Platform  / Database PaaS 等等。面向终态的申明式 API 与其背地“辛勤”工作的控制器，为“构建基础设施层形象”这个充斥了挑战的技术难题，提供了一个可能在复杂度与可用性之间获得均衡的解决方案。正是基于此，Kubernetes 我的项目才领有了宏大的集成生态，让这个“企业基础设施的规范形象”，逐渐成为了业界公认的事实。

而更为重要的是，Kubernetes 真正的胜利之处，在于它真正押注的是构建形象的办法而非这些形象自身。在绝大多数状况下，企业基于 Kubernetes 构建下层平台，都会引入各种各样其余的形象作为补充，甚至取代或者暗藏掉 Kubernetes 的局部内置形象：阿里巴巴开源 CloneSet、腾讯的 GameStatefulSet 实际等扩大型工作负载等都是这个趋势的最好的案例。

随同着 Kubernetes 生态从底层到应用层能力的逐步完善，在 2020 年，更多大型互联网终端企业开始退出到了云原生的梯队当中。咱们看到本来的 Mesos 生态标杆 Apple 公司成为了 KubeCon 2020 北美上的相对配角，而金融巨头 MasterCard 则分享了他们基于 OAM、Kubernetes 和 Crossplane 我的项目构建跨云、跨运行时利用交付平台的外部落地案例。而尤为值得一提的是，这些以往在底层根底技术上给人以”激进“印象的大型非云企业，在 2020 年纷纷祭出了对很多新兴技术比方 Virtual Cluster 和规范利用模型技术上的落地与思考。云原生浪潮对整个技术产业带来的深远影响可见一斑。

此外，咱们也不难察看到，Kubernetes 的极大遍及以及基于它衰亡的下层生态，正在跟安卓（Android）的倒退门路越来越显著的趋同。安卓可能对下以一套对立的形式形象与集成不同的手机、电视、甚至汽车等硬件设施，对上则为程序员暴露出对立的一套开发接口，使他们可能以这套对立的形象去拜访或者享受到这些基础设施能力。这种定位与 Kubernetes 十分相似，这里惟一的区别在于，安卓服务的程序员是 APP 开发者，而 Kubernetes 服务的“程序员”，则是平台构建者。在这个背景下，诸如“Kubernetes 摈弃 Docker”之类的新闻会很容易了解：安卓自身就不须要专一于手机的电池是哪个牌子的。

这个门路，可能也是 Google 比拟善于的一个“打法”：全力地去收费推广一个“操作系统”，真正获取商业价值的形式则是是去“收割”操作系统下层的生态价值，而不是操作系统自身。毕竟用户是不会花钱去购买安卓的。所以 Google Cloud 目前正在 All-in 的，正是通过 Anthos 这样的 Kubernetes 混合云底座，将 Google Cloud 服务交付到在全世界任何一个数据中心下来。

正在被突破的云计算“三层架构”

长久以来，业界对云计算的认知，始终围绕着“SaaS + PaaS + IaaS”这样经典的三层架构模型开展。然而，在 2020 年，随着云原生技术的极大遍及，咱们却发现这个模型仿佛正蒙受着挑战。

明天的云原生技术，起源于 Docker 以及容器这个创新性的技术反动，又受害于经典 PaaS（比方 Cloud Foundry）继续已久的心智遍及，最终在开发者与平台构建者的双重关注下，以 Kubernetes 生态为载体最终落地。

在 2020 年，随同着云原生技术逐渐成熟，面向用户的利用治理平台的状态也逐步开始从以 Cloud Foundry/Heroku 为主体的经典 PaaS 状态（即：企业级 PaaS），向轻量级的 App Service 比方 Shipa 和 Kalm 等方向聚拢。不过，轻量级 App Service 实质上还是 Heroku 体验在 Kubernetes 底座上的复刻，它们在提供杰出的开发者应用体验的同时，也继承了经典 PaaS 的“关闭”与“不可扩大”，这在很多大型企业基于云原生技术栈“DIY”属于本人的“PaaS”的诉求下，仍然会显得力不从心。

事实上，对于越来越多的平台构建者来说，随着云原生技术的日趋落地，“PaaS”自身的“解释权”不再属于某一家提供商，而更多取决于平台构建者的业务场景和其终端用户的理论需要。此外，对于“SaaS”来说，云原生带来的容器化软件打包与交付体系和 Kubernetes 底座，也曾经极大地扭转了云端软件的散发与运维形式。所以，无论是 PaaS 也好，还是 SaaS 也好，实质上正在被“云原生”的技术浪潮迅速“压平”，在这种背景下，传统 “ 程度 ” 划分云计算体系的办法其实曾经变得难以自洽。一个典型的例子就是：明天你既不能把 Kubernetes 称作是 PaaS，也不能把它称作是 IaaS。它是一个独特的基础设施能力接入层与平台层形象，作为平台构建者，你能够基于它构建你心目中任何下层平台，而至于你把这个下层平台称作是 PaaS / Serverless / FaaS，甚至是 SaaS，只是进一步形象的水平和依赖的垂直能力不同而已：这里并没有”谁盖在谁头上”这样的划分。

下一代云原生平台构建体系的崛起

Kubernetes 的胜利，极大使能了“平台构建者”这个以往被人们忘记在企业老本核心（Cost Center）里的重要角色。事实上，Kubernetes 之所以可能取代 Docker 生态成为明天云计算平台上的配角，很大水平上是这个群体做出了最终的决定。否则，依照 Docker 所触达到的源码交易用户群体规模以及其在开发者生态中的被接收度，Kubernetes 简直毫无胜算。这一点常常是被大家所漠视的。实际上，在企业级平台落地的过程中，平台的最终用户（比方业务研发与运维）尽管是“顾客与上帝”，但真正能在这个过程中起到关键作用和具备最终决定权的，往往还是业务背地的平台团队和老板们。

但与此同时，Kubernetes 之上的平台构建生态，在明天仍然是高度集中的。一个典型的察看就是，明天可能基于 Kubernetes 成体系构建出残缺下层平台的团队，其实集中在一、二线大型互联网公司当中，并且其实际往往“仅供参考”，鲜有可复制性。进一步的，云原生的极大遍及，仿佛并没有真正可能让平台构建者轻松地构建 PaaS 或者其余下层平台。这其实也进一步解释了后面咱们察看到的“PaaS 生态“在云原生时代的停滞：基于 Kubernetes 构建下层平台（包含 PaaS），在 2020 年仍然是大型公司和高技术水位团队们的专利。

这种平台构建生态的高度集中，与云原生心愿构建的“普惠式”将来，显然是不相符的。当然，既然技术倒退还没有跟上愿景，那么云原生社区也就不会停下脚步。

事实上，平台构建者之所以要基于 Kubernetes 进一步构建下层平台，其基本动机无非来自两个诉求：

1. 更高的形象维度：比方，用户心愿操作的概念是“利用”和“灰度公布”，而不是“容器”和“Pod”。
2. 更多的扩大能力：比方，用户心愿的利用灰度公布策略是基于“双 Deployment + Istio”的金丝雀公布，而不是 Kubernetes 默认的 Pod 线性滚动降级。这些加强或者扩大能力，在 Kubernetes 中个别是以 CRD + Controller 的插件形式来实现的。

所以说，基于 Kubernetes 构建下层平台在明天看起来仿佛横七竖八、没什么法则，但实质上都不会来到“形象 + 插件能力治理”这两个外围诉求。再举个例子，明天大家为 Kubernetes 构建的各种 Dashboard，其实就是一种“形象”的实现形式：这些 Dashboard 实质上是在 Kubernetes API 对象的根底上暴露出了一组容许用户填写的字段，从而实现了“简化用户应用心智、晋升用户体验”的目标 —— 这当然也是所有“形象”的基本指标。

基于对“形象 + 插件能力治理”这两个诉求的继续实际与思考，云原生社区在 2020 年诞生了像 KubeVela 这样专一于使能平台团队构建下层平台的开源我的项目。这个我的项目的定位在整个云原生生态中是十分独特的：它并不是某种垂直能力，更像是一套基于 Kubernetes 构建下层平台的“工具”组合，比方：

1. 基于模板的形象机制，以及基于此生成能力应用文档和 OpenAPI Schema 的自动化流程（从而帮忙平台团队疾速构建 Dashboard 或者 Appfile）。
2. 基于 OAM 模型的插件式能力注册、治理与发现机制，以此来模块化、自动化的治理插件能力，甚至提前预警插件能力之间的抵触等。

独一无二，在阿里云开源 KubeVela 我的项目后不久，云计算领头羊 AWS 在 Re:Invent 2020 上也高调发表了 AWS Proton 商业产品 的正式诞生，其思维同 KubeVela 我的项目十分相似，只不过构建平台的底座换成了 AWS 云平台，定义形象的模板应用了 AWS 本人的 Cloud Formation (KubeVela 目前反对的是 Google 开源的 CUELang 模板语言）。

能够预感，在云原生与 Kubernetes 我的项目极大水平地对立与标准化了基础设施层形象之后，如何进一步帮忙平台团队在此之上疾速、轻松、可复制地构建下层平台，正在成为业界开始积极思考的一条要害门路。再一次的，你很难在传统的云计算“三层架构”中找到适宜这些产品的地位，无论是 KubeVela 还是 AWS Proton，它们既不是 PaaS，也不是 IaaS，更不是 Kubernetes 的竞争者：它们是云原生背景下新一代平台构建体系逐渐崛起的萌芽。

摸索云原生的下一站

2020 年的云原生能够说是整个云计算生态中倒退最迅速的一条主线脉络，而也正是随同着这样的倒退劲头，云原生在新的一年里，曾经要开始思考它的下一步倒退空间。事实上，咱们曾经可能看到各种各样的厂商和团队在不同的畛域踊跃发力和摸索。

1. 本地开发与测试

使能开发者面向 Kubernetes 进行本地开发和测试正在开始成为一个备受关注的话题，在这个畛域中，来自纽约的 Tilt 我的项目是其中的佼佼者。阿里云和腾讯云也别离有这个话题下的不同维度的解决方案，比方 KT Connet 和 Nocalhost。

1. 云原生“中间件”的技术改革

Sidecar 模式正在以更加迅猛的势头将中间件畛域的能力下沉至 Kubernetes 这个新一代的利用基础设施当中，除了曾经热火朝天的 Istio 对流量治理畛域的颠覆，微软曾经不甘示弱的开源了 Open Service Mesh 作为回应。而与此同时，OAM 在微软的姊妹我的项目 Dapr 则间接拉齐了 Kubernetes 与中间件在“服务发现与绑定”侧的间隔，老牌我的项目 Dubbo 亦发表了下一代云原生中间件的技术蓝图。当然，所有这所有背地的用户动机是十分清晰的：云原生时代的中间件，要语言无关，要平台无关。

1. “边缘”与 Kubernetes 发行版

Kubernetes 的“安卓化”趋势，少不了将 Kubernetes 部署到全世界任何一个数据中心去的“雄心壮志”，这里当然也包含“边缘”设施。除了华为的拳头产品 KubeEdge 之外，阿里云的 OpenYurt 我的项目在 2020 年也进入了 CNCF 沙箱孵化，而腾讯云则提出了 SuperEdge 紧随其后。与此同时，AWS 在 2020 年重磅开源了其 EKS 服务背地的 Kubernetes 发行版 EKS-D，这里当然隐含了对 Google Cloud 的 Anthos 和微软云的 Arc 布局的强势回应。能够预感，云厂商们对“将 Kubernetes 部署到任何一个角落”的这份执著，会让 Kubernetes“安卓化”比设想中来得更快，也少不了在 ISV 和服务集成商侧的一番“腥风血雨”。

1. 云原生利用治理与 GitOps

云原生利用治理与交付，未然正在成为 Kubernetes 这个“新安卓”之上重要的价值聚焦点。在这个畛域，阿里云联结微软的 OAM + OpenKruise 组合曾经锋芒毕露，与此同时，社区上也呈现了 KubeVela 这样进一步使能平台构建者的开源框架，开发者工具畛域的佼佼者 Hashicorp，更是不失时机的公布了 Waypoint 这样的跨平台开发者界面工具。而随同着 Kubernetes 之上的应用层技术疾速演进的同时，基于 Git 作为利用配置管理核心交付利用的理念（即：GitOps），则正在迅速取代传统 CI/CD 中的 CD 环节，成为 Kubernetes 上利用散发的不二之选。在 2020 年末，CNCF 利用交付畛域小组正式发表了 GitOps Working Group 的组建，很有可能会将 GitOps 逐渐推向云原生 CD 的事实标准。在 Kubernetes“安卓化”势不可挡的明天，咱们对这个畛域在新的一年行将呈现的更多颠覆与翻新充斥期待。

2020 年：没有“确切定义”的云原生

“云原生”到底是什么？它就是容器和 Kubernetes 吗？虚拟机是云原生的吗？……

这些“灵魂拷问”，始终是很多首次接触云原生理念的公司和团队经常提出的困惑。实际上，作为一套“以利用云计算技术为用户降本增效”的最佳实际与方法论，云原生这个术语自诞生，到壮大，再到明天的极大遍及，都处于一个一直的自我演进与变革的过程当中。这种“永远没有确切定义”的继续生命力，才是“云原生”之所以对云计算生态充斥吸引力的源泉。

在 2020 年，整个云原生社区在不同畛域的积极探索与尝试，正在取代 Kubernetes、Service Mesh 等曾经成熟的实现我的项目，逐渐成为云原生生态举世无双的主旋律。这其实不难理解，云原生倒退到明天，正在离它所畅想的“软件人造生在云上、长在云上”越来越近，但也暴露出了现有的云原生技术底盘过分关注于基础设施形象与治理、漠视了最终用户侧的体验和技术带来的诸多问题。这些问题，须要依附整个云原生社区不停歇的思考、积淀与再翻新进行补充和修改，能力让云原生的技术价值逐渐“上浮”，对最终用户产生间接的价值与体感；也能力让云原生技术逐渐“民主化”，让构建简略、易用的云原生平台不再成为大公司们“秀肌肉”的专属。