转载自： https://www.cnblogs.com/doit8791/p/9825621.html
由浙江大学、Google、RedHat、华为等企业于2015年共同参与成立的云原生基金会（Cloud Native Computing Foundation，CNCF）秉承着协助、使能、鼓励（help, enable, encourage）的宗旨，海纳百川，是当前在容器、微服务、云原生领域最活跃的社区之一。CNCF通过构建并推广一系列的开源技术和标准，为在云原生 时代构建动态（dynamic）、分布式（distributed）环境下的可伸缩（scalable）、可运维（operable）、可观测 （observable）的敏捷应用与服务提供先进可靠的技术路线。
图 1 CNCF组织构建的云原生生态图谱
以CNCF社区第一个宣布毕业的开源容器编排项目Kubernetes的代码贡献量统计为例，我们可以观察到企业、高校和个人的紧密协作和贡献是 CNCF社区得以蓬勃发展的基石，自社区创立以来浙大一直积极持续的在社区进行投入，贡献度始终排名全球第一梯队，与华为一起领跑国内 Kubernetes社区生态。
技术标准化是开源社区健康发展的保障
如同生物多样性对生物界进化的作用一般，技术多样性同样是技术得以不断演化与进步的保证。当前CNCF社区已经包含了20多个开源项目，而由 CNCF绘制的云原生生态图谱则包含了超过500种开源技术（图 1）。在这样充满技术多样性的生态系统中，技术标准保障了不同类型的技术无缝对接，防止出现同类技术恶意竞争的情况，是生态系统健康发展的重要保障。
2015年，CNCF成立之初，社区创始成员们就对技术标准化做出了富有建设性的设想，并做了CNCF社区未来工作范围的总体架构设计（见图2）， 其中包括了资源调度、分布式系统服务、应用定义与编排等技术组件与一系列技术间的对接标准。众多的尚处于设想中的技术标准，其中相当一部分，在2018年 的今天都已经成为了现实，包括容器运行时接口标准（Container Runtime Interface）、容器存储接口标准（Container Storage Interface）和容器网络接口标准（Container Network Interface）。当然在当今丰富的生态系统中也包含了CNCF成立之初没有考虑到的技术标准，包括开放服务代理标准（Open Service Broker API）、云事件标准（Cloud Event）等等。
云原生开源技术圈流行一句话：“infrastructure should be boring“，即IT基础设施相关技术逐渐趋于稳定。Open Container Initialitive（简称OCI）组织的出现，以及以containerd/runc为代表的基础容器运行时参考实现的广泛采用，标志着云原生时代 的第一层基础设施的稳定化。而Kubernetes在容器编排领域的胜出，则代表了云原生时代的第二层技术设施的稳定化。
这些底层技术的稳定使得生态系统内的其他厂商有信心在相关技术上继续投入，同样也使得终端用户有信心尝试和采用云原生、微服务技术。更为重要的是为云原生生态内的上层技术的繁荣带来的强大的助推作用。
以Kubernetes API为基础，在CNCF社区中出现了大量Kubernetes-Native的上层技术，包括Service Mesh类的Istio、Linkerd等，云原生存储类的Rook项目，服务无计算/函数计算类的fission项目，快速部署管理深度学习框架的 kubeflow项目，大数据类框架管理的Spark on Kubernetes，复杂应用定义与管理类的ksonnet、Helm项目等。这些上层技术的出现使得云原生可以被应用到更为广泛的场景中，除了常见的 无状态/有状态应用之外，也包括serverless、AI、大数据等多种场景，并反过来推进了Kubernetes等云原生技术的进一步推广。
需要指出的是，在基础设施稳定化的大趋势下，也存在一些底层的新兴力量，比如近期Google发布的gVisor运行时技术，在遵循OCI运行时标准的同时，为容器运行时的实现带来了全新的思路。
无服务的兴起和云计算抽象层次的提升
无服务计算（serverless）是新近加入到云原生生态图谱中的一大类新兴技术。我们不应把无服务计算等价为某项具体的技术（比如亚马逊的 Lambda），也不应该将它等价为某类具体的技术（比如函数计算）。无服务技术代表了云计算服务抽象层次的提升。作为终端用户，不再需要关于底层技术设 施（如虚拟机集群的规格定义和管理），而将注意力集中到更高抽象层次的应用开发上去。
CNCF社区中的服务无生态图谱
从这个角度理解无服务计算，我们可以认为无服务计算是新的也是旧的。说它是旧的，因为它包括IT领域之前早就出现过的Mobile- Backend-as-a-Service（MBaaS），也包括2011年开源的经典PaaS技术Cloud Foundry+BOSH+IaaS（虽然当时并未从serverless角度考虑，但通过BOSH自动调用IaaS层接口，我们可以实现基础设施的透明 化管理，即实现根据工作负载动态调整Cloud Foundry所使用的IaaS虚拟机集群的规模，因此虽然PaaS和FaaS等serverless技术有所区别，我们将Cloud Foundry+BOSH+IaaS技术也归类到无服务计算中）。说它是新的，因为以AWS Lambda为代表的函数计算，以及更为近期的AWS Fargate和Azure ACI（Azure Container Instances）以及华为云CCI（Cloud Container Instance）服务正在不断扩充无服务计算的内涵。浙江大学一直致力于新型云计算技术的研发，早在2011年就开始参与Cloud Foundry开源项目，而在近期又参与到fission等开源FaaS项目中。
无服务计算符合云计算一直以来细化分工、提升生产力的总体思想，我们可以预测，无服务计算将不仅限于函数计算，而将在未来演化出多种形式的计算模 式，而面向无服务计算的安全、监控等多方面相关技术生态将进一步繁荣（当前CNCF的无服务生态图谱中仅仅包含工具、框架等少数类别，如图 4所示）。由于涉及到应用架构的演进，无服务计算的落地不会发生在一夜之间，而将结合微服务技术，在未来的几年里缓慢推进。而在此过程中类似CNCF社区 中的virtual kubelet技术将作为新旧架构应用开发运维模式的衔接与桥梁。
云-边-端一体化的计算新格局
IDC此前的数据显示，随着5G的到来和IoT的发展，到2020年，将有超过500亿的终端设备联网。而考虑到带宽的消耗、网络的延迟、以及数据 隐私性保护等挑战，在智慧城市、智慧医疗、智能制造、智能家居等数据量庞大、对处理延迟敏感、对数据隐私敏感的场景下，终端设备产生的数据中有超过半数需 要在终端设备或网络边缘侧就近分析处理，而中心化的云端只处理计算资源需求大、实时性要求不高的计算任务，如AI模型训练。未来的计算不仅仅局限在大型数 据中心，而将分布在由云-边-端构成的一体化连续频谱上。
从计算平台的角度看，云-边-端一体化的计算新格局至少提出了以下两大挑战：边缘操作系统和端云一体化管理平台。
当我们把终端设备和接入网关等构成的集群当做一个个的小型数据中心，每个边缘节点不再运行单一的任务，而是变成一个可以动态执行被调度该节点的多类 型任务的通用计算节点。因此边缘操作系统不仅仅需要负责边缘设备上的任务调度、存储网络管理等传统操作系统职责，也需要提供一套完整的安全隔离机制，以防 止动态调度到同一边缘设备上任务之间的相互影响。
而容器作为一类轻量级的操作系统隔离技术就可以在这里发挥作用。根据不同场景下资源的丰富程度和功能需求，在具体做法上我们可以看到部署完整的 Docker方案的实践，也可以看到更加轻量化的以containerd/runc为基础构建的开源IoT平台eliot，或者类似百度IoT Intelligent Edge平台那样基于Linux内核的namespace，cgroup技术直接构建定制化容器隔离的技术方案。浙江大学在这方面的研究主要围绕着 unikernel技术，相比常见的containerd/runc容器技术，通过rumpkernel，OSv等unikernel技术可以进一步减少 攻击面，减少资源占用和加快响应速度，实现边缘设备上安全计算环境。
端云一体化管理平台负责管理边缘设备构成的大量小型数据中心。开源社区已经有关于如何将Kubernetes等优秀的容器编排引擎应用到大量小型数 据中心的管理上。2018年5月在丹麦哥本哈根举行的KubeCon+CloudNativeCon大会上开辟了专门的session讨论 Kubernetes与边缘计算话题。跟CNCF同在Linux基金会下的EdgeX Foundry社区也发起了EdgeX Foundry on Kubernetes，即将该社区的边缘计算平台EdgeX运行在Kubernetes之上，利用Kubernetes完成资源调度管理的技术讨论。微软 的IoT Edge Virtual Kubelet开源项目旨在讨论如何使用Kubernetes构建包含传统数据中心和边缘计算的混合端云一体化管理平台。
微软的IoT Edge Virtual Kubelet开源项目架构，使用Kubernetes构建包含传统数据中心和边缘计算的混合端云一体化管理平台。图片来 源：github.com/azure/iot-edge-virtual-kubelet-provider