2020年注定是一个特殊的年份。它在困惑中开端，在惊喜中结束，使得未来的走向更加难以预测。那么，容器与云原生的2020年又是如何开始的？它们又将走向何方？
1. KubeRnetes：企业基础设施的标准抽象
在2020年，企业平台团队采纳KubeRnetes作为基础设施的合理性已不再受到质疑。实际上，KubeRnetes项目已经接近完成其最重要的使命：为云计算基础设施提供一层抽象，使平台团队能够在此基础上构建各种平台。
如今，云原生社区广泛认可KubeRnetes项目作为“平台之平台”的角色与价值，越来越多的平台团队基于KubeRnetes构建多种上层平台，如PaaS、Serverless、AI平台和数据库PaaS等。这种面向终态的声明式API以及其背后的“辛勤”控制器，为“构建基础设施层抽象”这一复杂技术难题提供了在复杂性和可用性之间取得平衡的解决方案。因此，KubeRnetes项目拥有了庞大的集成生态，逐渐成为业界公认的企业基础设施标准抽象。
更为重要的是，KubeRnetes的成功在于它关注构建抽象的方法，而非抽象本身。大多数企业在基于KubeRnetes构建上层平台时，往往引入其他抽象以补充，甚至替代或隐藏KubeRnetes的一部分内置抽象，比如阿里巴巴的CloneSet和腾讯的GameStatefulSet等实践都是这一趋势的典型案例。
伴随KubeRnetes生态的逐步完善，2020年更多大型互联网企业加入了云原生的行列。我们看到，曾经的Mesos生态标杆苹果公司在KubeCon 2020北美大会上成为了焦点，而金融巨头MasterCard分享了他们基于OAM、KubeRnetes和Crossplane项目构建跨云、跨运行时应用交付平台的案例。值得注意的是，这些过去在基础技术上较为“保守”的大型非云企业，在2020年纷纷对新兴技术如虚拟集群和标准应用模型展开了深入的探索与实践，云原生浪潮对整个技术产业的影响显而易见。
此外，KubeRnetes的广泛应用及其上层生态的崛起，已与安卓的发展路径越来越相似。安卓通过一套统一的方式抽象与集成不同的硬件设备，同时为开发者提供统一的开发接口，允许他们以此访问基础设施能力。这一定位与KubeRnetes十分相似，唯一的区别在于，安卓服务的开发者是应用开发者，而KubeRnetes服务的“开发者”则是平台构建者。在这种背景下，“KubeRnetes抛弃Docker”之类的新闻也就不难理解：安卓本身不需要专注于手机的电池品牌。
这种路径可能是Google擅长的“打法”：全力推广一个“操作系统”，而真正获取商业价值的方式是“收割”操作系统上层的生态价值，而不是操作系统本身。用户不会为安卓付费。因此，Google Cloud目前正在全力以赴地通过Anthos这一KubeRnetes混合云基础设施，将Google Cloud服务扩展到全球各地的数据中心。
2. 云计算“三层架构”的挑战
长期以来，业界对云计算的认知始终围绕着“SaaS + PaaS + IaaS”这一经典三层架构模型。然而，2020年随着云原生技术的广泛普及，这一模型似乎正面临挑战。
今天的云原生技术源于Docker及容器的创新革命，并受益于经典PaaS（如Cloud Foundry）的持续影响，最终在开发者与平台构建者的共同关注下，以KubeRnetes生态为载体实现落地。
随着云原生技术的逐步成熟，2020年面向用户的应用管理平台开始从以Cloud Foundry/Heroku为主体的经典PaaS形态向轻量级应用服务（如Shipa和Kalm）靠拢。然而，轻量级应用服务本质上仍是Heroku体验在KubeRnetes基础上的复刻，它们在提供卓越的开发者使用体验的同时，继承了经典PaaS的“封闭性”与“不可扩展性”，在许多大型企业基于云原生技术栈“DIY”其专属PaaS的过程中显得力不从心。
实际上，对于越来越多的平台构建者而言，随着云原生技术的逐步落地，“PaaS”的“解释权”不再属于某一家提供商，而是更多依赖于平台构建者的业务场景及其终端用户的实际需求。此外，云原生带来的容器化软件打包与交付体系以及KubeRnetes底座，已大幅改变了云端软件的分发与运维方式。因此，无论是PaaS还是SaaS，本质上都在被“云原生”的技术浪潮快速“压平”，这种背景下，传统的“水平”划分云计算体系的方法已显得难以自洽。例如，今天你既不能将KubeRnetes称作PaaS，也不能称作IaaS。它是一个独特的基础设施能力接入层与平台层抽象，作为平台构建者，你可以基于它构建任何上层平台，而将其称作PaaS、Serverless、FaaS，甚至SaaS，仅仅是对进一步抽象程度和依赖的垂直能力的不同而已：并不存在“谁盖在谁头上”的划分。
3. 下一代云原生平台构建体系的崛起
KubeRnetes的成功极大地赋能了“平台构建者”这一过去被忽视的重要角色。实际上，KubeRnetes能够取代Docker生态成为今天云计算平台主角，很大程度上是这个群体做出了决定。否则，按照Docker触达的用户规模和在开发者生态中的接受度，KubeRnetes几乎没有胜算。这一点往往被忽视。实际上，在企业级平台落地的过程中，最终用户（如业务研发与运维）虽然是“顾客与上帝”，但真正能起到关键作用并拥有最终决定权的，往往是业务背后的平台团队和管理者。
然而，KubeRnetes之上的平台构建生态在今天依然高度集中。如今，能够基于KubeRnetes构建完整上层平台的团队主要集中在一线和二线大型互联网公司，且其实践往往“仅供参考”，可复制性不强。进一步来看，云原生的广泛普及似乎并未真正使平台构建者轻松构建PaaS或其他上层平台。这也进一步解释了我们之前观察到的“PaaS生态”在云原生时代的停滞：基于KubeRnetes构建上层平台（包括PaaS）在2020年依然是大型公司和高技术水准团队的专利。
这种平台构建生态的高度集中与云原生希望实现的“普惠式”未来显然不符。当然，既然技术发展尚未跟上愿景，云原生社区也不会停止前进的步伐。
实际上，平台构建者基于KubeRnetes构建上层平台的根本动机无非源自两个诉求：
更高的抽象维度：用户希望操作的概念是“应用”和“灰度发布”，而非“容器”和“Pod”；更多的扩展能力：用户希望的应用灰度发布策略是基于“双Deployment + Istio”的金丝雀发布，而非KubeRnetes默认的Pod线性滚动升级。这些增强或扩展能力在KubeRnetes中通常通过CRD + Controller的插件方式来实现。
因此，基于KubeRnetes构建上层平台在今天看似杂乱无章，但本质上都围绕着“抽象 + 插件能力管理”这两个核心诉求展开。再以KubeRnetes构建的各种Dashboard为例，这些Dashboard实际上是一种“抽象”的实现方式：它们在KubeRnetes API对象的基础上暴露出一组允许用户填写的字段，以此简化用户使用心智、提升用户体验，这也是所有“抽象”的根本目标。
在对“抽象 + 插件能力管理”这两个诉求的持续实践与思考中，云原生社区在2020年诞生了KubeVela这一专注于赋能平台团队构建上层平台的开源项目。该项目在整个云原生生态中具有独特定位：它并非某种垂直能力，而是一套基于KubeRnetes构建上层平台的“工具”组合，例如：
基于模板的抽象机制，以及基于此生成能力使用文档和OpenAPI Schema的自动化流程（帮助平台团队快速构建Dashboard或appfile）；基于OAM模型的插件式能力注册、管理与发现机制，以此来模块化能力的构建与使用。
