摘要：为保障高速公路上门架零碎的落地我的项目的胜利落地，抉择 K8s 和 KubeEdge 来进行整体的利用和边缘节点治理。

一、我的项目背景

本我的项目是在高速公路 ETC 联网和推动勾销省界收费站的大前提下，门架零碎的落地，也就是要把门架部署在覆盖全国范畴的高速公路上，收集车辆通行的牌示信息，以及相应的交易信息。

整体的状况是在边缘侧，即高速公路上会部署大量的门架和相应的控制器，相应的边缘终端，这些终端大略 10 万台，其上部署了相干的利用以收集相干信息。超过 50 万个利用部署到边缘节点，收集到信息后，通过免费专网向省核心以及路网核心上传对应的数据。

本次我的项目的工作挑战次要有两个方面：

将近 10 万台异构设施的治理，包含 arm，x86 等异构设施。

50 余万个利用的生命周期治理

为保障我的项目的胜利落地，咱们对整体架构做了选型，最终抉择了 K8s 和KubeEdge来进行整体的利用和边缘节点治理。

二、为什么抉择 Kubernetes

在我的项目里，尽管说是部署在边缘侧的利用，但它的复杂程度曾经和云上是相似的了，在边缘侧部署的利用曾经是由很多个微服务组成的。所以 Kubernetes 对于撑持这种微服务化的、云原生化的利用部署和大规模治理的能力，同样也实用于这个我的项目在边缘侧的应用。

具体来说，有一些典型的部署需要：

双机热备

多机多活互备

有关联的利用同节点部署以晋升利用间交互效率

同一利用的不同实例跨节点部署以晋升可用性

根据边缘节点的不同属性将利用部署于不同分组中

定义独立于节点的利用部署以及实现满足条件的新边缘节点上线后主动装置利用

这些需要，用 K8s 的这些 Deployment、Pod、ReplicaSet、DaemonSet 等外围对象来示意，是非常适合的。所以咱们就抉择了Kubernetes。

当然，还有一些重要的边缘侧特有的需要是原生的 Kubernetes 不具备的，但 Kubernetes 的架构是十分好的，易于扩大，灵活性很高，能够基于原生 Kubernetes 架构根底，依据边缘治理的非凡需要进行扩大。

三、为什么抉择 KubeEdge

一是业务本身的特点来决定的。这个业务的量十分大，波及的边缘节点散布在全国各地，所以它的边缘侧是多硬件架构、多厂家的，咱们须要异构的反对；边缘工控机低至 4 核 ARM SOC、1G 可用内存，咱们须要低资源占用的计划来治理边缘侧的节点；治理运维简单，从路网核心到最终路段，分为 6 级治理档次，治理老本高，咱们须要高集成度边缘的计划，让边缘足够简略，把出问题的概率降到最低，升高运维老本。

二是从边缘环境的特点来看的。从网络的角度来看，网络分为部省、省站两层，屡次转发，咱们须要边缘接入具备高灵活性，可反对专线、代理、公网、有线和无线接入等多种形式；各地基础设施的建设不同，有些省份的网络带宽低至 3M，咱们须要边缘和云之间的治理带宽占用降到最低；有些高速公路上的网络条件是十分差的，经常出现断网的状况。咱们须要边缘计划有离线自治的能力。

整体计划

接下来我会把整体计划关上成几层来别离介绍。

利用部署

首先是利用部署，就像我方才说的，在边缘侧要部署的业务非常复杂，它是由多个微服务所形成的云原生化的架构。所以咱们这些微服务以及中间件都容器化之后能够十分好的适应各种不同的异构操作系统，不便对立治理。

如下图所示，微服务架构分成前端和后端，前端次要把业务通过 Deployment 的形式部署到门架上，与后端之间是通过 EdgeMesh 实现的。通过这种服务发现的形式，实现微服务前后端业务的通信。而后端业务容器自身是无状态的，能够通过 Deployment 来部署。

前面的 Redis 包含 MySql 就能够通过 Statefulset 的形式来进行部署。通过这样的部署模型，咱们能够很完满的进行封装和自动化治理高可用的边缘侧的整套业务零碎。

但如果仅仅是用原生的 K8s 部署形式，并不能齐全满足咱们的需要，因为在我的项目里要部署的量十分大，左图的环境只是利用于一个收费站，而一个路段要治理几百上千个收费站，一一部署老本过高。所以咱们基于 K8s 之上又构建了一个工作工作流的引擎零碎，把每一个部署微服务的步骤定义为一个 job。用批量的形式大量、疾速部署成千盈百个同样的微服务零碎和环境。

大规模节点接入

除了下面提到的挑战，在应答大规模节点接入的状况下也遇见过一些问题：

每个省有本人的管理权限，咱们按 K8s 集群的配置配了多个 K8s 集群来进行治理，一个省对应一个 K8s 集群，而后在 K8s 之上通过对立的管理层解决简单跨集群数据统计等操作，从核心侧治理每个省的边缘侧，这就是多集群的管理手段。

咱们曾遇见一种景象，路网核心或省核心做网络降级等动作之后，网络有时候会呈现问题，所有省的边缘节点，失去与 K8s 的连贯，等网络复原之后，又会产生所有节点同时连贯核心侧的 K8s 集群，引起大量的并发连贯, 对核心侧的零碎造成冲击，导致利用异样。为了应答这种状况，咱们通过动静退却算法缓解节点同时接入所造成的流量冲击。

须要精简 NodeStatus 和 PodStatus 上报的信息。就前文所提到的，各地基础设施的建设不同，有些省份的网络带宽低至 3M，所以咱们须要减小状态信息的大小，升高上报流量的冲击，升高对网络的影响。

镜像仓库 Mirror 分级减速，无效升高了对网络的冲击，进步大批量部署的部署效率。

边缘业务高可用

接下来的是边缘业务高可用，依照原生 K8s 的降级状态，它会先删除旧版本 Pod，再创立新 Pod 并在这个过程中去拉取新版本镜像。这种操作在私有云网络条件较好的状况下，是没太大问题的。但在边缘侧，这样就会造成业务长时间的中断，免费数据缺失。所以针对这一个流程，咱们也是做了相应的降级和优化。

咱们先把降级下载镜像的告诉下发做预下载，下载胜利之后再删除已有的旧 Pod，启动新利用，优化了利用降级对服务中断的工夫的影响，将业务降级时整体业务中断的工夫从分钟级缩减到了 10s 内。

同时，思考到边缘设施有主备部署的状况，而边缘侧又不像云上有 ELB 服务。咱们又在边缘节点中容器化部署了 Keepalived，通过 VIP，为门架的摄像头等设施提供对应的 K8s 集群内的容器服务。

四、总结

以后基于 KubeEdge 的边缘管理系统治理着全国 29 个省、市、自治区的将近 100,000 个边缘节点，超过 500,000 边缘利用的部署。撑持了高速公路门架业务的一直调整、更新，满足了每日 3 亿条以上的信息采集。

为日后车路协同、主动驾驶等翻新业务的倒退提供了良好的平台撑持。

K8s 提供的通用部署和调度模型很适宜部署大规模边缘利用。

单纯原生 K8s 不能满足边缘侧业务的所有需要，KubeEdge 集成 K8s 云原生治理能力，同时对边缘业务部署和治理提供了很好的反对。

本文分享自华为云社区《如何应用 Kubernetes 治理中国高速公路上的 10 万边缘节点？》，原文作者：技术火炬手。

点击关注，第一工夫理解华为云陈腐技术~