2023云边端协同的智能视频方案

云边端协同的智能视频方案1VV目录一、需求分析 1二、方案技术框架 3三、关键技术详解 5（一）数据传输和存储技术 5（二）设备和应用管理 5设备统一管控 6应用管理 9可观测性 12（三）云边端调度 14单机轻量容器引擎 14云边通道 23云边协同调度 27节点分组 32（四）算法维度 37智能视频服务架构 37弹性调度系统 48（五）视频维度 55端侧数据采集技术 55端侧推理任务平台 56边侧端数据接入、AI分析和关键存证数据 58（六）安全相关 59容器安全 59盒子鉴权 61mtls证书 62（七）硬件平台支持技术 63云边协同硬件服务器介绍 63基于IntelTDX的机密计算 75比亚迪边缘视频加速服务器硬件方案 89四、案例分享 95百度边缘音视频案例 95边云协同的视频分析技术在智慧校园之明厨亮灶中应用 97智慧零售 100五、总结和展望 102PAGEPAGE102云边端协同的智能视频方案研究报告一、需求分析随着人们对视频需求的不断增加，视频应用场景也不断扩大，包括监控、视频会议、在线教育、智慧城市、智能家居等领域，使得对视频处理能力的要求越来越高。云计算技术的快速发展为实现云边端协同的智能视频方案提供了技术支持，可以大大提高视频处理效率和准确性，并实现分布式计算和存储。物联网技术的广泛应用使得设备之间的连接更加紧密，也为云边端协同的智能视频方案提供了技术支持，可以实现设备之间的信息传递和互操作。人工智能技术的不断进步和发展，尤其是深度学习等技术的应用，使得智能视频处理更加智能化和高效化，提高了视频处理的准确性和自动化程度。随着安全和隐私需求的提高，对视频处理的要求也越来越高，特别是在监控和安全领域。云边端协同的智能视频方案可以更好地保障视频数据的安全性和隐私性，提高整个系统的可靠性。综上所述，云边端协同的智能视频需求背景主要源于视频应用场景的扩大、云计算技术的快速发展、物联网技术的广泛应用、人工智能技术的进步以及安全和隐私需求的提高等因素。主要可以概括为以下几点：数据传输和存储需求：智能视频应用需要大量的数据传输和存储，而边缘设备的处理能力有限，无法满足这些需求。因此，需要将数据传输到云端进行存储和处理，并将处理结果传回边缘设备，实现云端和边缘设备之间的数据协同。实时性需求：智能视频应用通常需要实时处理视频数据，对于一些需要及时反馈的应用场景，如智能监控、智能交通等，要求对视频数据进行实时处理和分析。因此，需要边缘设备和云端之间算法优化需求：智能视频处理通常需要复杂的算法支持，而边缘设备的计算能力有限，无法支持较为复杂的算法，因此需要将算法部分放在云端进行处理。同时，为了降低传输延迟和减少网络带宽的消耗，需要对算法进行优化，使其能够在边缘设备上运行，安全性需求：智能视频处理涉及到大量的敏感信息，需要采取一系列的安全措施来保障数据的安全性，如数据加密、身份认证等。同时，需要建立完善的安全管理机制，包括安全审计、漏洞修可扩展性需求：随着智能视频应用的不断发展和普及，需要用户体验需求：智能视频处理的最终目的是为用户提供高质量的服务体验，因此需要关注用户体验的各个方面，包括响应速度、图像清晰度、交互方式等，以满足用户的需求和期望。同时，需要进行用户调研和反馈，不断改进和优化系统的功能和性能，提高用户满意度。成本效益需求：在智能视频处理中，云端和边缘设备的资源使用需要考虑成本效益，如网络带宽、存储、计算资源等，需要根据实际情况进行优化和管理。端边云协同的智能视频系统需具备高效的视频采集和传输、端边智能分析、灵活的存储与检索、安全与隐私保护、可扩展性与兼容性、用户界面与交互、系统稳定性与可靠性等关键功能和性能。通过满足这些需求，智能视频系统能够提供高质量、可靠的监控和分析服务，为用户带来更安全、便捷的视频监控体验。二、方案技术框架云边端协同的智能视频方案技术框架可以采用以下主要技术：数据传输和存储技术：包括数据压缩、加密传输、云端存储、边缘存储等技术，以确保数据的安全传输和存储，并提高数据传输实时性处理技术：包括流媒体传输技术、低延迟编码技术、并行处理技术等，以保证视频数据的实时处理和及时反馈处理结果。智能视频处理算法技术：包括目标检测、行为识别、人脸识云边端协同调度技术：包括任务分配、资源调度、动态负载安全性保障技术：包括身份认证、数据加密、安全审计、漏用户交互界面技术：包括用户界面设计、交互方式设计等技基于以上技术，云边端协同的智能视频方案技术框架可以分为三层：应用层：用户通过界面操作，完成对智能视频处理的需求定云边端协同处理层：通过任务调度和资源分配等机制，将任基础设施层：提供数据传输和存储、实时处理、安全性保障等基础支撑服务，以保证系统的高效稳定运行。在该技术框架下，云端和边缘端协同处理任务，利用分布式计算资源和算法实现视频数据的智能处理和分析，提高了视频处理效率和准确率，并为用户提供了高质量的智能视频处理服务。三、关键技术详解云边端协同的智能视频方案中，涉及到多种关键技术，以下对这些技术进行详细的介绍。（一）数据传输和存储技术数据传输和存储技术是保证云边端协同的智能视频方案稳定和高效运行的关键技术。其中，数据压缩技术可以降低数据传输时的带宽占用和传输延迟，加密传输技术可以保证数据的安全性，云端存储技术可以提高数据存储利用率和容错性，边缘存储技术则可以提高数据访问速度和减轻云端的负担。（二）设备和应用管理设备和应用管理技术是保证端边云协同的智能视频解决方案能够正常运行的基础技术。该技术包括边缘和端设备的统一管控、应用管理和可观测性等关键技术，可以实现对边缘和端设备的有效管理、应用程序的灵活调度和监测，以确保系统的高效运行。下图是设备和应用管理的架构图。通过在传统的云端两层架构之间添加边缘站点这一物理层，使得每个边缘节点由最近的站点进行管理，从而降低云端中心的负载、服务时延，并提高边缘节点的管控数量。图3.1设备和应用管理架构图设备统一管控在端边云协同的智能视频解决方案中，设备统一管控技术起着至关重要的作用，该技术涉及对边缘计算节点和端侧摄像头的管理和监控，包括但不限于设备的激活注册、配置、状态检测、软硬件更新等功能。边缘计算节点管理边缘计算节点主要负责承担边缘计算任务。设备统一管控技术可以通过以下方式对边缘计算节点进行管理：注册激活3.1kubernetesCDNCDN部署在边缘节点中的agent组件，会定期汇报心跳到云端控制中心。从云端控制中心对该节点注册激活，后端会根据心跳信息依据节点的IPISP节点上的边缘agent至此，该边缘节点便成功纳管至该系统里。在中心控制中心将可以管理和操作该边缘节点，包括但不限于在线状态查看、资源监控、应用部署、远程命令执行等。分组管理管理。状态监测节点的在线状态（设备与网络的连接是否正常）、运行状态（如CPU、内存和存储资源的利用率等），而应用状态监测则是对各个应用程序的实时监测，包括但不限于应用的运行状态、错误和异常捕获等。软硬件更新OTA端侧摄像头设备管理端侧摄像头是智能视频解决方案中负责采集图像或视频数据的设备，采集到数据可结合模型算法应用实现视频内容分析和智能识别。GB28181ONVIF的接入，屏蔽底层异构，对端侧摄像头进行统一管理，并提供以下能力：应用管理应用管理是端边云协同的智能视频解决方案中的另一重要组成部分，它涉及到对各种应用程序的管理和部署。每个应用采用kubernetesPod合一算法这几类。此外，还可以将这些应用组成一体机应用进行统一管理。官方应用官方应用是一系列与智能视频解决方案相关的应用，也是本方yaml等元信息组成。在智能视频领域里，这些应用可以是关于视频编解码的应用、也可以是对应场景的目标检测和跟踪算法应用。根据不同的场景和需求，通过云边通道，用户可以将应用下发到具体的边当应用成功部署到边缘节点后，应用的实例状态会上报回中心，其状态的流转图如下图所示：图3.2应用状态流转此外，官方应用可以在边缘节点出厂时便内置进去，以减少应用部署时镜像拉取的时间，从而实现应用秒级别的启动。这些预置的信息同样会记录在中心控制中心里，用户可以通过中心查看预置的应用，并直接启停它们。自定义应用自定义应用则是由用户自定义创建的容器应用，由用户自行管理版本。创建完后可以通过相同的方式下发部署到边缘节点。多合一算法不同场景需求并不相同，比如智慧交通和智慧园区场景里所需要的算法并不相同。为了赋予用户更高的自由度，以满足个性化、场景化需求，本方案设计了多合一算法的功能。该功能可根据不同的场景需求，由用户自行对多个算法进行自由组合。在使用多合一算法前，需要事先在中心定义好单个算子的名称、运行架构、所需的运行资源以及模型文件地址。当部署一个多合一算法时，将会将这些信息整合在一起，通过模板创建实际的部署yaml文件。yamlinitContainerAIyamlinitContainer取。同时，算子内部会挂载一个宿主机的目录，用于存储存储下来的数据。其中，download；datadata为避免旧版本带来的脏数据，每次启动时，都需要清空，并且从download图3.3多合一算子启动流程当initContainer完成数据的初始化工作后，真正的算法框架进程将会读取该路径下数据。完成进程初始化工作，监听端口，建立server一体机套件为了加速标品交付速度，本方案提出了一体机套件的功能，实现对于边缘节点的"一键装机"，标品快速交付，即支持将多款官方应用、官方算法等捆绑到一起，作为一个一体机套件包。从而用户可以一键进行统一部署、统一管理、统一删除。可观测性可观测性是端边云协同的智能视频解决方案中的重要技术之一。它涉及对系统的运行状态和性能进行实时监测和分析，以便及时发其中，底层基于VictoriaMetrics架构，从而实现监测指标收集和数据存储和查询，架构如下图所示：图3.4监控架构图每个边缘节点都会部署一个vm-agent，用于实时收集系统中各个组件（node-exporter等）的监测指标，这些指标包括但不限于：系统资源利用率、应用性能指标、网络状况等。采集到的数据除了会推送到中心vm-storage组件外，还会推送到边缘节点上的vm单机版组件里，以便在边缘控制台上直接查看到当前节点的运行状态。VictoriaMetricAPI特定的监测指标进行实时查询、数据聚合和分析，并结合grafana此外，管理员或用户还可以设置报警规则，当监测指标超出设定的阈值或发生异常时，系统将自动触发报警通知，以便及时采取相应的措施。（三）云边端调度表3.1术语表说明edgelite边缘侧的应用程序，容器运行底座，拥有控制面能力，管理容器的生命周期edge-tunnel云边通道中在边缘侧的应用程序cloud-tunnel云边通道中在中心侧的应用程序cloudlite中心侧的应用程序，负责管理edgelite，代理edgleite到中心k8s的所有请求单机轻量容器引擎K8SK8S上。边缘计算由云中心的延伸逐步演变为云-边-端一体化的基础设施，这个过程也会越发触及更靠近用户侧的边缘环境，这就使得越来越多边缘侧的小型机器或机房、盒子设备、甚至是单片机设备需要作为边缘侧算力节点纳入到边缘计算管理范畴。管理这些边缘设备难点在于克服异构性、设备资源极端限制、边缘网络质量差等主要因素。目前云原K8S生已经被广泛用于云计算领域，完成应用到基础设施的敏捷CI/CD群节点的管理，对于边缘零散设备管理的技术配套仍然没跟上，所以对K8S的边缘计算的轻量化修改适配势在必行。由于边缘计算业务场景充斥着大量的异构、小规格的边缘算力，像各种智能终端、设备，它们对资源的约束是极致的，无法接受额，K8SK8SK8S对已有框架的轻量化改造、容器引擎的轻量化实现，有效提升边缘业务并发启动速度，大幅降低稳态下的内存占用，满足用户的基本需求。与云边集群的普通节点不同，edgelite适用于边缘一体机的使用场景，既满足单机独立运行的需求，又可以快速加入原生K8s集群，按照k8sAPI部署应用等。因此edgelite独立性：单机与中心无任何依赖关系；单机之间的资源serviceCPU200M（空载，不含containerd）。功能的有限性：单机仅满足基本的容器管理需求，包括Pod（包括Pod依赖的ConfigMap资源等）、Service、Node等，资源的访问接口需要兼容原生K8s的API。云原生标准化：单机可以快速加入到原生K8sK8s。针对以上特点，我们edgelite架构整体设计如下图：图3.5edgelite架构整体设计图为了减少进程间的通信，从而降低内存，我们设计了cli模块用来管理所有依赖子模块的集成问题，同时取消数据库存储，直接采storagelist-watchdispatchk8sserver模块，为了能够被标准k8s管理，将云边通道edge-tunneledgelitek8skubelet、kube-proxy、containerd裁剪统一集成到edgeliteallinone。作为AllinOne的组件，EdgeLite旨在集成在边缘部署所需的EdgeLiteEdgeLiteCli详细方案如下：一个可执行文件扮演多个角色同一个可执行文件可以作为不同的进程使用，例如，当文件名containerdcontainerdedgeliteedgelite样一来，只需要一份代码和一个进程，就能包含多个服务。/urfave/cli令管理的命令行工具，“/docker/docker/pkg/reexec”包作为进程管理工具。当二进制以指定名称命名时，则对应启动相应名称的进程。例如，edgelite的代码编译出来的二进制包含了containerd、kubectl、crictl、ctr进程。如果编译的二进制命名为containerdcontainerdEdgeLiteServer模块EdgeLiteServerk8sk8sk8s相关的kubectl、client-go可以正常调用ServerServer模块的处理流程如下：ServerHTTP）。Server对接收到请求，对请求进行解析，解析出请求的k8s资源类型和操作类型等信息（例如：Pod、Node等资源类型）。根据请求的资源类型和操作类型（CREATE、UPDATE、PATCH等操作类型），进入相应的接口服务进行处理。Storage/存储。对于更新事件的操作类型（CREATE、UPDATE、PATCH、DELETE）PushDispatcherEdgelite-Storage模块设计edgeliteserver完成资源对象的存储。为了确保写一致性，该模块维护ResourceVersion，并负责生成eventdispatcher。本地文件存储模块相较于单纯的读写本地文件，主要增加了以下两点能力：解除文件存储和业务逻辑之间的耦合，通过Transformserver录地址+文件名的方式来存放和索引资源。如果其他模块（如promlite）需要向本地存储迁移，可在初始化时自定义存储组织逻辑。增加了读取缓存，可以减少访问相同资源的内存占用和速度。写操作都先在临时目录下进行，没有错误后，再拷贝到正常的路径完成写入，以保证写操作的原子性。写操作的主要逻辑如下：ResourceVersion。拼接路径并创建objType/namespace/。创建文件并写入objType/namespace/name。eventdispatcher。对于create如果资源不存在，初始化资源的ResourceVersion对于update操作：更新资源的ResourceVersionEdgelite-Dispatch模块设计EdgeLiteK8sEdgeLite进程中，因此组件之间的资源同步可以通过进程内的消息通信来完HTTPList/Watch在EdgeLite中，需要进行资源同步的场景主要是：当存储的K8s需求，即只有一对多的消息单向传递，而没有多对多或双向的消息EdgeLite/dispatcher模块采用消息订阅发布的模式，每个客户端作为消息dispatcherwatcherwatcher提供的消息channel，获storagewatcher。Edgelite-PodControlleredgelite删除了k3sserverDeployment、DaemonSet高阶应用部署。因此，单机版不再具备保证指定实例个数的Pod配置的使用上限，造成Pod状态，被驱逐的Pod也无法自动恢复重启，从而造成业务异常。因此，单机版需要在保证轻量化的同时，也需要提供自动恢复被驱逐的Pod为了解决这个问题，我们自定义了一个Controller，仅针对被Pod，controller未纳管时）启用。PodkubeletPod来缓解和释放机PodPodStatusFailed状态，此外，当机器可用资源小于临界值时，kubeletnodestatusNodeCondition并为node打上不可调度的污点，使得新增部署的容器无法运行，基于以上的特点，我们可以设置一个简单的controller，仅对被驱逐的Pod3.6Edgelite-PodController云边通道在边缘计算场景下，许多边缘节点都位于私有网络中。由于节IPHTTP、RTSPFTP等服务。这导致常用的运维操作如日志查询、远程命令执行、指标数据查询等无法实现。因此，我们需要开辟一条云端与边缘侧的通提供一个能够跨越局域网屏障，实现稳定可靠的数据传输，支持多种协议代理的云边协同通道。通过这种方式，我们可以构建出云-边-端一体化的请求通道解决方案，从而将中心云、边缘云、私有现场IDC和边缘盒子设备等整合成一个资源混合云，实现容器化编排和资源统一调度。edge-tunnelcloud-tunnel（1）如何在云边传递云端请求；（2）如何拦截云端请求；（3）边缘如何处理云端请求；（4）使用websocket构建云边通道，传递云端请求WebSocketEdge-Tunnel作为服务端，通过它们之间建立一条长连接来传Cloud-TunnelEdge-ServerEdge-TunnelEdge-TunnelTunnel-ClientCloud-TunnelEdge-Tunnel举例http代理的整体方案结构如下：cloud-tunnelhttp责将http客户端的请求代理转发到边缘进行处理。它包括proxyservertunnelserverProxyServerProxyServerhttphttphttptunnelmessageedge-tunnelwebsockethttp理。TunnelServerTunnelServerwebsocketedge-tunnelwebsocketedge-tunnelProxyServerDNStunnel-dnsDNStunnel-dnsconfigmapDNStunnel-dns”这个configmap中，每个边缘设备和cloud-tunnel的映射关系都以“deviceName:cloud-tunnelipHTTPDNS解析，将请求发送给与目标边缘设备建立有云边通道的cloud-tunnel。同时，如果HTTP客户端无法直接使用tunnel-dnscloud-tunnelDNScloud-tunnel。apiVersion:v1kind:ConfigMapmetadata:name:http-proxynamespace:kube-systemdata:"host"device1\n" //DNSedge-tunnel处理云端请求edge-tunneltunnelclienthttpclienttunnelclienttunnelclient是云边通道websocket连接的客户端。edge-tunnelcloud-tunnelwebsocketcloud-tunneltunnelmessageclienthttpclienthttpclientedge-tunnelhttpcloud-tunnelhttpedge-tunnelhttpclienthttpclientURL、Bodyhttp标httphttphttpclient道将其吐回给cloud-tunnelhttpcloud-tunnel每个边缘节点都会运行一个名为edge-tunnel的模块，而这里的高可用性主要指cloud-tunnelcloud-tunnelCloudTunnel的configmap，cloud-tunnelconfigmapdata:node1:8999node2:8999cloud-tunnelconfigmapcloud-tunnelconfigmap就可以准确路由到对应管理的cloud-tunnel。云边协同调度我们希望不仅能够在边缘侧直接访问轻量化单机平台，而且能K8sAPIcloud-lite在边缘离线的场景下，边缘控制面可以作为一个独立的系统，直接调度本地的资源，实现本地业务的运行。与此同时，当边缘设备需要连接到中心时，可以通过中心统一管理边缘设备，实现完整全局的资源统一调度。这种模式可以保证边缘设备在离线的情况下仍然能够独立运行，并且当需要连接到中心时，可以实现资源的统一调度和管理。这种模式可以适用于一些需要实时响应的场景，例如智能制造、智能交通等。在智能制造中，边缘设备可以实时采集数据，并进行本地的处理和分析，从而实现对生产过程的实时监控和调整。在智能交通中，边缘设备可以实时感知交通流量和路况，并做出相应的调度和指挥，从而实现交通的畅通和安全。因此，边缘控制面结合中心统一管理的方式，可以有效地实现边缘设备资源的调度和管理，并且可以适用于各种不同的场景。CloudLitesynccontroller在Cloudlite架构中，为了实现对边缘单机的统一纳管和K8sAPICloudlite听中心资源的变化，并通过云边通道主动下边缘发起更新。CloudliteK8scontroller，这些controller主要负责以下两个任务：（1）从边缘单机拉取资源K8s（2）K8sCloudlite道。该通道能够实时感知中心资源的变化，并将这些变化的信息主动下发到边缘单机中，从而实现对边缘资源的实时更新和同步。Cloudlite和K8sAPICloudliteCloudliteKubernetescloudlite中，我们需要关注Pod、Node、Service、Endpoint、ConfigMap、Secret六control。EdgeLitecloud-tunnelcloud-tunnelk8sconfigmapSynccontrollerConfigMapInformer，监听configmapnode-record发生变更时，通过读取nodemanager动该节点的同步任务；当节点被从中心删除时，停止并删除同步任务。syncer是执行节点资源同步任务的模块。当启动之后，会周期性地执行同步任务，默认周期是5min，可以参数配置。同步任务主要包括两个步骤：向边缘节点下发资源，并查询全量的资源详情：EdgeLitehttpsyncertunnel-dns点标识node-id，通过云边通道发起http向中心K8ssyncerSynccontrollerpodnodeconfigmap、secretserviceendpointcontroller6controllerInformerkey值（资源namespace+name）添加到工作队列WorkQueue中。syncResourceHandler作为WorkQueue行工作队列中的任务。syncResourceHandler的主要工作过程如下：查询中心和边缘是否存在资源。如果两者都不存在，则忽略该任务。如果中心存在资源，而边缘不存在，则在边缘创建该资如果中心不存在资源，而边缘存在，则在边缘删除该资源。如果中心和边缘都存在该资源，则需要以中心版本为主，如果以上步骤在边缘执行失败，则需要将任务重新加入这里对于Pod和Node的同步需要一些特殊处理：对于边缘同步到中心的Pod，由于名称都带上了nodeIDPod非强制删除时，Pod会设置DeleteTimeStamp，PodControllerDeleteTimeStampPodPod个强制删除PodNodeControllerNodeNodeConfigMaptunnel-dns的node向EdgeLite的请求是否需要重试，取决于请求通过云边200。对于集群级别的资源，只处理中心部署的资源：中心没有、边缘有，（检查资源是否有使用），若没有则删除；EdgeliteEdgelite心sync-controller（约定只同步podnode），serviceconfigmapnamespacesSecrets，边缘侧同步规则：中心有，边缘没有，在边缘创建资源（添加中心创建注解）。（。所有中心创建资源携带（注解kubernetes.io/owner.by.cloud=true）通过同步创建的资源均在写入前添加该注解。节点分组K8snode平面，但由于资源异构、机器的运营商、云供应商不同，逻辑上自deployment案通过给node打标签、划分逻辑组，并使用nodeSelector或Affinity限定部署在逻辑组中。然而，由于每个组都需要独立维护一个deployment，因此需要大量的YAMLdeployment，管理困难且维护成本增加。原生KubernetesServiceService流量很可能会出现访问不可达或者访问效率低下的问题。有些服务我们希望每个区域中都运DaemonSet方式Pod副本。服务通过localhost以节点池的视角对不同边缘区域下的主机进行统一管理和运维，可以实现批量管理节点组内节点的label、annotations和taints。通过使用新的单元化部署模型，将用户的工作负载部署在不同的节点池中，业务的实例数和版本都可以按照节点池的维度进行统一管理。同时，服务闭环也可以在节点池中实现流转。CloudLite和Edgelite同步网络拓扑信息，支持节点分组网络互通和流量拓扑节点分组K8sCRDNodepool随着Kubernetes（k8s）（CustomResourceDefinition，CRD）k8sk8s场景。而在许多场景中，需要对节点进行分组管理，这就用到了自定义资源节点池Nodepool。Nodepool是一种用于管理节点组的新颖方法，它可以让用户根据特定的需求将节点分组，从而更好地利用和管理节点资源。在Nodepool中，通过指定标签来实现节点的分组。用户可以为自己定义的节点池指定特定的标签，从而将具有相似属性的节点归为一类。这样的做法有助于更好地进行节点的管理、调度和扩展。NodepoolController通过Informer机制监听Node和Nodepool资源。NodepoolControllerk8sNodeNodepool类信息实时同步到NodeInformerk8sWatchAPINodepoolControllerInformerNode和NodepoolNodepoolHandlerNodeNodepoolHandlerNodepoolController它负责帮助用户维护节点标签，并保证对应节点池的三类信息实时Node，NodepoolHandlerNodepool定义和节点的标签，将节点添加或从对应的节点池中移除。此外，当节点池中的节点数量超过或不足预设阈值时，NodepoolHandler还会自动扩展或缩减节点池的大小。节点分组网络互通Edgelitecloudlitek8sk8s前由于每个单机是作为一个独立的节点，每个节点之间的资源完全隔离，因此单机节点之间的容器网络也无法互通。为了对齐普通节子网分配：在目前的方案中，每个单机初始运行时使用参数“--cluster-cidrflannelPodIPPodIP相同的。因此，一个想法是每个单机节点可以当作独立的集群来看待，不考虑单机的子网分配问题，而是考虑如何实现集群之间的容器网络互通。但是，目前业界实现的集群之间容器网络互通的方案因此，要实现不同节点之间的容器网络互通，就需要确保不同节点上的PodIP节点分配一个不冲突的子网网段。分配子网的策略可以自定义，也可以使用k8s要实现节点之间容器网络互通，基于flannel方案除了要求podIPnodeflannelnodeIPnode给单机上的flannel容器网络的互通。这个同步过程由cloud-litesynccontrollercontrolleredgeliteedgelitenode流量分组每个EdgeLiteServicekube-proxy（目前集成在EdgeLite）kube-proxyServiceServiceiptables/ipvs制kube-proxyEndpointsEdgeLite点对服务实例的访问。我们可以采用在云端Cloudlite组件中对EndpointsEndpointsServiceControllerEndpoints过滤流程：Endpoints（ADD/UPDATE/DELETE）；通过Endpoints=>Service=>DeployGroup=>NodePools；遍历当前CloudliteEdgeLite判断当前EdgeLiteNodePoolEndpointsNodePoolPod（Endpoints的subsets后端列表）Endpoints。CloudliteEndpointsEdgeLiteServiceEndpointsEndpoints=>ServiceDeployGroupNodePoolsEdgeLiteNodePoolEndpointsPod，最后调用EdgeLiteEndpoints。NodePoolEndpoints（四）算法维度智能视频服务架构智能视频处理涉及视频编解码及算法识别，这部分工作对算力的有很高的要求。如果将这部分工作完全放在云端进行处理，那么云端服务将除了需要提供极大的算力支持，还需要考虑网络传输延迟及带宽费用等高昂的成本。为此，我们充分利用了边缘计算的能力，将任务分解并下放到边缘，最终实现在边缘节点上面的设计了一套智能视频推理服务。如上图所示，这套智能视频推理服务主要包括以下4个模块：视频处理模块：提供保存、抽帧、渲染合成等常见的视算法推理模块：提供目标检测、跟踪、人脸识别等算法推理能力事件管理模块：用于接收来自算法模块的事件信息，并WebWeb使用场景如下：用户在Web抽帧出来的图片发给算法模块进行识别。算法模块识别之后，再把图片及识别结果发给事件管理模块。Web理结果。算法推理模块EdgeInfer了全面的工具集，支持用户自定义模型和算法，以适应不同的推理应用场景。其主要特点包括：实时性：使用了高性能的调度框架，可以快速同步地返回推理结果。可配置性：服务内部支持自定义流水线，允许用户根据自己的需求，自行配置需要的处理流程，包括：图像预处理、推理、事件发送等逻辑。进一步地，EdgeInfer支持结合多个算法的推理结果，实现更复杂的推理能力。这样可以帮助用跨平台性：本服务支持多种不同的硬件平台，包括：NvidiaXavier/Orin、算能、瑞芯微、昆仑芯等，以便用户能够方便地将其部署到不同的应用场景中。EdgeInferhttpbaidu-rpc行远程算法调用,也提供特定格式的sdk开发。EdgeInfer内部主要的处理流程如下：HTTP、RPCjpeg,pngRGB图片预处理：将原始图片并转化成推理模型需要的格式。TensorRTRKNN算法后处理：根据用户需求，补全模型推理无法完成的响应请求：将推理结果通过HTTP、RPC上面只是最简单的推理流程。在实际业务中，我们会遇到更加复杂的推理逻辑：例如：在一张图片内指定一个入侵区域，在这区域内如果发现有车辆或行人，就会判定为入侵并触发告警。车辆检测和行人检测是互相独立运行的，如果进行并发处理，那可以减少推理速度。例如：识别图片里面所有员工。人脸特征提取模型，要求先用其他模型提取出人脸位置，再取出对应位置的人脸作为输入提取特征。这时就必须将多个模型进行串行推理，，EdgeInfer这套框架主要包括以下结构：将模型推理、前后处理等逻辑拆解成互相独立的处理器。使用有向图将处理器连接在一起，构建出一套复杂的处理流程。使用流水线调度策略：基于消息队列，对数据有序管理，EdgeInfer处理器插件化能力作为EdgeInfer最重要的器官，处理器用于处理不同的工作，类型一个函数，对输入数据进行处理，然后输出结果。其基本包括以下类型：jpeg/pngRGB处理。逻辑封装：根据模型推理结果，实现用户需要的业务功能。常用于推理后处理。处理器需要处理复杂的功能，因此其需要有一个固定且较为宽松的输入和输出格式。如下面所示：每个任务都是一个字典型的结构，键是处理器的名字，值是处理器的输出结果。每个处理器都可以获取得到当前任务的全部信息，在处理完之后，将自己的结果写入到任务中。在保证了统一的输入输出格式之后，还可以进一步地封装成动态插件。处理器插件化可以带来如下好处：处理器插件可以随意替换。根据不同的硬件环境，项目需求，每个处理器都可能会有多种实现方式，此时只要动态插件可以扩展功能，而不需要修改主干代码。只要把逻辑封装成处理器插件，在接入到EdgeInfer之后，在编译时不需要考虑其他处理器。例如：编译图片解码。流水线调度能力在提出处理器概念之后，接下来，就是怎么去执行他们。我们可以编写一个函数F，在里面按顺序调用三个处理器，对于大多数开发者来说都是容易的事。但处理器有时受到底层实现的影响，在处理任务时可能会有一些约束，例如：例如中间有一些处理器只能同时处理一个任务，那大多数人都会直接在函数F里面加上互斥锁。这时就变成如下的串行调度模式。这种模式处理逻辑简单，但因为等待解锁会有任务执行时间长的问题，容易堆积任务，严重时甚至会打满内存而崩溃。更好的方CPUEdgeInfer因为所有处理器都是互相解耦的，所以允许不同的处理器进行并行处理，极大地缩短串行处理时间。同时，考虑到有些处理器无法同时处理多个任务，所以需要在每一个处理器前面都加一个消息队列，如下图：不论来了多少个任务，都会按顺序放入队列中，再慢慢被处理器进行消费。当如果消费速度小于添加速度时，会导致任务队列被打满。为避免这种情况，我们还可以对任务队列加一些处理策略，例如：按先入先出的策略终止未完成任务，或者增加处理器提高消费速度。流水线处理技术最终带来了以下优点：有向图表示能力在实际业务中，我们会遇到复杂的处理逻辑，要求处理好：串行和并行需求，同步和异步限制。要写出高效、简洁的代码，非常考验开发者。此外，开发者可能为了追求高效率，代码逻辑过于特殊化，可复用性差，无法适用于其他项目。EdgeInfer如上图所示，基于有向图，我们可以非常直观地看出员工着装检测算法的处理逻辑，这远比一堆代码更容易理解。接下来，我们就需要使用图式计算引擎来执行任务。这部分需要引入以下组件：组件名作用Source数据源：按一定规律产生任务。比如：从Http协议接口接收到请求。Graph流程图：将任务放到需要执行的处理器中，或者进行销毁。Queue缓存队列：每个处理器的任务缓存队列。Processor处理器：负责处理任务。比如：图片格式转换、推理、事件发送这些组件的交互逻辑如下图：数据源(Source)，实时地从HttpRtspGraph有向图(Graph)会根据当前任务的状态，选择对应的处理器(ProcessorQueue)。处理器处理完任务后，再次交给有向图(Graph)决定去向。有向图(Graph)如果判断当前任务已经执行完时，会触发由上面流程可看出，有向图处理带来了以下优点：弹性调度系统除了直接在计算节点上部署算法外，端边云协同的智能视频解决方案还提供应用弹性调度能力：根据实际的QPS使用情况和负载情况动态调整应用的部署，在算力资源紧张的情况下，通过减少低优应用的副本数来腾出可用资源给高优应用来使用，该能力同样可使用于分组管理模式下的计算节点。系统架构图3.7弹性调度系统架构如上图所示，弹性调度系统主要由云边数据通道、弹性计算调度层、统一网关等几个核心模块组成：息汇聚。以下功能：HPAGPUCRD（AIDeploymentenvoy+xdsqps组件会为xds组件提供每个应用在当前节点分组下实际Endpointxdsenvoy系统实现节点组粒度调度与整个集群调度的不同之处在于，不同节点组的运行情况是完全隔离的，同时应用的实际访问情况也会受到一些外在因素的影响，比如地域，这些将会导致各个应用在不同节点池里的实际访问情况各不相同。有些应用在某节点池甚至可能完全没有访问流量，或是被其他更高优的应用占去所需部署资源而导致完全没有实例在运行。AIDeploymentCRD本方案定义了新的CRD（AIDeployment）CRDDeploymentspecHPAQPSAIDeployment控制器，主AIDeployment用所需的DeploymentServiceHPA此外，本方案还定义了关于节点组的CRD资源（NodePool）。该资源记录了节点组及其关联的一系列的边缘节点间的关系。而节点部署组则是由多个节点组组成。AIDeployment控制器会监听NodePoolAIDeploymentAIDeployment成实际要部署yamlyamlDeploymentHPAserviceDeployment。不管有多少节点组，Service也只会部署一份。service-topologyendpointxDSservice-topology组件后，网关便只会获取到该节点组对应的endpoint数据，从而保证应用流量只会在同一个节点组里流入流出。弹性调度由于该系统调度部署的应用，需要统一使用网关代理访问。在hostnamespace：-H"hostnamespace1QPS，以便更新调度。应用的实际QPS指标数据是通过通过网关的metricsDeploymentservice，HPAselector网关数据拉取时对数据来源加上节点池标记，以便区分应用在各节QPSDeploymentHPAQPSAQPS10QPS100+，则将会调整应用A10，而当实际QPS降低后，副本数也会缩回到相应的数值。这里使用的kubernetesceil[*(当前指标/的期望副本数的变量需要大于10资源监控资源监控模块会定时监控智能应用在各个节点池部署的Deployment的运行情况，并将其告知给流程调度模块，最后由流程调度模块统一更新智能应用的对应的运行状态status.state，以及status.nodePoolStatusesDeployment流程调度在应用运行过程中，随着QPS的不断提高，应用实例也会跟着增加，这可能会导致节点池资源不足，部分实例无法正常启动。此时FailedScheduling，并将该事件告知流程调度模块。流程调度模块收到通知后，将会启动低优任务抢占的工作：高级优先级任务发现算力不足可以抢占低级优先级和更低的高级优先级。低级优先级不能抢占其他任务。此Deployment优应用QPS开始下降，实例数也跟着减少后，节点组可用资源又变多一旦节点组的可用资源充足，流程调度模块将会按优先级从大到小的顺序开始恢复被抢占的应用。流程调度模块的具体实现如下图所示：图3.8流程调度工作流程组件间的工作流程如下图所示：图3.9工作流程图流程调度模块监听AIDeploymentCRD，转化数据结构并NodePool源流程调度模块根据优先级、资源情况控制该应用在节点池上是否需要启停动态启停模块则根据流程调度的信号进行智能应用的启动和关闭应用的实际副本数受QPSHPA应用副本数的变化导致资源使用的变化将被资源监控模流程调度模块接收到资源变化信号，重新判断应用是否需要启停（五）视频维度端侧数据采集技术端侧数据采集技术是指采集算法推理所需的各种数据，以及将算法的输出结果进行收集和存储的技术。该技术包括图片、音视频以及结构化数据、元数据等各种形式数据文件的搜集整理，分类归集，存储传输，以及可扩展的多维度数据汇聚分析等功能。基于以上功能，数据采集可以分为三个功能模块：图片和音视频数据原始数据采集，作为算法输入数据和事件存证数据，支持主流图片编码格式和音视频格式；通过对多种形式数据的搜集保存，为算法推理、结果存证、数据展示分析等提供基础能力支撑，同时通数据云边端归集可以支持算法迭代和升级，不断优化和改进算法，提高算法的准确性和效率，端侧推理任务平台端侧推理任务平台是指工作在端侧硬件上，主要功能为绑定视频与算法，设定任务规则，生成算法任务的核心平台能力。该平台APIUI主要的框架如图：该平台能力主要包括以下几个模块：ONVIF边侧端数据接入、AI边侧端数据接入、AIAI分析，并将算法结果存储分析存证的核心关键技术，其具有易运维系统结构如图：其中：数据形式包含图片、音视频数据和实时流，结构化数据、时AI分析能力是指封装算子原子能力如数据预处理、模型训练AIAIAI能力动态负载均衡扩缩容等，通过端边侧联合的AI分析能力，可以实现轻量分析放端侧，重量分析放云边端，对海量数（六）安全相关容器安全基于云原生k8s应用的边缘计算容器安全方案：在边缘计算场景中，容器安全是一个非常重要的问题。由于边缘计算的环境相对较为复杂，因此需要采取一些特殊的措施来确保容器的安全性。以下是基于云原生k8s应用的边缘计算容器安全方案的几个方面：使用可靠的镜像仓库：在边缘计算环境中，由于网络带宽和延迟等问题，重新下载镜像仓库中的所有镜像可能非常限制容器的权限：容器的权限应该被限制在最低权限级使用自签名证书：在边缘计算环境中，建议使用自签名证书来验证容器的身份和完整性。我们通过在容器中安装自部署容器网络：容器网络是一种将容器与外部网络隔离开的技术。在边缘计算环境中，建议使用容器网络来限制容监控和日志记录：监控和日志记录是确保容器安全性的PrometheusEFK强化准入和退出机制：在边缘计算环境中，应该建立严格的准入和退出机制，确保容器在进入和退出环境时都经过Kubernetes的admissioncontroller利用容器安全扫描工具：使用容器安全扫描工具可以帮综上所述，基于云原生k8s应用的边缘计算容器安全方案应该从多个方面来确保容器的安全性和可用性，包括使用可靠的镜像仓库、限制容器的权限、使用自签名证书、部署容器网络、监控和日志记录、强化准入和退出机制、利用容器安全扫描工具、实施容器安全培训和意识、定期审计和更新以及建立应急响应机制等方面。盒子鉴权在当今的数字化时代，鉴权加密方案是保护边端固件和应用的重要手段之一。本文会部署一套边缘鉴权服务器实现边缘节点的鉴权和密钥托管能力，可用于确保设备运行的软件组件是合法的和未被篡改的。在该鉴权加密方案中，中心会为可信的边缘盒子进行预授权操作。当边缘设备需要部署应用时，中心后台服务重新更新预授权信息，并下发命令使边缘鉴权服务器重新获取鉴权信息，包含包括授权应用，授权有效期，授权应用所绑定的密钥等信息。边缘部署的应用组件集成了鉴权SDK，会在启动时向边缘鉴权服务器发送授权应用名申请验证，并由该服务器验证器授权的合法性和有效性。仅当验证通过后，应用组件才能正常运行。组件与该服务器之间的通信采用了强大的加密算法和非对称密钥技术，确保了授权信息的安全性和完整性，防止信息被篡改或盗用。同时鉴权服务器还提供以下能力：提供的接口包括获取授权信息、验证授权信息、设置环提供日志记录和审计功能，可以记录边缘设备的操作和上述鉴权加密方案为边缘设备的软件组件提供了安全、可靠、高效的鉴权认证和管理功能，保障了设备运行的合法性和安全性。mtlsMTLSMTLS本方案采用基于FUSE边缘的每个证书都会使用密钥进行加密，加密后的文件会存放在边缘主机的指定的一个加密数据目录里。同时，这些密钥也会托管在3.6.2所描述的鉴权服务器里，并关联指定的一些业务应用，限制业务程序使用。当边缘主机安装的解密文件系统启动后，会将上述加密数据目IO都会转发到解密文件系统里，由该系统进行解析。在解密文件系统打开文件请求前，会先向鉴权服务器验证业务程序是否可信，以及对于可信进程来说，对解密文件系统的文件的读操作，读取的是明文，而对于非可信的进程，读取的则是密文。基于该解密文件系统，可以有效的在Linux系统中对文件进行加密和解密，并通过验证进程和索要密钥等方式来保护文件的安全性，从而为云边通讯提供了安全性保障。（七）硬件平台支持技术硬件平台支持技术是保证云边端协同的智能视频方案能够高效CPU、GPU、FPGA化技术，可以提高计算资源的利用效率和处理能力。同时，还包括硬件设备的稳定性、可靠性等技术，以确保整个系统的稳定性和可靠性。云边协同硬件服务器介绍随着“云-边-端”架构的快速发展，算力需要下沉到边缘侧来满足边缘对日益增长的算力需求，特别是对实时数据的处理。同时，边缘侧算力系统需要和云算力系统保持协同工作，从而可以实现各尽管云和边缘侧对算力的需求相同，但是由于各自所处环境也不相同。云一般采用大型数据中心来实现，处理的是巨型同构数据，因此云服务器的架构大体相同，数量众多，但是种类较少，可以快速批量生产。边缘侧的应用场景五花八门，少量多样，且所处环境系统架构针对云与边各自不同的特点，硬件模块化设计是一种很好地解决方案。工业富联基于《ODCC-2021-04003-边缘计算小型化边缘服务器系统参考架构及技术规范》规范要求进行设计，采用深度模块IOPCB220mmx200mm3.10图3.10模块化计算架构示意图以计算模块为核心，根据不同的应用场景，可以快速满足从数据中心到边缘的模块复用，如图3.11所示。图3.11模块化服务器架构:满足从数据中心到边缘的模块复用高性能室内云边服务器针对室内边缘视频技术，工业富联基于模块化服务器架构概念，2U481.6mmx450mmx87mm（WxLxH），采用IntelCPU，最高可支持TDP250W，88DDR5DIMMI/OIO80LPCIeGen5BMC4FHFLPCIeGPGPU4NVMeSSD，3.12图3.12室内高性能云边服务器实物图WIFI4GMEC3.13图3.13支持MEC高性能室内云边服务器爆炸图高性能存储云边服务器视频流数据往往需要实时存储。工业富联通过模块复用，基于Intel2U481.6mmx450mmx87mm（WxLxH），I/OIOCPU1S1S+1SCPUTDP225W1616DDR5DIMM。支持可插拔BMC管理模组，轻松实现灵活复用。系统支持2个LPPCIe扩展卡，可以插多路视频卡和网卡，快速进行视频数据传输与处12NVMe用4NVMe模块实现，可根据具体的应用场景按需安装相应的存储模块3.14图3.14高性能存储云边服务器实物图高性能存储云边服务器爆炸图如图3.15所示。图3.15高性能存储云边服务器爆炸图室外高性能云边服务器边缘视频技术除了在室内场景被应用之外，在室外场景也被广泛使用，比如智能交通、智慧灯杆、智能驾驶等。相比于室内场景，室外场景更加恶劣，包括宽温高湿、粉尘、盐雾等各种情形都有可能发生。工业富联针对室外边缘场景的特点，采用模块复用的概念，基于Intel第四代至强可扩展处理器设计相应的高性能室外云边服务器，采用外机箱加内机箱的模式，实现算力提升的同时，满足IP65770mmx530mmx190mm(WxLxH),360mmx450mmx87mm(WxLxH3.16图3.16室外高性能云边服务器实物图（内机箱（左）、外机箱（右））I/OIOCPUTDP165W，88DDR5DIMM1个LPPCIe支持T4GPGPU1OCP3.0输，支持8口RJ端口+2x2光口，可以接收多路视频信号。支持5G/WIFIGPSMEC3.17图3.17室外高性能云边服务器内机箱爆炸图IP65PDU3.18图3.18室外高性能云边服务器外机箱爆炸图浸没式单相液冷边缘服务器当边缘算力需求进一步提升时，或者在特别恶劣的环境，采用风冷边缘服务器将不再受欢迎。一是因为风扇属于易损元件，二是噪声问题，三是可维护性等问题。因此，采用浸没式单相液冷边缘服务器可以有效解决此问题。浸没式液冷边缘服务器系统采用自然对流为主，水冷散热为辅的方式进行散热，不需要额外配置庞大的冷却塔或干冷机进行散热，IP65能力、更低的维护需求、提升能效。采用环保的介电液体减少对环境的污染，满足多元化系统部署的场景。针对高功耗元件，如CPU3.19图3.19浸没式单相液冷边缘服务器实物图（外机箱（右）、内机箱（左））1000W的散1218.3mmx730mmx390mm，481.6mmx450mmx870mm。在内机箱内采用模块复用的概念，基于Intel第四代至强可扩展处理器，1CPU，TDP165W，最大支持两张A100GPGPU88DDR5DIMM，采用独立的BMC4SATASSD。内机箱所承载的边缘服务器系统放置在密闭的外机箱腔体内，通过对流的方式将组件的热量传递至液体，液体再将其导到腔体表面的鳍片进行系统散热，如图3.20所示。图3.20浸没式单相液冷边缘服务器散热原理示意图为了更有效地增加系统内对流，提升系统与环境间的热传能力，在系统内部将高功率或低温度规范的组件放置在底部，低功率或高温度规范的组件放置在顶部来进行布局。图3.21优化摆位实现最佳散热效果示意图AI2UCDU3KW1U2U21”和“193.22图3.222U边缘液冷系统实物外观图2U集成了液冷机柜、冷却分配单元(CDU)和监控系统。液冷机柜由不锈钢制成，提供防锈和防腐蚀保护。机柜的翻盖顶盖可以密封以IP65CDUCDU泵从水箱顶部抽吸进入板式换热器与冷水机、干冷器等冷却系统进行热交换“2U2154VPSU2U2N11S+1SCPU88DDR51x4PCIex162FHFL250WGPGPU4FHFLAIBMC程轻松实现对节点的管理。通过模块化的灵活布局，实现最佳的基于热设计的摆位。监控系统提供两种操作模式，通过传感器监控液冷机柜和CDU3.23图3.232U高性能高密度浸没式单相液冷服务器实物图综上所述，云边端协同的智能视频方案中，涉及到多种关键技术，这些技术相互协作，共同保障系统的高效稳定运行和智能视频处理能力。基于IntelTDX在计算中，数据以三种状态存在：传输中、静止和使用中。通过网络的数据是“传输中”的，存储中的数据是“静止的”，正在处理的数据是“正在使用的”。在我们不断存储、消费和共享敏感数据（从信用卡数据到医疗记录，从防火墙配置到我们的地理位置数据）的世界中，保护所有状态下的敏感数据比以往任何时候都更加重要。加密现在通常用于提供数据机密性（阻止未经授权的查看）和数据完整性（防止或检测未经授权的更改）。虽然现在普遍部署理边界安全在抵御攻击方面的能力越来越有限。虽然以前的保护措施（保护传输中和静态数据）仍然是重要组成部分，但它们已不足以用于保护使用中的数据。机密计算通过在基于硬件、经过验证的可信执行环境中执行计算来保护使用中的数据。这些安全且隔离的环境可防止在使用应用程序和数据时对其进行未经授权的访问或修改，从而提高管理敏感和受监管数据的组织的安全级别。图3.24机密计算保护使用中的数据 可信执行环境（TEE）通常定义为提供一定级别的数据完整性、数据机密性和代码完整性保证的环境。基于硬件的TEE使用硬件支持的技术为在该环境中执行代码和保护数据提供增强的安全保证。在机密计算的上下文中，未经授权的实体可能包括主机上的其他应用程序、主机操作系统和虚拟机管理程序、系统管理员、服务提供商和基础设施所有者——或任何其他可以物理访问硬件的人。TEE中使用的数据TEE之外的任何实体处理数据时TEE替换或修改。总之，这些属性不仅保证了数据的机密性，而且还保证了所执行的计算实际上是正确的计算，从而使人们也可以信任计TEE英特尔信任域扩展（英特尔®TDX）（®TDX）种体系结构技术，用于部署硬件隔离的虚拟机（VM）（TD）。英特尔TDX旨在将TD虚拟机与主机平台上的虚拟机管理器（VMM）、虚拟机管理程序和其他非TD软件隔离开来。英特尔TDX可用于增强机密计算，帮助保护TD免受各种软件攻击，还有助于减少TD可信计算基础（TCB）。英特尔TDX旨在增强平台用户对数据安全和IP保护的控制。英特尔TDX还可以增强云服务提供商（CSP）提供托管云服务的能力，而不会将租户数据暴露给对手。英特尔®TDXIntelVMXISA)扩展、Intel®TME-MK)技术和CPU内存和CPU状态的机密性和完整性，有助于保护敏感的IP和工作负载数据免受大多数基于软件的攻击和许多基于硬件的攻击。有一个工具，支持从可信计算基础（TCB）中排除云平台的固件、软件、设备和操作员。工作负载可以使用此工具促进对CPU指令、安全性、调试和其他技术的更安全访问。工作负载现在可以具有此功能，而与用于部署工作负载的云基础结构无关。远程证明使依赖方（工作负载的所有者或工作负载提供的服务的用户）能够在提供工作负载数据之前确定工作负载正在TD内支持英特尔TDX的平台上运行。远程证明旨在允许服务的所有者和消费者以数字方式确定他们所依赖的TCB版本，以帮助保护他们的数据。为了帮助执行TD的安全策略，引入了一种称为安全仲裁模式(SEAM)的新CPU模式来托管英特尔提供的、经过数字签名但未加密的安全服务模块。Intel-TDX模块托管在由SEAM范围寄存器(SEAMRR)标识的保留内存空间中。在这种设计下，CPU只允许在SEAM内存范围内执行的软件访问SEAM内存范围，所有其他软件访问和从设备到该内存范围的直接内存访问(DMA)都将中止。SEAM内存在XTS模式下使用AES提供加密机密保护，带有一个临时的128位内存加密密钥，并且可以在两种可用模式中的一种模式下运行以实现内存完整性保护（以启用各种内存配置）。内存完整性可以通过（默认的）密码完整性保护方案或逻辑完整性保护方案来强制执行。加密完整性方案使用基于SHA-3的消息身份验证代码(MAC)（28位），有助于防止主机/系统软件访问以及检测来自软件和一些硬件的状态篡改的攻击。逻辑完整性保护方案旨在仅防止主机/系统软件访问。图3.25英特尔®TDX架构TDX®64VMX理TDIntel-TDX模块旨在执行VM进入SEAM-VMX，VMRESUMEVMLAUNCHVMXTDIntel-TDX模块有助于确保TD的执行控制活动不允许VMM或其他不受信任的实体拦截TD对TD分配的资源的访问，如控制寄存器、模型特定寄存器(MSR)、调试寄存器、性能-监控计数器、时间戳计数器等。TDX模块旨在为TD实施安全策略。在创建TD时，该模块旨在为每个TD分配一个唯一的私有KeyID．CPU旨在禁止IntelTDX模块和TD以外的软件使用私有KeyID进行内存访问。尝试通过SEAM模式之外的软件访问私有KeyID会导致页面错误异常(#PFKeyID的设备的DMATDagent行网络访问、存储服务、调用hypervisor服务等I/O操作。VMMGPAPA(EPT助分配TD使用的内存并将其映射到TD的GPA。当TD正在执行时，设计指定两个EPT将为TD激活：一个安全EPT用于提供私GPAPAEPTGPAPAIntel-TDX模块有助于为VMM提供安全EPT管理功能，以在安全EPT中添加或删除映射，并围绕这些操作实施安全策略，以保持内存布局的完整性。用于构建安全EPT的内存设计为使用唯一的per-TD内存加密密钥进行加密和完整性保护。创建TD时，IntelTDX模块将要求VMM用于托管虚拟机控制结构(VMCS)、TD的状态保存区等。该模块的目VMM同时分配给其他TDIntel-TDX模块将使用TD这些结构，以帮助为TD-CPU状态提供加密机密性和完整性保护。TDVMX-APIC虚拟化和APIC虚拟化架构旨在提供APIC的许多寄存器的CPU仿真，跟踪虚拟APICCPU将VMXrootTDVM。VMX-APIC虚拟化和虚拟中断架构的使用将有效地将中断传递到TD(s)，避免修改TDAPIC。请从Intel®TrustDomainExtensions®TDX的白皮书和技术规范：图3.26英特尔®TDX技术规范英特尔®TDX的云软件套件®TDX的Linux*IaaS)和平台即服务(PaaS)组件，®TDX在英特尔®TDX在IaaS主机上使用基于英特尔®SoftwareGuardExtensions（®SGX）QGS)图3.27英特尔®TDX的云软件套件构建套件对于端到端堆栈设置和验证，tdx-tools提供下游补丁和构建工具，只需几个简单的步骤即可构建整个堆栈。图3.28构建英特尔®TDX的云软件套件成功构建包后，将生成两个存储库。一个是主机存储库，其中TDXTDXQemuTDXLibvirt和TDVF。另一个存储库是包含英特尔TDX访客内核、grub2和填充程序的来宾存储库。管理TDX虚拟机与普通虚拟机一样，TD客户机可以由QEMU通过命令行启动，也可以由Libvirt通过XML模板进行编排。本章介绍如何管理TD访客的生命周期，以应对各种引导，例如安全启动、直接启动和grub启动。图3.29英特尔®TDX虚拟机启动具体的实现如下：安全启动TD来宾的安全启动与传统的非机密VM几乎相同。主要区别在于TDVF.fd需要静态测量到机读旅行证件中。它不允许在运行时通过EnrollDefaultKey等工具将安全启动密钥注册到EFI变量FV（固件卷）中。相反，开发了一个来自tdx-tools的新工具ovmfkeyenroll，以帮助在测量之前离线注册安全启动证书。图3.30英特尔®TDX安全启动英特尔®TDX的测量通常，TEE可以提供其来源和当前状态的证据或测量值，以便另一方可以验证证据，并且可以通过编程或手动方式来决定是否信任在TEE中运行的代码。此类证据由制造商可以担保的硬件签名通常很重要，这样检查证据的一方就可以强有力地保证它不是由恶意软件或其他未授权方生成的。远程方在成功验证证据后允许将秘密或密钥发送到TEE环境。图3.31机密虚拟机的测量可信计算基础(TCB和软件组件。对于机密VM，它包括CPUSEAM固件等硬件信息以及OVMF、引导加载程序（shim/grub）和内核等来宾组件。QEMUVMMOrchestratorLibvirtTCBTCB上的哈希链测量将扩展到一些安全寄存器，例如TPMPCR（平台配置寄存器）。来自多个安全寄存器的值构建为一个报告，并最终通过认证密钥签署为Quote。图3.32英特尔®TDX报告TD有两种类型的测量寄存器——MRTD和RTMR：MRTD（TD）TDTD的初始内容）RTMR（是英特尔TDX软件的一组通TD辑和数据。按照设计，来宾TD软件可以使用RTMR来测量启动过程图3.33英特尔®TDX启动测量过程英特尔®TDX的认证TDX（TD）（也称为TCB版本）的正版英特尔TDX系统上的TD内运行。TDX证明重新使用英特尔SGX基础设施来提供对给定测量TDQuote，即在TDQuotingEnclaveTD报告。图3.34英特尔®TDX远程证明过程步骤1：TD收到来自平台外挑战者的证明请求。步骤2：TD然后请求英特尔TDX模块向TD提供报告34：IntelTDXSEAMREPORTCPUReportTDTD有的SVN（）TDXTCB步骤5、6：TD请求VMM将报告转换为远程证明的报价。步骤7、8、9：TD报价飞地然后使用EVERIFYREPORT2验证报告上的MAC，如果验证通过，则通过使用TD的非对称证明密钥签署报告将报告转换为报价。步骤10：报价返回给挑战者。步骤11、12：挑战者使用证明验证服务来执行quote验证。面向英特尔TDX的Linux堆栈通过集成英特尔® SoftwareGuardExtensionsDataCenterAttestationPrimitives（英特尔®SGXDCAP）TDX比亚迪边缘视频加速服务器硬件方案不同的上层业务对底层硬件平台提出不同的技术需求，具体包括：VIMVNFRANCUFPGAARMCPUCPU适应边缘机房环境挑战边缘机房与核心机房相比条件较为恶劣，很多方面无法满足通用服务器的运行要求：600mm800mm45℃；边缘机房条件难以与大型数据中心等同，且数量庞大，所以单纯的改造机房并不现实，其中既有改造难度大造价高的原因，也有机房作为“战略资源”，很难自由扩展空间的因素，因此对服务器进行重新设计就是必经之路。满足运维管理需求边缘服务器承载大量电信级业务，并部署在较为恶劣的边缘机房，所以需要有强大管理运维能力保障：VIM/PIM工作，完善是为了更加有效的管理服务器；/边缘计算服务器硬件方案服务器物理形态、供电及环境适应性边缘服务器不但需要适应边缘机房的环境，还需要满足各类边缘业务在边缘机房的交付、部署与本地运维需求。具体包括：470mm500mm；部分边缘应用场景，可能需要支持在更宽的温度范围（例如-5~45）BEMC一般计算型服务器2U高度即可，存储型服务器可进一步放宽；但考虑边缘业务未来交付方便，可能会考虑“机框+多节点”的整体设计形态。硬件规格及关键组件ASICVPU（VideoProcessingUnit）加速卡配置，方案要求最高密度、最低成本、超低延迟、最低能耗、可计算存储架构,可直接用于现有服务器硬件接口，易使用，易维护等特性。由于采用视频加速卡方案，从功耗、空间和性能需求等多方面考虑，倾向于单路低功耗方案。同时考虑到边缘异构计算等在部件规格方面，一是对网卡的性能、兼容性等有较高要求，可能需要推动25G、100G网卡的应用以及生态的不断完善，同时加强对部件的选型要求或者形成比较严格的认证部件列表；二是对于网卡加速功能要求比较迫切，需将部分功能卸载至网卡，以提高网络处理速度并降低CPU负载，具体功能包括网络转发、IPSec、DPI和HQoSBIOS、BMCOTII项目将与服务器、BMC及FW厂商合作，开发统一的针对NFV比亚迪边缘服务器系统方案模块化服务器简介：比亚迪模块化设计理念是将：计算、存储、PCIe扩展、供电单元设计为独立模块，缩小了服务器的机箱长度，可根据不同需求灵活配置，更便于边缘场景安装和维护。19435mm的机房环境，可以支持在边缘网络机柜上架安装，该方案具备如下特性：42U该方案采用密闭的浸没式液冷箱设计方案，具有被动散热、外壳散热、内置热交换多种散热方案，具有如下特性：VPU（VideoProcessingUnit）