解锁云原生新场景 | 云原生加速云边端一体化发展

云原生加速云边端一体化发展

“十四五”规划中明确提出要“协同发展云服务与边缘计算服务”，同时国务院《“十四五”数字经济发展规划》也指出要“加强面向特定场景的边缘计算能力”。随着我国云计算进入普惠发展期，边缘计算需求激增，云边端一体化已然成为未来重要演进方向。

云原生和边缘计算技术的广泛应用和深度融合，必将进一步加速云边端一体化的落地实践进程。

云原生边缘计算架构

下面结合灵雀云的边缘计算解决方案为大家介绍完整的边缘计算整体架构，这个架构包含终端、边缘和云三个部分，终端部分可以是摄像头、传感器、VGA、机器人等。第二部分边缘端，依据离边缘设备的远近我们进一步划分为边缘网关、近边缘和远边缘三种类型的计算环境。

边缘网关也就是A部分，是与设备紧密相连的，数据从边缘向云传输的第一跳，一般采用有线或者无线方式与设备直接相连。边缘网关有应用类型多，设备接口使用多的特点，采用容器技术关键在于提升网关的融合度，将多类型网关合而为一。在我遇到的边缘计算项目里，最初客户的边缘网关按照接口不同，距离设备的距离不同，采用20多个arm板卡管理不同的设备，在采用容器后，我们进行了资源融合，最终方案仅使用9个arm板卡，资源节约了一半。

近边缘也就是B部分，通常是按照边缘局点部署的，一个商超、加油站、高速收费站、飞机等都算一个近边缘计算环境。这种环境与设备之间的网络延时需要控制在2ms左右。这种平台通常是由三个以上物理服务器节点构成，是边缘计算的重要组成部分。这个部分的特点是承载了重要的边缘业务，需要支持会更多一些，例如存储、网络、GPU、中间件、微服务框架等，但是整体资源还是比较紧张。容器平台恰恰适应这样的运算环境。不仅仅为业务提供基础运行支持，还能够保障业务的弹性伸缩、故障自愈、批量发布等，为业务带来额外的价值。

下一个计算环境是远边缘，也就是C部分。这种环境是按区域部署的，和端点之间的网络延时控制在10ms左右。这一部分我之所以把它放在边缘计算和云计算之间，是因为在有些客户的计算模型中并不存在这一部分，或者这一部分会演化成企业私有云，这完全依据业务层级架构。从基础设施的视角看，远边缘就是一朵能力齐全的私有云，由于业务形态比较多，一般需要支持虚拟机和容器两种计算模型。幸运的是，Kubernetes拥有Kubevirt这样项目，让我们能够采用云原生的方式管理虚拟机，在现实中，这已经不算新技术，在运营商等场景中已经得到广泛的使用。在远边缘环境中，我们采用软件定义数据中心的思路，采用k8s作为底座，承载数据中心所需要的一切计算、网络、存储、负载均衡、安全等能力。另外，在远边缘上还有对于近边缘以及边缘网关的统一管理能力，管理对象包括业务和平台侧的管理。

最后是云计算环境，也就是D部分。这一部分也就是我们一般都理解的IaaS、PaaS等能力。对于远边缘环境的统一管理我们采用分布式云架构，可以在云里对远边缘环境进行应用下推、统一运维，平台升级等操作。

值得一提的是，在实践中，并非每个客户必须遵循这样复杂庞大的架构，通常客户需要的是整套架构的一个子集，这完全取决于客户业务架构。

在灵雀云的边缘计算架构中，我们并不是从零构建这样一套复杂的架构。而是在已经稳定运行、并且经数百家头部企业客户验证的成熟产品架构基础上，进行少量的扩展和增强，使之适应边缘计算环境特点，从而保证这套解决方案有足够的丰富的功能和足够的稳定性。

K8s容器+边缘计算=edge-native

平台本质上是为了更好地支持业务，业务的灵活性、稳定性才是我们追求的最终目标。在边缘计算领域，我们会用edge-native来描述能够充分发挥边缘能力的业务类型，这类似于cloud-native描述了运行在云里的新型业务类型。容器不仅仅为边缘计算提供了良好的基础设施，更能够有效支持edge-native业务的开发和运行。这里我们逐一分解edge-native业务的七个特征：

第一，业务通常是层级架构的。从边缘网关到近边缘到远边缘，最后到云，业务的不同部分运行在不同的层级环境中，他们共同构成了完整的业务。容器所提供的多级边缘管理能力与边缘计算实际建设架构完全匹配，而且容器可以提升业务层级部署的灵活性，业务可以快速的从云里下沉到边缘，或者从边缘迁移到云中。

第二，业务需要cache。这和边缘侧有大量的数据处理有关，边缘计算自身无法解决此类问题，传统情况下只能业务自己解决。当我们采用容器后，容器可以轻松把中间件、数据库服务下沉到边缘网关或者近边缘环境中，无论是x86服务器还是arm盒子。

第三，业务需要弹性伸缩。正是由于边缘计算资源有限，弹性伸缩这种灵活的资源调配机制显得更有价值，在传统边缘计算的模型中，基础设施无法帮助业务解决此类问题，需要在业务层面解决此类问题，这给业务带来很大的麻烦。然而弹性伸缩是容器的强项，在标准的k8s中，就包含了HPA的能力，它可以通过简单的配置，让业务依据CPU、内存、监控指标进行弹性扩缩容，实现资源更集约化使用。

第四，业务形态应该是多个小服务组成。这种小服务概念借鉴了云端微服务的概念，他强调服务要尽量小，能够适配到更紧凑的设备中，并且减少服务之间的依赖，能够实现快速的服务拼装。这点正是容器的优势，容器自身就是小服务最佳的承载工具，另外像服务网格这种技术也有利于针对C、C++、Java等业务实现服务治理，能够帮助开发快速排障。

第五，edge-native是近地服务。业务的设备、数据、交互完全发生在边缘侧，大家可以想象一下加油站、商超、高速收费站这类场景。容器中的服务路由技术可以进行灵活的业务发布，不仅实现就地服务，还能实现极端情况下的跨地服务。

第六，故障自愈。故障时边缘计算的常见现象，因为边缘侧没有稳定的制冷、防震措施，导致要比数据中心更容易发生故障，这极大的提升了企业的运维成本。我的有些客户，需要在每个地市雇佣几个人维护局点业务的正常运行。容器Pod副本管理技术可以实现快速故障自愈，一旦探针发现业务无法服务，容器平台会快速将业务进行重启、迁移等操作，确保有足够的副本运行在集群中。

最后，安全诉求也是edge-native典型特征。这是由于边缘计算增加了攻击点。而容器早已经解决了运算、网络、存储上的隔离性问题，而DevSecOps可以帮助业务提升代码安全、镜像安全。更重要的是，一旦事后发现软件供应链发生了漏洞问题，例如最近发生的 Ngnix 0day漏洞问题，需要升级业务才能够解决此问题，而在容器环境，我们可以通过业务批量更新快速解决漏洞问题，甚至平台自身的问题也可以通过一键式平台升级解决。

edge-native是业务的目标，但绝不仅仅是业务开发团队的责任，类似于cloud-native，需要我们在基础设施、在平台侧给与足够的支持，而容器就是实现edge-native的重要技术手段。

容器边缘 VS 超融合边缘

在和客户的沟通中，部分客户在犹豫是否应该采用超融合解决边缘平台的问题，这里我们可以简单仅从技术角度对比一下超融合和容器对边缘计算的适配程度。

这里我们抽象了超融合和容器技术的架构，左侧是超融合架构，通常在局点上部署几台超融合服务器，在云端通过云管平台实现对边缘侧的统一管理；右侧是容器技术，在局点上部署Kubernetes管理物理服务器，在云端通过容器云管实现对边缘侧的统一管理。

我们可以从云端到边缘侧逐一比对这两种方案。首先在云端，超融合方案管理对象是虚拟机，本质上管理的是资源，无法感知到应用的运行情况；而容器方案管理的对象却是容器，也就是业务本身，这对业务运维就非常友好了，我们更多关注的是业务运行得好不好，而非仅仅是资源。

在云边网络层面，除了常规的管理流、监控流数据，一个重要的带宽占用对象是虚拟机镜像或者容器镜像，容器镜像大小与业务自身相似，是虚拟机镜像的1%-10%。因此当我们下发一个镜像到边缘侧，容器技术在网络层面可以极大程度上节约本就紧俏的云边网络带宽。

而在边缘侧，超融合采用的虚拟机运行业务，虚拟机运行起来后，每个虚拟机需要独立操作系统，因此虚拟机的运行资源占用是比较高的。而容器是共享操作系统，一个容器所占的运行时资源和容器内的业务基本相似，没有额外支出。这样容器技术资源占用上有巨大的优势，可以留给业务更多的CPU、内存等运行资源。

另外，最重要的还是平台对业务的支持上，容器更加精简灵活，故障自愈、弹性伸缩、灰度发布本身就是容器的强项，而这些采用虚拟化实现都过于笨重。

所以，在和客户商讨方案后，大部分客户都喜欢纯容器边缘方案，采用容器支持近边缘或者边缘网关的建设，而在远边缘、云端会采用虚拟化、超融合、容器共建的方式。

云原生边缘计算赋能ISV交付运维

传统边缘计算有其明确的使用场景，是业务向数据靠近的过程。当前越来越多的ISV开始考虑通过采用类边缘计算的方案来提升业务交付运维的效率。这部分ISV包括教育、医疗、广电等行业。

传统情况下，ISV需要针对每一个客户进行现场部署、现场开发，一个项目需要几周到几个月甚至几年的现场服务，这推高了ISV的人力成本。

为了解决该问题，ISV开始采用边缘计算方案实现远端业务统一交付、运维。方案很简单，在每一个客户环境中部署容器管理平台，也就是K8s，在云中部署边缘管理模块，然后打通客户环境到云环境网络，从而实现通过云环境对客户业务的统一运维。这种架构可以在一定程度上提高客户服务的响应速度，同时降低项目现场服务成本。目前这还是一种创新的技术模式，但在未来也许会帮助企业形成新的商业模式，提升运营能力，实现持续收入。