作者介绍
罗川，中国移动苏州研发中心工程师，曾负责数个集团大数据分析类项目的设计与研发，有多年大数据领域相关技术开发经验。近期对边缘计算领域开始进行研究，参与开发的中国移动云边缘平台获得了“5G MEC边缘云服务能力”可信云认证。
概要：本文首先简单介绍了什么是KubeEdge，然后基于最新的1.7.1版本，详细阐述了如何一步一步部署KubeEdge边缘计算平台。纯半自动化离线部署，简单易上手，快来试试吧~
KubeEdge是什么
KubeEdge是一个开源的边缘计算平台，基于Go语言开发，由华为主导，是CNCF的第一个边缘计算领域的官方项目，目前还处在孵化阶段。其核心功能是提供将云原生应用编排到边缘节点的能力，各类命令可以在云端统一下发。另外，提供了一些开箱即用的IoT设备通信协议，支持边缘节点和端设备通信。整个框架基于Kubernetes构建和改造，可将云端和边缘节点视为一个完整的Kubernetes集群。
由于其改造了Kubelet，且支持containerd等其他容器运行时，使得它的运行时占用的资源很少，因此其可以跑在配置较差的边缘设备上，比如一个树莓派。
KubeEdge部署
前置条件
- Kubernetes集群，至少有一个master节点
- 边缘节点部署容器运行时，比如Docker
- 边缘节点可访问Kubernetes Master节点的10000和10002两个端口（可修改）
我的环境
- 之前无锡研发区虚拟机搭建的Kubernetes集群，1.18.5版本
- 台式机安装的Ubutun虚拟机作为边缘节点，KubeEdge版本为最新1.7.1
- 单向网络，本机虚机可访问研发区虚机，反之则不行
本文省略掉Docker和Kubernetes的部署环节
下面开始部署KubeEdge
首先，官方文档提供了两种部署方式，keadm命令（KubeEdge提供的，非kubeadm）自动化安装和二进制文件手动安装
考虑到自动化安装过程肯定会遇到各类网络问题，我首先尝试了手动安装，但失败了，所以选择了半自动化安装...
部署KubeEdge需要分别在云端和边端部署，云端部署cloudcore及一些Kubernetes资源，边端部署edgecore，cloudcore和edgecore从本质上来讲，是两个Go语言编译的二进制文件
之所有说是半自动化安装，是因为我提前下好了需要用到的文件，并放到指定位置，这样keadm自动安装的时候就可以直接拿到，不用再去下载，当然，如果你的环境可以畅通的访问github就可完全自动化了
正式开始
先是云端，在Kubernetes master节点执行下列操作
（1）下载必要的文件，放置到正确的目录
Kubernetes crd文件，https://github.com/kubeedge/kubeedge/tree/master/build/crds
- devices_v1alpha2_device.yaml
- devices_v1alpha2_devicemodel.yaml
- cluster_objectsync_v1alpha1.yaml
- objectsync_v1alpha1.yaml
- router_v1_ruleEndpoint.yaml
- router_v1_rule.yaml
软件包，https://github.com/kubeedge/kubeedge/releases
- kubeedge-v1.7.1-linux-amd64.tar.gz
服务文件，https://github.com/kubeedge/kubeedge/blob/master/build/tools/cloudcore.service
- cloudcore.service
按如下分布放置/etc/kubeedge目录下
[root@fgm01 /etc/kubeedge]# tree . ├── cloudcore.service ├── crds │ ├── devices │ │ ├── devices_v1alpha2_devicemodel.yaml │ │ └── devices_v1alpha2_device.yaml │ ├── reliablesyncs │ │ ├── cluster_objectsync_v1alpha1.yaml │ │ └── objectsync_v1alpha1.yaml │ └── router │ ├── router_v1_ruleEndpoint.yaml │ └── router_v1_rule.yaml └── kubeedge-v1.7.1-linux-amd64.tar.gz
（2）一切就绪，启动cloudcore
keadm init --advertise-address="THE-EXPOSED-IP" --kubeedge-version=1.7.1 --kube-config=/root/.kube/config
PS：
--kube-config string Use this key to set kube-config path, eg: $HOME/.kube/config (default "/root/.kube/config")
如果没有的话，把/etc/kubeedge/admin.conf重命名过来
一切正常的话，会看到提示：KubeEdge cloudcore is running。接下来部署边端
（3）边端程序，是一个切割版的kubelet
跟云端一样，先准备好需要的文件，放置/etc/kubeedge目录下，具体url参考云端文件位置
cluo@ubuntu:/etc/kubeedge$ tree ├── cloudcore.service ├── edgecore.service └── kubeedge-v1.7.1-linux-amd64.tar.gz
（4）获取token
keadm gettoken
# 会得到类似这样的一串
befabd99bac9af1e65b6ae051711974044cd9b006f22c919087d5353afd225ea.eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2Mjc2MjM4NDJ9.2weCJl42gJMRpSSBUBZjjKU3FNvIQmcz1dOlWaKFDnA
（5）部署边端程序
keadm join --cloudcore-ipport="THE-EXPOSED-IP":10000 --befabd99bac9af1e65b6ae051711974044cd9b006f22c919087d5353afd225ea.eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2Mjc2MjM4NDJ9.2weCJl42gJMRpSSBUBZjjKU3FNvIQmcz1dOlWaKFDnA --kubeedge-version=1.7.1
执行keadm join，这一步实际上就是安装和运行edgecore和mqtt
这里要注意指定一下版本，跟你下载的压缩包版本一致，否则会找不到文件，又去下载...
看到提示KubeEdge edgecore is running，就说明安装好了
（6）验证
如何验证部署成功呢？
我们可以像查看kubernetes节点一样，查看边端节点
kubectl get nodes
如果打印出你的边端节点，且是Ready状态，就说明部署成功了。
我这边是这样的
边缘节点和K8s合影
（7）收尾工作
到这里基本上就部署结束了，但是如果想要追求完美，还有几点收尾工作
首先，如果这时候有小伙伴部署了新的负载到K8s集群，或者有Pod发生重启，这个Pod可能会跑进边缘节点，也就是我本地电脑的虚拟机内...
这当然是我们不希望的，边缘节点并不真是K8s集群内的工作节点，正常情况下，边缘节点和工作节点之间网络是不通的
另外一个小问题，这个node并不稳定运行，我们下班电脑也就关机了（真实环境的确边缘节点随时都可能掉线，这也是边缘计算框架针对设计优化的一个点）
所以我们这时候需要来点控制策略，让我们正常研发项目的Pod不要分配到边缘节点来
有两种思路，一种是控制Pod不要分配到固定节点，另外一种就是反过来，让一个节点只接受特殊Pod
显然后一种更适合目前的场景，毕竟我们已经有好几十Pod在跑了，重新去制作策略太麻烦了
如何让一个节点只接受特殊Pod呢？熟悉K8s的同学可能已经知道答案了，那就是给节点加入Taint（污点）
kubectl taint node edge-node1 node.kubernetes.io/kubeedge=:NoExecute
当你的Pod没有加对应的toleration（容忍）策略时（一般也不会加），就不会分配到这个节点了
好，第二个问题
你配完污点，这时候如果再去查看边缘节点是否运行了Pod，会发现竟然还有两个Pod....分别是kube-proxy和calico-node
这是两个daemon sets组件控制的，也就是每个节点默认都会运行一个这样的Pod，来保证K8s集群内的网络畅通，所以，正常情况下，任何一个节点都必须要拥有这两个Pod，才能和大家一起愉快的玩耍，但边缘节点就不这么想了，他更想静静...
好了，虽然这是两个kube-system空间的Pod，但其实kubeEdge是不需要这两个组件的，甚至kube-proxy正常运行还会导致edgecore起不来....
因此，我们最好也把它俩给去掉，但... 我们不是配了污点了么，所以为啥他俩还在呢？
答案只有一个，就是这两个Pod毕竟是系统级的，可能早就想到了有人会给节点设置污点，所以，提前设置了容忍策略，而且还是什么都能忍的那种
我们来查看一下，会找到一段类似这样的配置
kubectl get daemonsets kube-proxy -n kube-system -o yaml
tolerations:
- key: CriticalAddonsOnly
operator: Exists
- operator: Exists
可能第一眼还看不出来，这其实有两个规则，第二个规则只包含了一个operator，这个，就是答案了
An empty key with operator Exists matches all keys, values and effects which means this will tolerate everything.
所以，污点对于这两个Pod来说，不好使了，我们使用另外一个方案，那就是节点的反亲和性
边缘节点部署好后，会有一个表示节点角色的label，node-role.kubernetes.io/edge，我们从上面的截图也能看到
[root@fgm01 ~]# kubectl describe node edge-node1
Name: edge-node1
Roles: agent,edge
Labels: kubernetes.io/arch=amd64
kubernetes.io/hostname=edge-node1
kubernetes.io/os=linux
node-role.kubernetes.io/agent=
node-role.kubernetes.io/edge=
所以，我们加入这么一段硬性的反亲和性配置，让这个daemon sets不选择含有node-role.kubernetes.io/edge标签的节点
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchexpressions:
- key: node-role.kubernetes.io/edge
operator: DoesNotExist
最后，我们设置一下边缘节点的Docker私服仓库，让其跟云端共用一个镜像仓库，这样，云端下发应用时，边缘节点可正常拉取到镜像
好，至此，KubeEdge算是真正完成部署了，一个边缘节点已经抵达战场。
版权声明 (原创)：本文内容由移动云用户自发贡献，版权归原作者所有，移动云开发者社区不拥有其著作权，亦不承担相应法律责任。如果您发现本社区有涉嫌抄袭的内容，可填写举报信息，一经查实，本社区将立刻删除涉嫌侵权内容。
