摘要：为保证高速公路上门架系统的落地项目的成功落地，选择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。用批量的方式大量、快速部署成百上千个同样的微服务系统和环境。