时代新宠——云原生

一 云原生：

1.definition：

云原生（CloudNative）是一个组合词，Cloud+Native。专门为在云平台部署和运行而设计的应用及架构。Cloud表示应用程序位于云中，而不是传统的数据中心；Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势。

符合云原生架构的应用程序应该是：采用开源堆栈（K8S+Docker）进行容器化，基于微服务架构提高灵活性和可维护性，借助敏捷方法、DevOps支持持续迭代和运维自动化，利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。

2. Three major characteristics

（1）容器化封装：以容器为基础，提高整体开发水平，形成代码和组件重用，简化云原生应用程序的维护。在容器中运行应用程序和进程，并作为应用程序部署的独立单元，实现高水平资源隔离。

（2）动态管理：通过集中式的编排调度系统（Kubernetes）来动态的管理和调度。

（3）面向微服务：明确服务间的依赖，互相解耦。

3.组成：

（1）微服务： 方法论 知道如何将应用程序解耦 切分成若干小组件或服务

微服务（或微服务架构）是一种云原生架构方法，其中单个应用程序由许多松散耦合且可独立部署的较小组件或服务组成。这些小组件或服务通常有自己的堆栈，包括数据库和数据模型；通过REST API，事件流和消息代理的组合相互通信；它们是按业务能力组织的，分隔服务的线通常称为有界上下文。

单体架构（Monolithic）：基于传统的Web开发方式，将很多功能从开发到交付都打包成一个很大的服务单元（一般称为 Monolith），而微服务实现和实施思路则更强调功能趋向单一，服务单元小型化和微型化。单体架构中所有的服务都写在一起，随着业务的复杂，代码的耦合度就会越来越高，不便于将来的升级维护。

微服务架构：微服务架构中，每个微服务模块只是对简单、独立、明确的任务进行处理，通过REST API返回处理结果给外部。在微服务推广实践角度来看，微服务将整个系统进行拆分，拆分成更小的粒度，保持这些服务独立运行，应用容器化技术将微服务独立运行在容器中。微服务在拆分的时候，会根据业务功能模块把一个单体的应用拆分成许多个独立的项目，每个项目完成一部分的业务功能，然后独立开发和部署。这些独立的项目就成为一个微服务，进而构成一个服务集群。这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。

（2）容器化：容器将依赖环境一起打包，因而屏蔽了开发、测试和运行环境的差异，再加上秒启、可多开的特性，使得微服务得以实现。云原生的最佳载体。

A 容器化是一套技术体系，云计算的一个必然导向。为微服务提供实施保障，起到应用隔离作用，K8S是容器编排系统，用于容器管理，容器间的负载均衡。

B虚拟机：操作系统级别的资源隔离 减轻对硬件的依赖

容器：进程级的系统隔离 轻量级的虚拟化技术 应用程序隔离，可以解决虚拟机能够解决的问题，同时也能够解决虚拟机由于资源要求过高而无法解决的问题。

传统虚拟机包含完整的操作系统，一旦开启即对硬件资源的一部分独占。容器引擎只是隔离进程，对资源并不独占，因此是一种更轻量的虚拟化。这使得容器在文件体积、启动速度、占用资源和开启数量上都具有明显优势。

C：Docker 创建容器的主流工具，已成云平台运行分布式、微服务化应用的行业标准基本技术。它的优势在于可以让开发者将企业需要的各种应用及应用依赖文件封装在Docker镜像文件中，然后在任何物理设备（Linux设备或Window设备等）上安装运行实现虚拟化，让应用程序彻底脱离底层设备，可以在物理机之间灵活迁移部署，使运维工程师摆脱了繁琐的环境部署，极大的提高了工作效率，同时减少了部署过程中的潜在风险。

D：边缘计算网关基于“硬件平台化，业务APP化”的设计理念，终端功能由APP软件定义，用户基于基础服务接口开发自定义APP，并实现在边缘计算网关的灵活部署，快速适应业务需求复杂多变的物联场景。边缘计算网关支持部署Docker容器，用户可在部署的容器上安装自己的业务APP，同时网关设备提供各种eSDK接口供容器和APP调用其资源。

E ：Docker的三大组成要素：

镜像：Docker镜像是一个特殊的文件系统，除了提供容器运行时所需的程序、库、资源、配置等文件外，还包含了一些为运行时准备的配置参数。镜像不包含任何动态数据，其内容在构建之后也不会被改变。镜像可以用来创建Docker容器，用户可以使用设备上已有的镜像来安装多个相同的Docker容器。

容器：镜像创建的运行实例，Docker利用容器来运行应用。每个容器都是相互隔离的、保证安全的平台。我们可以把容器看做是一个轻量级的Linux运行环境。

镜像仓库：集中存放镜像文件的地方。用户创建完镜像后，可以将其上传到公共仓库或者私有仓库，需要在另一台主机上使用该镜像时，只需要从仓库上下载即可。

（3）DevOps：

Dev+Ops（Development+Operation），就是开发和运维合体让开发人员和运维人员更好地沟通合作，DevOps是一个敏捷思维，是一个沟通文化，也是组织形式，为云原生提供持续交付能力。

在DevOps的流程下，运维人员会在项目开发期间就介入到开发过程中，了解开发人员使用的系统架构和技术路线，从而制定适当的运维方案。而开发人员也会在运维的初期参与到系统部署中，并提供系统部署的优化建议。

（4）持续交付：

持续交付是一个整体过程，从一个业务端的想法到系统功能可以面对客户的全流程。让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以发布的状况。它的目标在于让软件的构建、测试与发布变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。持续交付的能力通过自动化流水线的方式实现，减少研发过程中不必要的浪费，近而缩短整个研发过程中所有需求的交付周期。

（5）容器+微服务+DevOps是实现云原生的最佳组合 （只有容器是一种比较明确的技术，而微服务和DevOps更像是一种方法论。） 代码复用率 可移植性 可拓展性

“微服务”，就是将原来黑盒化的一个整体产品进行拆分（解耦），从一个提供多种服务的整体，拆成各自提供不同服务的多个个体—从单体式架构（Monolithic）→ 微服务架构（Microservices）

虚拟化，其实就是一种敏捷的云计算服务。它从硬件上，将一个系统“划分”为多个系统，系统之间相互隔离。

容器就更彻底，不是划分为不同的操作系统，而是在操作系统上划分为不同的“运行环境”（Container），占用资源更少，部署速度更快。

容器编排工具是指让集群中的多个容器能够按计划、有组织运行的工具。（Kubernetes）

容器将依赖环境一起打包，因而屏蔽了开发、测试和运行环境的差异，再加上秒启、可多开的特性，使得微服务和DevOps均得以实现。所以可以说，容器技术是云原生的最佳载体，成为云原生的基石。

二：边缘计算云原生开源方案选型比较

1.Kubernetes**：** 容器编排系统由于屏蔽了底层架构的差异性，可以帮助应用平滑地运行在不同的基础设施上的特性，云上的 Kubernetes 服务也在考虑拓展其服务边界，云原生和边缘计算结合的想法自然就呼之欲出了。将Kubernetes强大的容器管理能力扩展到边缘计算场景中，针对边缘计算场景中常见的技术挑战提供了解决方案，如：单集群节点跨地域、云边网络不可靠、边缘节点穿透内网注册等，帮助用户轻松地部署应用到边缘计算节点上，安全可靠地服务

**2.**对比关注点：

相较于Kubernetes 的能力增强点；主要关注边缘自治，边缘单元化，轻量化等能力

架构差异带来的影响: 主要关注运维监控能力，云原生生态兼容性，系统稳定性等方面

	KubeEdge	OpenYurt	SuperEdge	K3s
背景：	华为云于 2018 年 11 月份开源的，CNCF的孵化项目。	OpenYurt 是阿里云于 2020 年 5 月份开源的，目前是 CNCF 沙箱项目。	SuperEdge 是腾讯云于 2020 年 12 月底开源的，目前还是开源初期阶段。	CNCF官方认证的Kubernetes发行版，K3S专为在资源有限的环境中运行Kubernetes的研发和运维人员设计，目的是为了在x86、ARM64和ARMv7D架构的边缘节点上运行小型的Kubernetes集群。
架构图	fig.1.	fig.2.	fig.3.	fig.4
差异	1.云端(k8s master)增加了 Cloud Hub 组件和各类 controller， 2.边缘端(k8s worker)没有原生的 kubelet 和 kube-proxy，而是一个对原生组件进行重写了 EdgeCore 组件 3.EdgeCore 是基于 kubelet 重构的，为了保证轻量化，裁剪了原生 kubelet 的部分能力，同时也增加了很多适配边缘场景的能力	1. 架构设计简洁，采用无侵入式对Kubernetes进行增强。 2.在云端(K8s Master)上增加 Yurt Controller Manager, Yurt App Manager 以及 Tunnel Server 组件。 3.边缘端(K8s Worker)上增加了 YurtHub 和 Tunnel Agent 组件。从架构上看主要增加适配边缘场景的能力。	1.架构设计比较简洁，也是采用的无侵入式对 Kubernetes 进行增强 2.在云端(K8s Master)上增加 Application-Grid Controller, Edge-Health Admission 以及 Tunnel Cloud 组件。 3.边缘端(K8s Worker)上增加了 Lite-Apiserver 和 Tunnel Edge，Application-Grid Wrapper 组件。从架构上主要增加了边缘适配能力	K3S就是基于一个特定版本Kubernetes，减少运行Kubernetes所需的资源，以及运行时占用空间；
特点	1**.****边缘自治：通过增加节点元数据缓存，可以规避云边断网状态下，边缘业务或者节点重启时，边缘组件可以利用本地缓存数据进行业务恢复。 可以离线自治。 2.**轻量化: edge-core 的运行负载低，削减了部分kubelet功能(如CSI，CNI等)，从而使边缘 EdgeCore 组件相比原生kubelet 组件更加轻量。同时因为节点上增加了SQLite数据库。 3. **简化开发：**开发人员可以编写基于HTTP或MQTT的常规应用程序，对其进行容器化，然后在Edge或Cloud中的任何一个更合适的位置运行应用程序。	**1.**边缘单元化：在边缘场景下，边缘节点通常具备很强的区域性、地域性，不同地域的节点间往往存在网络不互通、资源不共享、资源异构等明显的隔离属性。跨越不同节点的service流量会出现访问不可达、或者访问效率低下的问题。 **2.**边缘自治: 因为每个边缘节点增加了具备缓存能力的透明代理 YurtHub，从而可以保障云边网络断开，如果节点或者业务重启时，可以利用本地缓存数据恢复业务。 **3.****无缝转换。**它提供了一种工具，可以轻松地将本机Kubernetes转换为“边缘”就绪。 **4.****云平台不可知。**OpenYurt可以轻松部署在任何公共云Kubernetes服务中	与SuperEdge大同小异，特点类似 1**.****边缘自治：当边端节点与云端网络不稳定或者断连时，边缘节点依旧可以正常运行，不影响已经部署的边缘服务 2. 分布式健康检查：**superedge提供边端分布式健康检查能力，每个边缘节点会部署edge-health，同一个边缘集群中的边缘节点会相互进行健康检查，对节点进行状态投票。这样即便云边网络存在问题，只要边缘端节点之间的连接正常，就不会对该节点进行驱逐；整个设计避免了由于云边网络不稳定造成的大量的pod迁移和重建，保证了服务的稳定 3. **服务访问控制：**superedge自研了ServiceGroup实现了基于边缘计算的服务访问控制，极大地方便边缘集群服务的发布与治理 **4.****云边隧道：**支持自建隧道(目前支持TCP, HTTP and HTTPS)打通不同网络环境下的云边连接问题	1.K3S的所有组件（包括Server和Agent**）都运行在边缘，因此不涉及云边协同。如果K3S要落到生产，在K3S之上应该还有一个集群管理方案负责跨集群的应用管理、监控、告警、日志、安全和策略等**
Kubernetees 架构差异 可能带来的影响	1.****跟随Kubernetes社区同步演进挑战大:由于对Kubernetes 系统的侵入式修改，后续跟随 Kubernetes 社区的演进将会遇到很大挑战。 2. 边缘节点无法运行 Operator：云边通信机制的修改，Cloud Hub 只能往边缘推送有限的几种资源(如 Pod，ConfigMap 等)。而 Operator 既需要自定义 CRD 资源，又需要 list/watch 云端获取关联资源，因此社区的 Operator 无法运行的 KubeEdge 的边缘节点上。 **3.**边缘节点不适合运行需要 list/watch **云端的应用：**云边通信机制的修改，导致原来需要使用 list/watch 机制访问 kube-apiserver 的应用，都无法通过 hub tunnel 通道访问 kube-apiserver，导致云原生的能力在边缘侧大打折扣。 4. 系统稳定性需要提升	**1.**原生 Kubernetes 带来的系统稳定性挑战：OpenYurt 没有修改 Kubernetes，当云边长时间断网再次恢复时，边缘到云端会产生大量的全量 List 请求，从而对 kube-apiserver 造成比较大的压力。边缘节点过多时，将会给系统稳定性带来不小的挑战。 2. 边缘无轻量化解决方案: 虽然 OpenYurt 没有修改 Kubernets，但是在边缘节点上增加 YurtHub 和 Tunnel Agent 组件。	同OpenYurt类似	减少运行时空间资源占用轻量级别的k8s（k3s 将安装 Kubernetes 所需的一切打包进仅有 60MB 大小的二进制文件中，并且完全实现了 Kubernetes API。为了减少运行 Kubernetes 所需的内存）
边缘计算场景支持能力（边缘场景的设备管理能力）	设备管理能力: 这个能力直接集成在 edged 中，给 iot 用户提供了一定的原生设备管理能力。 无边缘健康检测能力	无设备管理能力：OpenYurt 目前没有提供设备管理的相关能力，需要用户以 workload 形式来运行自己的设备管理解决方案。 无边缘健康检测能力	无设备管理能力 安全及流量消耗待优化
稳定性挑战	接入设备数量过多	大规模节点 云边长时间断网恢复	大规模节点 云边长时间断网恢复

fig.1.

fig.2.

fig.3.

fig.4.

如果需要内置设备管理能力，而对云原生生态兼容性不在意，建议选择 KubeEdge

如果从云原生生态兼容和项目成熟度考虑，而不需要设备管理能力或者可以自建设备管理能力，建议选择 OpenYur