2020 年注定是不凡的。它在阴霾中开始，在惊叹中结束，也让未来变得更加扑朔迷离。那么，容器与云原生的 2020 年呢？你是否记得它是怎样开始的？它又将走向何方？
Kubernetes：企业基础设施的标准抽象
在 2020 年，没有人再会去质疑一个平台团队采纳 Kubernetes 作为自己的基础设施的合理性。事实上，2020 年的 Kubernetes 项目已经非常接近于地完成了它最重要的使命，即：为云计算基础设施带来一层可以让平台团队基于此构造“一切”的平台层抽象。
我们已经能够看到，今天的云原生社区已经开始广泛认可 Kubernetes 项目作为“The platform for platform”的定位与价值，越来越多的平台团队正在基于 Kubernetes 构建各种各样的上层平台，比如 PaaS / Serverless / AI Platform / Database PaaS 等等。面向终态的声明式 API 与其背后“辛勤”工作的控制器，为“构建基础设施层抽象”这个充满了挑战的技术难题，提供了一个能够在复杂度与可用性之间取得平衡的解决方案。正是基于此，Kubernetes 项目才拥有了庞大的集成生态，让这个“企业基础设施的标准抽象”，逐步成为了业界公认的事实。
而更为重要的是，Kubernetes 真正的成功之处，在于它真正押注的是构建抽象的方法而非这些抽象本身。在绝大多数情况下，企业基于 Kubernetes 构建上层平台，都会引入各种各样其他的抽象作为补充，甚至取代或者隐藏掉 Kubernetes 的部分内置抽象：阿里巴巴开源的 、腾讯的 实践等扩展型工作负载等都是这个趋势的最好的案例。
伴随着 Kubernetes 生态从底层到应用层能力的逐步完善，在 2020 年，更多大型互联网终端企业开始加入到了云原生的梯队当中。我们看到原本的 Mesos 生态标杆 Apple 公司成为了 KubeCon 2020 北美上的绝对主角，而金融巨头 MasterCard 则分享了他们基于 OAM、Kubernetes 和 Crossplane 项目构建跨云、跨运行时应用交付平台的内部落地案例。而尤为值得一提的是，这些以往在底层基础技术上给人以”保守“印象的大型非云企业，在 2020 年纷纷祭出了对很多新兴技术比如 和上的落地与思考。云原生浪潮对整个技术产业带来的深远影响可见一斑。
此外，我们也不难观察到，Kubernetes 的极大普及以及基于它兴起的上层生态，正在跟安卓（Android）的发展路径越来越明显的趋同。安卓能够对下以一套统一的方式抽象与集成不同的手机、电视、甚至汽车等硬件设备，对上则为程序员暴露出统一的一套开发接口，使他们能够以这套统一的抽象去访问或者享受到这些基础设施能力。这种定位与 Kubernetes 非常类似，这里唯一的区别在于，安卓服务的程序员是 APP 开发者，而 Kubernetes 服务的“程序员”，则是平台构建者。在这个背景下，诸如“Kubernetes 抛弃 Docker”之类的新闻会很容易理解：安卓本身就不需要专注于手机的电池是哪个牌子的。
这个路径，可能也是 Google 比较擅长的一个“打法”：全力地去免费推广一个“操作系统”，真正获取商业价值的方式则是是去“收割”操作系统远程桌面上层的生态价值，而不是操作系统本身。毕竟用户是不会花钱去购买安卓的。所以 Google Cloud 目前正在 All-in 的，正是通过 这样的 Kubernetes 混合云底座，将 Google Cloud 服务交付到在全世界任何一个数据中心上去。
正在被打破的云计算“三层架构”
长久以来，业界对云计算的认知，一直围绕着“SaaS + PaaS + IaaS”这样经典的三层架构模型展开。然而，在 2020 年，随着云原生技术的极大普及，我们却发现这个模型似乎正遭受着挑战。
今天的云原生技术，起源于 Docker 以及容器这个创新性的技术革命，又受益于经典 PaaS （比如 Cloud Foundry）持续已久的心智普及，最终在开发者与平台构建者的双重关注下，以 Kubernetes 生态为载体最终落地。
在 2020 年，伴随着云原生技术逐步成熟，面向用户的应用管理平台的形态也逐渐开始从以 Cloud Foundry/Heroku 为主体的经典 PaaS 形态（即：企业级 PaaS），向轻量级的 App Service 比如 和 等方向靠拢。不过，轻量级 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 进一步构建上层平台，其根本动机无非来自两个诉求：
更高的抽象维度：比如，用户希望操作的概念是“应用”和“灰度发布”，而不是“容器”和“Pod”。
更多的扩展能力：比如，用户希望的应用灰度发布策略是基于“双 Deployment + Istio” 的金丝雀发布，而不是 Kubernetes 默认的 Pod 线性滚动升级。这些增强或者扩展能力，在 Kubernetes 中一般是以 CRD + Controller 的插件方式来实现的。
所以说，基于 Kubernetes 构建上层平台在今天看起来似乎杂乱无章、没什么规律，但本质上都不会离开“抽象 + 插件能力管理”这两个核心诉求。再举个例子，今天大家为 Kubernetes 构建的各种 Dashboard，其实就是一种“抽象”的实现方式：这些 Dashboard 本质上是在 Kubernetes API 对象的基础上暴露出了一组允许用户填写的字段，从而实现了“简化用户使用心智、提升用户体验”的目的 —— 这当然也是所有“抽象”的根本目标。
基于对“抽象 + 插件能力管理”这两个诉求的持续实践与思考，云原生社区在 2020 年诞生了像 这样专注于使能平台团队构建上层平台的开源项目。这个项目的定位在整个云原生生态中是非常独特的：它并不是某种垂直能力，更像是一套基于 Kubernetes 构建上层平台的“工具”组合，比如：
基于模板的抽象机制，以及基于此生成能力使用文档和 OpenAPI Schema 的自动化流程（从而帮助平台团队快速构建 Dashboard 或者 Appfile）。
基于 OAM 模型的插件式能力注册、管理与发现机制，以此来模块化、自动化的管理插件能力，甚至提前预警插件能力之间的冲突等。
联系客服
