简介：到底什么是“云原生”？仅仅是容器和Kubernetes吗？虚拟机是云原生的吗？...2020年注定不平凡。开始于灰暗，结束于惊奇，让未来更加扑朔迷离。那么，2020年容器和云原生呢？你还记得它是怎么开始的吗？它会去哪里？Kubernetes：企业基础设施的标准抽象2020年，没有人会质疑一个平台团队采用Kubernetes作为自己基础设施的合理性。事实上，2020年的Kubernetes项目已经非常接近完成其最重??要的使命，即：为云计算基础架构带来平台层抽象，允许平台团队在其之上构建“一切”。我们已经可以看到，今天的云原生社区已经开始广泛认可Kubernetes项目“Theplatformforplatform”的定位和价值。越来越多的平台团队基于Kubernetes构建各种上层平台，如PaaS/Serverless/AIPlatform/DatabasePaaS等。面向最终的声明式API及其背后“苦干”的控制器，为“构建基础设施层抽象”这一具有挑战性的技术问题提供了一个能够在复杂性和可用性之间取得平衡的解决方案。正是基于此，Kubernetes项目拥有庞大的集成生态系统，使得这种“企业基础设施的标准抽象”逐渐成为业界公认的事实。更重要的是，Kubernetes真正的成功在于它真正押注于构建抽象的方法而不是抽象本身。大多数情况下，企业会引入其他各种抽象作为补充，构建基于Kubernetes的上层平台，甚至会替换或隐藏一些Kubernetes内置的抽象：阿里巴巴开源的CloneSet、腾讯的GameStatefulSet实践以及其他扩展的Workloads等。是这种趋势的最好例子。随着Kubernetes生态从底层到应用层能力的逐步完善，2020年将有更多的大型互联网终端企业开始加入云原生梯队。我们看到原先的Mesos生态标杆Apple成为了KubeCon2020北美的绝对主角，金融巨头MasterCard分享了他们内部基于OAM、Kubernetes和跨平面项目。特别值得一提的是，这些以往在底层基础技术上给人“保守”印象的非云大公司，在2020年纷纷提出要落地VirtualCluster、标准应用模型技术等多项新兴技术。和思考。云原生浪潮对整个科技行业的深远影响可见一斑。另外，不难观察到，Kubernetes的大火以及基于它的上层生态，越来越多地与安卓（Android）的发展路径趋同。Android可以将手机、电视、甚至汽车等不同的硬件设备进行统一的抽象和集成，对外暴露出一套统一的开发接口给程序员，让他们利用这种统一的抽象来开发Access或享受这些基础设施的能力。这个定位和Kubernetes很像。这里唯一不同的是，Android服务程序员是APP开发者，而Kubernetes服务“程序员”是平台建设者。在这样的背景下，“Kubernetes放弃Docker”等新闻就很容易理解了：Android本身并不需要关注手机电池的品牌。这条路也可能是谷歌擅长的“玩法”：免费推广一款“操作系统”，而真正获得商业价值的方式是“收割”操作系统上层的生态价值，不是操作系统。本身。毕竟用户是不会花钱买安卓的。所以谷歌云目前是All-in，就是通过像Anthos这样的Kubernetes混合云基础，将谷歌云服务交付到全球任何一个数据中心。正在被打破的云计算“三层架构”长期以来，业界对云计算的认知始终围绕着“SaaS+PaaS+IaaS”的经典三层架构模式展开。然而到了2020年，随着云原生技术的大火，我们发现这种模式似乎面临着挑战。今天的云原生技术源于Docker和容器的创新技术革命，得益于经典PaaS（如CloudFoundry）的长期普及。最终，在开发者和平台搭建者的双重关注下，作为载体的Kubernetes生态终于落地。2020年，随着云原生技术的逐渐成熟，面向用户的应用管理平台的形态逐渐开始从经典的以CloudFoundry/Heroku为主体的PaaS形态转变（即：企业级PaaS）以轻量级AppService为例，Shipa和Kalm正在靠拢。但是，轻量级的AppService本质上是在Kubernetes基础上对Heroku体验的翻版。在提供优秀开发者体验的同时，也继承了经典PaaS的“封闭性”和“不可扩展性”，这在很多大企业中普遍存在，在自身基于云原生的“PaaS”诉求下依然力不从心技术堆栈“DIY”。事实上，对于越来越多的平台搭建者而言，随着云原生技术的逐步落地，“PaaS”本身的“解释权”不再属于某个提供商，而更多地取决于平台搭建者。业务场景及其最终用户的实际需求。此外，对于“SaaS”而言，云原生带来的容器化软件打包交付体系和Kubernetesbase也极大地改变了云软件的分发和运维方式。因此，无论是PaaS还是SaaS，本质上都在被“云原生”技术的浪潮快速“扁平化”。在此背景下，传统的“横向”划分云计算系统的方法实际上变得难以保持一致。一个典型的例子是：今天你既不能叫KubernetesPaaS，也不能叫IaaS。它是基础设施能力接入层和平台层的独特抽象。作为平台搭建者，你可以基于它搭建你心目中的任何上层平台。至于你把这个上层平台称为PaaS/Serverless/FaaS，甚至是SaaS，只是进一步抽象的程度和依赖的垂直能力不同：没有“谁在谁头上”这样的划分。下一代云原生平台构建体系的兴起和Kubernetes的成功，极大地赋能了“平台构建者”这一此前被企业成本中心（CostCenter）遗忘的重要角色。事实上，Kubernetes之所以能够取代Docker生态，成为当今云计算平台上的主角，很大一部分原因在于这个群体的最终决定。否则，按照Docker已经达到的用户群体规模和在开发者生态中的接受度，Kubernetes几乎没有胜算。这一点往往被大家所忽视。事实上，在一个企业级平台落地的过程中，虽然平台的终端用户（如业务研发和运维）是“客户和上帝”，但他们真正能够在这个过程中起到关键作用，并拥有最终决策权。往往是业务背后的平台团队和老板。但与此同时，基于Kubernetes的平台构建的生态在今天仍然是高度集中的。一个典型的观察是，如今能够基于Kubernetes构建完整上层平台的团队实际上集中在一二线的大型互联网公司，他们的做法往往“仅供参考”，很少可复制。再者，云原生的大火似乎并不能真正让平台搭建者轻松搭建PaaS或其他上层平台。这实际上进一步解释了我们早前观察到的云原生时代“PaaS生态”的停滞：基于Kubernetes构建上层平台（包括PaaS）在2020年仍将是大公司和高科技团队的专利。这种高度中心化的平台构建生态，显然与CloudNative希望构建的“普惠”未来不符。当然，技术发展跟不上愿景，云原生社区不会停止。事实上，平台搭建者基于Kubernetes进一步搭建上层平台的根本动力来自两个需求：一个是更高的抽象维度：比如用户想要操作的概念是“应用”和“灰度发布”，而不是“容器”和“豆荚”。更具扩展性：比如用户想要的灰度发布策略是基于“双部署+Istio”的金丝雀发布，而不是Kubernetes默认的pod线性滚动升级。这些增强或扩展在Kubernetes中通常以CRD+Controller插件的形式实现。因此，基于Kubernetes构建上层平台在今天看来可能杂乱无章，但本质上不会离开“抽象+插件能力管理”两大核心诉求。再举个例子，现在大家为Kubernetes构建的各种Dashboard，其实都是一种“抽象”的实现：这些Dashboard本质上是暴露了一组字段，用户可以在KubernetesAPI对象的基础上进行填写，从而达到“简化”的目的用户的使用心智，提升用户体验”已经实现——这当然是一切“抽象”的根本目标。基于对“抽象+插件能力管理”两大诉求的不断实践和思考，云原生社区将在2020年催生出像KubeVela这样专注于赋能平台团队构建上层平台的开源项目。这个项目的定位在整个云原生生态中是非常独特的：它不是一个垂直的能力，更像是一套基于Kubernetes搭建上层平台的“工具”，比如：基于模板的抽象机制，并基于此生成能力使用文档和OpenAPISchema的自动化过程（从而帮助平台团队快速构建Dashboard或Appfile）。采用基于OAM模型的插件能力注册、管理和发现机制，实现插件能力管理的模块化和自动化，甚至可以对插件能力之间的冲突进行预警。无独有偶，在阿里云开源KubeVela项目后不久，云计算龙头AWS也在Re:Invent2020上宣布了AWSProton商用产品的正式诞生。AWS云平台使用AWS自带的CloudFormation来定义抽象模板（KubeVela目前支持谷歌开源的CUELang模板语言）。可以预见，在云原生和Kubernetes项目对基础设施层的抽象进行了极大的统一和规范之后，如何进一步帮助平台团队在其之上快速、便捷、可复现地构建上层平台成为业界的积极考虑。一条关键路径。再次，你很难在传统的云计算“三层架构”中为这些产品找到合适的位置。无论是KubeVela还是AWSProton，它们既不是PaaS也不是IaaS，更不是Kubernetes的竞争对手：它们是云原生背景下逐渐兴起的新一代平台构建体系的萌芽。探索云原生的下一站2020年云原生可以说是整个云计算生态中发展最为迅猛的主线，也正是借助这种发展势头，云原生在新的一年里已经开始发力.开始思考它的下一个发展空间。事实上，我们已经看到了各个厂商和团队在不同领域积极的努力和探索。本地开发测试===========开发测试本地开发测试开始成为开发者高度关注的话题。在这个领域，来自纽约的TILT项目就是其中之一。经过。阿里云和腾讯云在这个话题下也有不同维度的解决方案，比如KTConnet、Nocalhost。云原生“中间件”的技术变革==================Sidecar模式正在将中间件领域的能力下沉到新一代应用基础Kubernetes当中设施方面，除了Istio对流量管理领域的颠覆已经如火如荼，微软也不甘示弱，开源了OpenServiceMesh作为回应。同时，OAM在微软的姊妹项目Dapr在“服务发现和绑定”端直接拉近了Kubernetes与中间件的距离。老项目Dubbo也公布了下一代云原生中间件的技术蓝图。当然，这一切背后的用户动机非常明确：云原生时代的中间件必须是语言无关、平台无关的。“边缘”和Kubernetes分布===========================================================================================================================================================================================================================================================================================要“雄心勃勃””，这里当然也包括“边缘”设备。除了华为的旗舰产品KubeEdge，阿里云的OpenYurt项目也在2020年进入CNCF沙箱孵化，腾讯云提出SuperEdge紧随其后。同时，AWS在2020年重磅开源了其EKS服务背后的Kubernetes发行版EKS-D，这当然意味着对谷歌云的Anthos和微软云的Arc布局的强烈回应。可以预见，云厂商“将Kubernetes部署到任何角落”的执念，将使Kubernetes“安卓化”的速度比预期更快，ISV和服务集成商这边将掀起一场“血雨腥风”。.云原生应用程序管理和GitOps==========================================================云原生应用程序管理和交付已经成为Kubernetes这一“新安卓”的重要价值焦点。在这个领域，出现了阿里云和微软的OAM+OpenKruise组合。与此同时，进一步赋能平台建设者的开源框架KubeVela和开发者工具领域的领导者Hashicorp也纷纷亮相社区。发布了Waypoint等跨平台开发人员界面工具。随着Kubernetes上应用层技术的快速演进，基于Git作为应用配置管理中心的应用交付理念（即：GitOps）正在迅速取代传统CI/CD中的CD环节，成为Kubernetes上的应用分发平台.最好的选择。2020年底，CNCF应用交付领域团队正式宣布成立GitOps工作组，很可能将GitOps逐步推向云原生CD的事实标准。如今，Kubernetes的“安卓化”已势不可挡，期待新的一年在该领域有更多的颠覆与创新。2020：没有“明确定义”的云原生究竟什么是“云原生”？仅仅是容器和Kubernetes吗？虚拟机是云原生的吗？……这些“灵魂拷问”一直是很多刚接触云原生概念的公司和团队经常提出的困惑。事实上，作为一套“利用云计算技术为用户降本增效”的最佳实践和方法论，云原生这个词从诞生、成长到今天的伟大时代，一直处于不断自我发展的状态。知名度。在进化和创新的过程中。这种“从未被准确定义”的持续生命力，正是“云原生”对云计算生态如此具有吸引力的源泉。2020年，整个云原生社区在不同领域的积极探索和尝试，正在取代Kubernetes、ServiceMesh等成熟的落地项目，逐渐成为云原生生态的独特主题。其实不难理解，云原生发展到今天，越来越接近其想象中的“软件在云上诞生、成长”，但也暴露出现有的云原生技术底盘过于注重专注在基础设施抽象和管理上，忽略了终端用户体验和技术带来的诸多问题。这些问题需要通过整个云原生社区的不断思考、沉淀和再创新来补充和修正，让云原生的技术价值逐渐“浮起来”，为终端用户产生直接的价值和意义；只有这样，云原生技术才能逐渐“民主化”，让搭建简单易用的云原生平台不再是大公司“秀肌肉”的专属领域。作者：张磊原文链接本文为阿里云原创内容，未经允许不得转载
