《深入理解边缘计算》——第一章：边缘计算入门

本章将从边缘计算系统的组成和概念解析、边缘计算的意义、边缘计算系统的部署与管理、不同应用部署方式的比较4个方面对边缘计算系统进行介绍。

1.1边缘计算系统

本节从组成部分和概念解析两方面来说明边缘计算系统。

1）组成部分：边缘计算系统由云、边、端三部分组成，每部分的解决方案不止一种。本书的云组成部分选择Kubernetes，边组成部分选择KubeEdge，端组成部分选择EdgeX Foundry。

2）概念解析：对组成边缘计算系统的云、边、端三部分涉及的相关概念进行说明。

1.1.1边缘计算系统组成

1.云——Kubernetes

Kubernetes是Google开源的大规模容器编排解决方案。整套解决方案由核心组件、第三方配套组件和运行时组成，具体如表1-1所示。

表 1-1 Kubernetes组成部分说明

组成部分	组件名称	组件作用	备注
核心组件	Kube-apiserver	Kubernetes内部组件相互通信的消息总线，对外暴露集群API资源的唯一出口
	Kube-controller	保证集群内部资源的现实状态与期望状态保持一致
	Kube-scheduler	将需要调度的负载与可用资源最佳匹配
	Kube-proxy	为节点内的负载访问和节点间的负载访问做代理
	Kubelet	执行kube-scheduler的调度结果，操作相应负载
第三方组件	etcd	存储集群的元数据和状态数据
	flannel	集群的跨主机负载网络通信的解决方案	需要对原来的数据包进行额外的封装、解封装，性能损耗较大
	Calico	集群的跨主机负载网络通信的解决方案	纯三层网络解决方案，不需要额外的封装、解封装，性能损耗较小
	coredns	负责集群中负载的域名解析
容器运行时	docker	目前默认容器运行时
	Containerd	比docker轻量，稳定性与docker相当容器运行时
	Cri-o	轻量级容器运行时	目前稳定性没有保证
	frakti	基于hypervisor的容器运行时	目前稳定性没有保证

2.边——KubeEdge

KubeEdge是华为开源的一款基于Kubernetes的边缘计算平台，用于将容器化应用的编排功能从云扩展到边缘节点和设备，并为云和边缘之间的网络、应用部署和元数据同步提供基础架构支持。KubeEdge使用Apache 2.0许可，并且可以免费用于个人或商业用途。KubeEdge由云部分、边缘部分和运行时组成，具体如表1-2所示。

表 1-2 KubeEdge组成部分说明

组成部分	组件名称	组件作用	备注
云部分	CloudCore	负责将云部分的事件和指令下发到边缘端，同时接受边缘端上报的状态信息和事件信息
边缘部分	EdgeCore	接收云部分下发的事件和指令，并执行相关指令，同时将边缘的状态信息和事件信息上报到云部分
运行时	docker	目前，KubeEdge默认支持docker	官方表示未来会支持containerd、cri-o等容器运行时

3.端——EdgeX Foundry

EdgeX Foundry是一个Linux 基金会运营的开源边缘计算物联网软件框架项目。该项目的核心是基于与硬件和操作系统完全无关的参考软件平台建立的互操作框架，构建即插即用的组件生态系统，加速物联网方案的部署。EdgeX Foundry 使有意参与的各方在开放与互操作的物联网方案中自由协作，无论其是使用公开标准还是私有方案。

EdgeX Foundry微服务集合构成了4个微服务层及2个增强的基础系统服务。4个微服务层包含从物理域数据采集到信息域数据处理等一系列的服务，2个增强的基础系统服务为4个微服务层提供服务支撑。

4个微服务层从物理层到应用层依次为：设备接入服务层（Device Service）、核心服务层（Core Service）、支持服务层（Supporting Service）、导出服务层（Export Service），2个增强的基础系统服务包括安全和系统管理服务，具体说明如表1-3所示。

表 1-3  Edgex Foundry组成部分说明

组成部分	组件名称	组件作用	备注
设备接入层服务	Device-modbus-go	Golang实现对接使用modbus协议设备的服务
	Device-camera-go	Golang实现对接摄像头设备的服务
	Device-snmp-go	Golang实现对接SNMP服务
	Device-mqtt-go	Golang实现对接使用MQTT协议设备的服务
	Device-sdk-go	Golang实现对接其他设备的SDK	SDK给设备接入提供了较大的灵活性
核心服务层	Core-command	负责向南向设备发送命令
	Core-metadata	负责设备自身能力描述，提供配置新设备并将它们与其拥有的设备服务配对的功能
	Core-data	负责采集南向设备层数据，并向北向服务提供数据服务
	Registry&config	负责服务注册与发现，为其他EdgeX Foundry微服务提供关于EdgeX Foundry内相关服务的信息，包括微服务配置属性，采用开源consul实现
支持服务层	Support-logging	负责日志记录
	Support-notifications	负责事件通知
	Support-scheduler	负责数据调度
导出服务层	Export-client	导出数据的客户端
	Export-distro	导出数据的应用
两个增强基础服务	System-mgmt-agent	提供启动、停止所有微服务的API
	Sys-mgmt-executor	负责启动、停止所有微服务的最终执行

1.1.2概念解析

组成边缘计算系统的云、边、端三部分的相关概念如下。

l云：涉及的概念包括Container、pod、ReplicaSet、Service、Deployment、Daemonset、Job、Volume、ConfigMap、Namespace、Ingress等。

l边：目前边缘系统的实现方式是通过对云原有的组件进行裁剪下沉到边缘，所以边涉及的概念是云的子集，而且与云保持一致。

l端: 部署在边上的一套微服务，目前没有引入新的概念。

目前，边和端都在沿用云的概念，所以本节主要是对云的概念进行解析。下面以图解的形式对云涉及的相关概念进行说明。由图1-1可知，Container是在操作系统之上的一种新的环境隔离技术，使用容器隔离出的独立空间包含应用所需的运行时环境和依赖库。在同一台主机上,容器共享操作系统内核。

图 1-1 container解析

由图1-2可知，pod是由一组容器组成的，在同一个pod内的容器共享存储和网络命名空间。在边缘计算系统中，pod是最小的可调度单元，也是应用负载的最终载体。

图 1-2 pod解析

由图1-3可知，ReplicaSet用来管理pod，负责将pod的期望数量与pod真实数量保持一致。在边缘计算系统中，ReplicaSet负责维护应用多实例和故障自愈。

图 1-3 ReplicaSet解析

由图1-4可知，service做为一组pod的访问代理，并在多个pod之间做负载均衡。pod的生命周期相对比较短暂，变更频繁。service作为一组pod固定不变的标记，除了为与之相关的pod做访问代理和负载均衡外，还会维护service与pod的对应关系。

图 1-4 Service解析

由图1-5可知，Deployment是Replicaset的抽象，在Replicaset的基础上增加了增加了一些高级功能，功能和应用场景与Replicaset相同。

图 1-5 Deployment解析

由图1-6可知，DaemonSet负责将指定的pod在每个节点上都启动一个实例。该功能一般用在部署网络插件、监控插件和日志插件的场景。

图 1-6 DaemonSet解析

由图1-7可知，Job用来管理批量运行的pod，该管理类型的pod会被定期批量触发。与deployment管理的pod的不同，Job管理的pod执行完相应的任务后就退出，不会一直驻留。在边缘计算系统中，一般用Job所管理的pod来训练AI模型。

图 1-7 Job解析

由图1-8可知，Volume是用来给pod提供存储的，通过挂载的方式与对应pod关联。Volume分临时存储和持久存储，临时存储类型的Volume会随着pod的删除被删除，持久存储类型的Volume不会随着pod的删除被删除。

图 1-8 Volume解析

由图1-9可知，ConfigMap做为pod存储配置文件的载体，通过环境变量（env）和文件卷的方式与pod进行关联。在边缘计算系统中，以ConfigMap方式来管理配置信息会更方便。ConfigMap 还可以对配置中的敏感信息进行加密，使配置信息更安全。

图 1-9 ConfigMap解析图

由图1-10可知，Namespace是对pod、service、configmap、deployment、daemonset等资源进行隔离的一种机制，一般用在同一公司的不同团队隔离资源的场景。在边缘计算系统中，用Namespace来对一个团队可以使用的资源（CPU、内存）和创建的负载所需要的资源进行限制。

图 1-10 Namespace解析图

由图1-11可知，Ingress作为集群内与集群外相互通信的桥梁，可以通过Ingress将集群内的服务暴露到集群外，同时可以对进入集群内的流量进行合理的管控。在边缘计算系统中，Ingress是一种资源对象，需要配合Ingress Controller和反向代理工作。

图 1-11 Ingress解析

1.2边缘计算的意义

随着移动互联网技术的发展，智能终端设备和各种物联网设备的数量急剧增加。在5G和万物互联时代，传统云计算中心集中存储、计算的模式已经无法满足终端设备对低时延、高带宽、强算力的需求。将云数据中心的计算能力下沉到边缘，甚至终端设备，并通过云数据中心进行统一交付、运维、管理，是云计算的趋势，从而催生了边缘计算。

边缘计算为终端用户提供实时、动态和智能的服务计算。边缘计算会将计算推向更接近用户的实际现场，这与需要在云端进行计算的传统云计算有着本质的区别，而这些区别主要表现在带宽负载、资源浪费、安全隐私保护以及异构多源数据处理上。

1.3边缘计算系统的部署与管理

本节对边缘计算系统的部署采用两个节点的形式，将边缘计算系统的云部分Kubernetes部署在云控制节点，边缘部分KubeEdge和端部分EdgeX Foundry部署在边缘计算上。这样做的目的是让读者能够快速部署边缘计算系统。通过操作已运行的系统对本书要讲的边缘计算系统有一个感性的认识。

1.3.1系统部署

本节将对边缘计算系统部署所需要的主机环境和部署docker、Kubernetes、KubeEdge和EdgeX Foundry的相关步骤进行说明。

1.主机环境

表4是部署边缘计算系统的两台主机的详细配置，该环境包含两个节点，即云控制节点和边缘节点。 

表1-4 部署边缘计算系统主机配置

	操作系统	CPU/内存	磁盘	带宽
云控制节点	CentOS 7.7 64位	2vCPU/8GiB	100GiB	2Mbit/s
边缘节点	CentOS 7.7 64位	4vCPU/16GiB	40GiB	2Mbit/s

2.部署docker

本节docker的安装步骤适合CentOS 7.7 64位操作系统，具体安装步骤如下。其他操作系统请参考docker官网相关安装文档。

1）卸载之前安装的老版本docker（可选），命令如下：

# yum remove docker docker-client docker-client-latest docker-common docker-latest docker-latest-logrotate docker-logrotate docker-engine

2）安装docker Repository，命令如下：

# yum install -y yum-utils device-Mapper-persistent-data lvm2

配置安装docker时需要的仓库链接：# yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

3）安装docker Engine-Community(最新版本)，命令如下：

安装docker：# yum install docker-ce docker-ce-cli containerd.io

4）查看已安装的docker相关包，命令如下：

# yum list docker-ce --showduplicates | sort -r

5）启动docker，命令如下：

# systemctl start docker

6）确认docker已正常运行

查看docker运行状态，确认docker已经正常运行，命令如下：

# systemctl status docker

如果输出类似图1-12的信息，说明docker已经正常运行。

图1-12 docker运行状态

3.部署Kubernetes

下面介绍Kubernetes16.5部署。本书的边缘计算系统中只需要部署Kubernetes的master节点来作为边缘计算系统的云控制中心，为了使部署Kubernetes教程更完整，也将部署Kubernetes的node节点的步骤包含了进来。

（1）安装 Kubernetes master节点

1）在需要运行Kubelet的节点上关闭swap，命令如下：

# swapoff -a

2）关闭防火墙，命令如下：

# systemctl disable firewalld && systemctl stop firwalld

3）关闭SELinux，命令如下：

# setenforce 0

4）下载所需的binary和images压缩包并解压，命令如下：

server binary是Kubernetes GitHub上release的编译好的Kubernetes版本，包括各组件的二进制和镜像。进⼊Kubernetes release⻚⾯，点击某个release的changelog，如CHANGELOG-1.16.5.md ，下载其中的server binary压缩包。下载完成的安装包如下所示：

解压安装包命令：# tar -zxvf Kubernetes-server-linux-amd64.tar.gz

通过上述命令解压后，我们会看到类似图1-13的内容。

图1-13 Kubernetes server binary压缩包解压

通过图1-13可知，压缩包Kubernetes-server-linux-amd64.tar.gz解压成文件夹Kubernetes,所需的binary和image都在kuernetes/server/bin目录下。

5）把Kubernetes/server/bin ⾥的kubeadm、 Kubelet、kubectl三个binary复制到 /usr/bin 下，命令如下：

#cp Kubernetes/server/bin/kubectl Kubernetes/server/bin/kubeadm Kubernetes/server/bin/Kubelet /usr/bin

6）提前加载控制平⾯镜像。

根据官方文档中Running kubeadm without an internet connection小节内容，kubeadm在执行init过程中需要启动控制平面，因此需要在此之前将控制平面的对应版本的镜像准备好，包括apiserver、 controller manager、scheduler和kubeproxy组件镜像，然后将Kubernetes/server/bin中包含的镜像压缩包加载到master节点，命令如下：

#docker load -i kube-scheduler.tar

但是，etcd和pause镜像需要通过其他途径（如docker Hub）来获得。

7）下载Kubelet的systemd unit定义⽂件，命令如下：

# export RELEASE=v1.16.5

#curl -sSL "https://raw.GitHubusercontent.com/Kubernetes/Kubernetes/${RELEASE}/build/debs/Kubelet.service" > /etc/systemd/system/Kubelet.service

其中，RELEASE变量需要提前export出来，如 v1.16.5。

8）下载kubeadm配置文件，命令如下：

#mkdir -p /etc/systemd/system/Kubelet.service.d

#curl -sSL 

9）设置Kubelet开机自启动，命令如下：

#systemctl enable Kubelet

10）初始化master节点，命令如下：

#kubeadm init --Kubernetes-version=v1.16.5 --pod-network-cidr=10.244.0.0/16

其中，Kubernetes-version告诉kubeadm具体需要安装什么版本的Kubernetes；pod-network-cidr=192.168.0.0/16 flflag的值跟具体网络⽅案有关，这个值对应后⾯的Calico⽹络⽅案。如果安装的是flflannel，则pod-network-cidr的值应该是10.244.0.0/16。

注意：如果所有镜像就绪，则kubeadm init步骤执⾏时间只需几分钟。如果安装过程遇到错误需要重试，则重试之前运⾏ kubeadm reset 。

11）配置kubectl。

由于下面安装pod⽹络时使⽤了kubectl，因此需要在此之前执⾏如下配置。

l如果后续流程使⽤root账户，则执⾏:

#export KUBECONFIG=/etc/Kubernetes/admin.conf

注意：为了方便，我们可以将该命令写到/.profifile下。

l如果后续流程使⽤⾮root账户，则执⾏：

# mkdir -p $HOME/.kube

# cp -i /etc/Kubernetes/admin.conf $HOME/.kube/config

# chown $(id -u):$(id -g) $HOME/.kube/config

12）安装 pod网络。

这⾥选择Calico，按照Kubernetes官⽅安装⽂档操作即可，命令如下：

#kubectl apply -f

Calico的yaml文件链接为：https://docs.projectCalico.org/v3.7/manifests/Calico.yaml

13）允许pod调度到master节点上，否则master节点的状态会是not ready（可选，如果⽤来做单节点集群则执⾏此步）。

默认会在执行kubeadm init过程中，通过执⾏以下命令使pod调度到master节点上：

#kubectl taint nodes --all node-role.Kubernetes.io/master-

14）执⾏到这步，我们已经有了⼀个单节点Kubernetes集群，可以运⾏pod。如果需要更多节点加⼊，可以把其他节点集合到集群。安装就绪的单节点集群如图1-14所示。

图1-14 单节点集群负载

（2）安装 Kubernetes node节点（可选）

1）swapoff -a //关闭内存swap分区

2）安装docker。

3）安装kubeadm、Kubelet。

详细参考安装 Kubernetes master节点的步骤。

将安装Kubernetes master时下载的server binary里包含的kubeadm、 Kubelet两个binary复制到 /usr/bin 下。

4）准备镜像。

把安装Kubernetes master时下载的kube-proxy、pause镜像转移到该节点并加载。

5）为Kubelet和kubeadm准备配置文件，命令如下：

# export RELEASE=v1.16.5

#curl -sSL "https://raw.GitHubusercontent.com/Kubernetes/Kubernetes/${RELEASE}/build/debs/Kubelet.service" > /etc/systemd/system/Kubelet.service

#mkdir -p /etc/systemd/system/Kubelet.service.d

#curl -sSL "https://raw.GitHubusercontent.com/Kubernetes/Kubernetes/${RELEASE}/build/debs/10-kubeadm.conf" > /etc/systemd/system/Kubelet.service.d/10-kubeadm.conf

6）设置Kubelet开机启动⾃动，命令如下：

# systemctl enable Kubelet

7）计算节点加入集群，命令如下：

在node上执行：

# kubeadm join --token : --discovery-token-ca-cert-hash sha256:

注意：这条命令在master节点执行kubeadm init结束时会在console上显⽰。

4.部署 KubeEdge

在Kubernetes已经安装成功的基础上安装KubeEdge1.1.0，使用Kubernetes的master节点作为其云控制节点。

（1）安装Cloud部分

1）修改Kubernetes master节点配置。

cloud端是KubeEdge中与kube-apiserver交互的组件，在该教程中cloud端与kube-apiserver交互使用的是非安全端口，需要在Kubernetes master节点上做如下修改：

#vi /etc/Kubernetes/manifests/kube-apiserver.yaml

- --insecure-port=8080

- --insecure-bind-address=0.0.0.0

2）下载安装包。

可以通过两种方式下载安装包：通过curl直接下载；在KubeEdge的release仓库中下载。

第一种方式：通过curl直接下载。

VERSION="v1.0.0"

OS="linux"

ARCH="amd64"

curl -L "https://GitHub.com/KubeEdge/KubeEdge/releases/download/${VERSION}/KubeEdge-${VERSION}-${OS}-${ARCH}.tar.gz" --output KubeEdge-${VERSION}-${OS}-${ARCH}.tar.gz && tar -xf KubeEdge-${VERSION}-${OS}-${ARCH}.tar.gz  -C /etc

注意：通过curl直接下载，由于网速问题一般需要时间比较久，失败的可能较大。

第二种方式：在KubeEdge的release仓库中下载。

进入KubeEdge的GitHub仓库中的KubeEdge v1.0.0 release，下载KubeEdge-v1.0.0-linux-amd64.tar.gz，将下载的安装包上传到Kubernetes master节点的/root目录下，进行如下操作：

#tar -zxvf KubeEdge-v1.0.0-linux-amd64.tar.gz

# mv KubeEdge-v1.0.0-linux-amd64 /etc/KubeEdge

3）在Kubernetes master节点生成证书。

生成的证书用来在KubeEdge的edge与cloud端加密通信。证书生成命令如下： 

#wget -L https://raw.GitHubusercontent.com/KubeEdge/KubeEdge/master/build/tools/certgen.sh

#chmod +x certgen.sh bash -x ./certgen.sh genCertAndKey edge

注意：上述步骤执行成功之后，会在/etc/KubeEdge下生成ca和certs两个目录。

4）创建device model 和 device CRDs。

在Kubernetes master节点上创建KubeEdge所需的device model和device CRD。创建步骤如下：

#wget -L https://raw.GitHubusercontent.com/KubeEdge/KubeEdge/master/build/crds/devices/devices_v1alpha1_devicemodel.yaml

#chmod +x devices_v1alpha1_devicemodel.yaml

#kubectl create -f devices_v1alpha1_devicemodel.yaml

#wget -L https://raw.GitHubusercontent.com/KubeEdge/KubeEdge/master/build/crds/devices/devices_v1alpha1_device.yaml

#chmod +x devices_v1alpha1_device.yaml

#kubectl create -f devices_v1alpha1_device.yaml

5）运行cloud端。

在Kubernetes master节点上运行KubeEdge的cloud端，命令如下：

#cd /etc/KubeEdge/cloud

#./CloudCore

注意：本节为了方便查看进程输出采用了前台驻留进程的方式，除了上述方式外，还可以通过systemd来查看。

（2）安装Edge部分

edge端是KubeEdge运行在边缘设备上的部分，在edge端运行之前需要安装合适的容器运行时，包括docker、containerd和cri-o。本节采用的容器运行时是docker，具体安装步骤可以参考“ 部署docker”小节。

1）准备edge端安装包。

因为证书问题，可以将Kubernetes master节点上的/etc/KubeEdge直接复制到edge节点的/etc下，命令如下：

#scp -r /etc/KubeEdge root@{ edge节点ip }:/etc

2）在Kubernetes master节点上创建edge节点的node资源对象，命令如下：

# vi node.json

{

"kind": "Node",

"apiVersion": "v1",

"metadata": {

"name": "edge-node",

"labels": {

"name": "edge-node",

"node-role.Kubernetes.io/edge": ""

}

}

}

# kubectl create -f node.json

3）修改edge部分的配置.

修改两部分内容：edge端连接cloud端的ip；edge端的name与在Kubernetes master上创建的node相对应。

● edge端连接cloud端的IP

edgehub.websocket.url：IP修改成Kubernetes master IP端口不变。

edgehub.quic.url：IP修改成Kubernetes master IP端口不变。

● edge端的name与在Kubernetes master上创建的node相对应。

controller:node-id与在Kubernetes master上创建的node的name保持一致。edged:hostname-override与在Kubernetes master上创建的node的name保持一致。

4）运行edge端，命令如下：

#cd /etc/KubeEdge/edge

#./EdgeCore

注意：本节为了方便查看进程输出采用了前台驻留进程的方式，除了上述方式外，还可以通过systemd来查看。

（3）验证KubeEdge是否正常运行。

KubeEdge部署成功后，在Kubernetes master节点通过kubectl工具查看其运行状态，具体如图1-15所示。

图1-15集群节点运行状态

5.部署EdgeX Foundry

EdgeX Foundry是一套可以用KubeEdge部署到边缘上的IoT SaaS平台。它可以采集、存储IoT设备的数据并将其导出到云数据中心，同时通过向终端设备下发指令对终端设备进行控制。

(1)准备镜像

本节以容器的形式部署EdgeX Foundry，需要在KubeEdge管理的边缘计算节点上准备edgex-ui-go、edgex-vault、edgex-mongo、support-scheduler-go、support-notifications-go、support-logging-go、core-command-go、core-metadata-go、core-data-go、export-distro-go、export-client-go、edgex-vault-worker-go、edgex-vault和edgex-volume共14个镜像。

有两种方法获取这些镜像：

1）直接在dockerhub上下载这些镜像；

2）根据EdgeX Foundry源码仓库中的Makefile文件构建这些镜像。

（2）准备部署EdgeXFdoundry组件所需的yaml文件

需要在前面部署的Kubernetes的master节点上准备与每个镜像对应的yaml文件对其进行部署。绝大多数镜像需要通过deployment进行部署,个别镜像需要Job进行部署，有些镜像还需要service对外暴露服务，这些yaml文件没有固定的标准。目前，EdgeX Foundry官方还没有提供相关yaml文件，建议根据具体场景进行编写。

（3）通过yaml文件部署EdgeX Foundry。

至此，我们已经拥有了Kubernetes的master节点，并将master节点作为云端控制节点，KubeEdge管理的节点作为边缘计算节点的云、边协同的集群。同时，在KubeEdge管理的节点上准备好了部署EdgeX Foundry所需的镜像，在Kubernetes的master节点上准备好了运行EdgeX Foundry镜像所需的yaml文件。接下来，只需在Kubernetes的master节点上通过kubectl命令创建yaml文件中描述的资源对象即可，具体命令如下：

#kubectl create -f {文件名}.yaml

yaml文件中描述的资源对象都创建好，意味着EdgeX Foundry的部署结束。至于，EdgeX Foundry是否部署成功，可以通过如下命令进行验证：

#kubectl get pods –all-namespace

从图1-16可知，部署的EdgeX Foundry相关组件都已正常运行。

图1-16 EdgeXFoundry组件运行状态

最后，通过在浏览器里访问edgex-ui-go（即在浏览器访问http://{EdgeX Foundry所运行主机的ip}:4000）进入EdgeX Foundry的登录页面，具体如图1-17所示。

图1-17 EdgeX Foundry的登录页面

在图1-17中输入对应的Name/Password，就可以成功进入EdgeX Foundry的控制台，具体如图1-18所示。

图1-18 EdgeX Foundry控制台

至此，我们已经拥有了由两个节点组成的，包含云、边、端的完整边缘计算系统。接下来介绍边缘计算系统的管理和在该边缘计算系统上部署应用。

1.3.2系统管理

通过以上对云、边、端三部分的梳理，我们了解到边缘计算系统的管理可分为集群管理和应用管理。

1.集群管理

集群管理是对集群级别的资源进行管理，这些资源主要包括node、namespace。下面通过对上述对象增、删、改、查进行说明。

（1）对node的操作

1）创建node，命令如下：

# kubectl create -f {node定义文件}.ymal

2）删除node，命令如下：

# kubectl delete -f {node定义文件}.ymal

#kubectl delete node {node名字}

3）修改node，命令如下：

#kubectl apply -f {修改过的node定义文件}.yaml

#kubectl edit node {node名字}

4）查看node，命令如下：

查看集群的node列表：#kubectl get nodes

查看指定node的具体定义：#kubectl describe node {node名字}

（2）对namespace的操作

1）创建Namespace，命令如下：

# kubectl create -f {namespace定义文件}.ymal

# kubectl create namespace {namespace名字}

2）删除Namespace，命令如下：

# kubectl delete -f {namespace定义文件}.ymal

#kubectl delete namespace {namespace名字}

3）修改Namespace，命令如下：

#kubectl apply -f {修改过的namespace定义文件}.yaml

#kubectl edit namespace {namespace名字}

4）查看Namespace。

查看集群的namespace列表，命令如下：

#kubectl get namespace

查看指定namespace的具体定义，命令如下：

#kubectl describe namespace {namespace名字}

集群级别的资源一般不需要用户对其进行创建、修改或者删除，只是在用户需要时对其进行查看。

2.应用管理

应用管理主要是对应用相关的资源进行管理，这些资源包括deployment、replicaset、pod、service endpoint、service acount、secret、persistent volume、persistent volume claim。对这些应用相关资源的操作，与集群相关资源的操作比较相似，我们可以参考集群管理对指定资源进行增、删、改、查的操作。

需要说明一点，应用相关的资源一般需要用户创建和管理，也就是说掌握对应用相关的资源的增、删、改、查是有必要的。

1.4 不同应用部署方式的比较 

本节主要对在云、边协同的集群上以及在传统的云平台上应用部署的架构、适用场景进行说明。

1. 在边缘计算系统上部署应用

图1-19是在云、边协同集群上部署应用的架构图。由架构图可知，云控制中心作为集群的控制平面，边缘计算节点作为应用负载最终运行的节点，运行在边缘计算节点上的应用与终端设备进行交互，负责终端设备的数据采集、存储和处理，并通过下发指令控制终端设备。

图1-20 在边缘计算系统上部署应用

1. 在云上部署应用

图1-21是在传统云平台上部署应用的架构图。由架构图可知，云既作为控制平面，也最终承载应用负载。运行在云上的应用负载类型是多种多样的，既有面向互联网企业互联网企业的Web服务，也有面向智能家居、工业互联网、车联网等行业的IoT SaaS平台。

图1-21在云上部署应用架构图

1. 不同部署方式的适用场景

通过对比在边缘计算系统上部署应用和在云上部署应用的架构可知：

1）在边缘计算系统上部署应用的架构适合实时性要求较高、比较重视隐私、与云连接的网络质量没有保障、网络带宽受限的场景，比如5G、无人驾驶、车联网、智能家居、工业互联网、医疗互联网、AR/VR等。

2）在云上部署应用的架构适合实时性要求不高、计算密集型、I/O密集型的场景，比如面向互联网的各种各样的Web服务、AI模型训练、离线大数据处理等。

1.5 本章小结

本章对边缘计算系统的组成、边缘计算的意义、边缘计算系统的部署与管理、不同应用部署方式的比较进行了介绍。下一章将从整体架构切入介绍从云、边、端的部署与配置。

《深入理解边缘计算》 已累计发售近10000册，云边端协同计算推荐必读书目