2020年注定是不凡的。它在阴霾中开始，在惊叹中结束，也让未来变得更加扑朔迷离。那么，容器与云原生的2020年呢？你是否记得它是怎样开始的？它又将走向何方？
1、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服务交付到在全世界任何一个数据中心上去。
2、正在被打破的云计算“三层架构”
长久以来，业界对云计算的认知，一直围绕着”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，只是进一步抽象的程度和依赖的垂直能力不同而已：这里并没有”谁盖在谁头上”这样的划分。
3、下一代云原生平台构建体系的崛起
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年诞生了像KubeVela这样专注于使能平台团队构建上层平台的开源项目。这个项目的定位在整个云原生生态中是非常独特的：它并不是某种垂直能力，它更像是一套基于Kubernetes构建上层平台的“工具”组合，比如：
基于模板的抽象机制，以及基于此生成能力使用文档和OpenAPI Schema的自动化流程（从而帮助平台团队快速构建Dashboard或者Appfile）；
基于OAM模型的插件式能力注册、管理与发现机制，以此来模块化、自动化的管理插件能力，甚至提前预警插件能力之间的冲突等。
无独有偶，在阿里云开源KubeVela项目后不久，云计算领头羊AWS在Re:Invent 2020上也高调宣布了AWS Proton商业产品的正式诞生，其思想同KubeVela项目非常类似，只不过构建平台的底座换成了AWS云平台，定义抽象的模板使用了AWS自己的Cloud Formation(KubeVela目前支持的是Google开源的CUELang模板语言）。
可以预见，在云原生与Kubernetes项目极大程度的统一与标准化了基础设施层抽象之后，如何进一步帮助平台团队在此之上快速、轻松、可复制的构建上层平台，正在成为业界开始积极思考的一条关键路径。再一次的，你很难在传统的云计算“三层架构”中找到适合这些产品的位置，无论是KubeVela还是AWS Proton，它们既不是PaaS，也不是IaaS，更不是Kubernetes的竞争者：它们是云原生背景下新一代平台构建体系逐步崛起的萌芽。
4、探索云原生的下一站
2020年的云原生可以说是整个云计算生态中发展最迅速的一条主线脉络，而也正是伴随着这样的发展劲头，云原生在新的一年里，已经要开始思考它的下一步发展空间。事实上，我们已经能够看到各种各样的厂商和团队在不同的领域积极发力和探索。
本地开发与测试
使能开发者面向Kubernetes进行本地开发和测试正在开始成为一个备受关注的话题，在这个领域中，来自纽约的Tilt项目是其中的佼佼者。阿里云和腾讯云有也分别有这个话题下的不同维度的解决方案，比如KT Connet和Nocalhost。
云原生“中间件”的技术变革
Sidecar模式正在以更加迅猛的势头的将中间件领域的能力下沉至Kubernetes这个新一代的应用基础设施当中，除了已经如火如荼的Istio对流量治理领域的颠覆，微软已经不甘示弱的开源了Open Service Mesh作为回应。而与此同时，OAM在微软的姊妹项目Dapr则直接拉齐了Kubernetes与中间件在“服务发现与绑定”侧的距离，老牌项目Dubbo亦宣布了下一代云原生中间件的技术蓝图。当然，所有这一切背后的用户动机是非常清晰的：云原生时代的中间件，要语言无关，要平台无关。
“边缘”与Kubernetes发行版
Kubernetes的“安卓化”趋势，少不了将Kubernetes部署到全世界任何一个数据中心去的“雄心壮志”，这里当然也包括“边缘”设备。除了华为的拳头产品KubeEdge之外，阿里云的OpenYurt项目在2020年也进入了CNCF沙箱孵化，而腾讯云则提出了SuperEdge紧随其后。与此同时，AWS在2020年重磅开源了其EKS服务背后的Kubernetes发行版EKS-D，这里当然隐含了对Google Cloud的Anthos和微软云的Arc布局的强势回应。可以预见，云厂商们对“将Kubernetes部署到任何一个角落”的这份执著，会让Kubernetes“安卓化”比想象中来得更快，也少不了在ISV和服务集成商侧的一番“腥风血雨”。
云原生应用管理与GitOps
云原生应用管理与交付，已然正在成为Kubernetes这个“新安卓”之上重要的价值聚焦点。在这个领域，阿里云联合微软的OAM+OpenKruise组合已经崭露头角，与此同时，社区上也出现了KubeVela这样进一步使能平台构建者的开源框架，开发者工具领域的佼佼者Hashicorp更是不失时机的发布了Waypoint这样的跨平台开发者界面工具。而伴随着Kubernetes之上的应用层技术快速演进的同时，基于Git作为应用配置管理中心交付应用的理念（即：GitOps），则正在迅速取代传统CI/CD中的CD环节，成为Kubernetes上应用分发的不二之选。在2020年末，CNCF应用交付领域小组正式宣布了GitOps Working Group的组建，很有可能会将GitOps逐步推向云原生CD的事实标准。在Kubernetes“安卓化”势不可挡的今天，我们对这个领域在新的一年即将出现的更多颠覆与创新充满期待。
5、2020年：没有“确切定义”的云原生
“云原生”到底是什么？它就是容器和Kubernetes吗？虚拟机是云原生的吗？……
这些“灵魂拷问”，一直是很多初次接触云原生理念的公司和团队常常提出的困惑。实际上，作为一套“以利用云计算技术为用户降本增效”的最佳实践与方法论，云原生这个术语自诞生，到壮大，到今天的极大普及，都处于一个不断的自我演进与革新的过程当中。这种“永远没有确切定义”的持续生命力，才是“云原生”之所以对云计算生态充满吸引力的源泉。
在2020年，整个云原生社区在不同领域的积极探索与尝试，正在取代Kubernetes、Service Mesh等已经成熟的实现项目，逐步成为云原生生态独一无二的主旋律。这其实不难理解，云原生发展到今天，正在离它所畅想的“软件天然生在云上、长在云上”越来越近，但也暴露出了现有的云原生技术底盘过分关注于基础设施抽象与管理、忽视了最终用户侧的体验和技术带来的诸多问题。这些问题，需要依靠整个云原生社区不停歇的思考、沉淀与再创新进行补充和修正，才能让云原生的技术价值逐步“上浮”，对最终用户产生直接的价值与体感；也才能让云原生技术逐步“民主化”，让构建简单、易用的云原生平台不再成为大公司们“秀肌肉”的专属。
