KubeEdge 1.3.0 部署

kubeedge 4.6k 字 次

本文介绍了如何在两台 ubuntu 16.04 64 bit 双核 CPU 虚拟机上从源码开始部署 KubeEdge 1.3.0 集群的过程，云端 Kubernetes 版本为 1.17.3，Golang 版本为1.13.5。本文基于 KubeEdge 1.1.0 和 KubeEdge 1.2.0 部署文章，具有一定实践参考意义。

一、概述

1.1 环境

云端：ubuntu 16.04 64 bit，用户名为 ubuntu。IP 为 192.168.0.102。
边缘端：同上，IP 为 192.168.0.140。
KubeEdge部署涉及两端：

  • 云端
    docker， kubernetes 集群和 KubeEdge 云端核心模块。
  • 边缘端
    docker， mqtt 和 KubeEdge 边缘端核心模块。

技术总结：
1、搭建编译环境（建议自行编译源码），编译系统内存需足够大（如4GB）。
2、部署k8s，但只安装k8s master节点即可，node不需要安装。
3、编译 KubeEdge，生成证书（注：针对 kubectl logs命令而言），创建crds。
4、先运行得到配置文件，再修改。注意配置文件位置，注意系统平台框架。
5、检查主机名称，必须合规，否则注册不了。
6、先运行云端，获取 token，再修改边缘端配置。

1.2 依赖

依赖组件（含工具、编译器）及版本：

  • golang
    版本 1.13.5，到 下载。编译源码需要，如果不编译，则无须安装。需要指出的是，KubeEdge 对 golang 版本有兼容性，当前官方已经支持 1.13 版本 golang。
  • k8s 版本
    1.17，具体部署参考其它文章。理论上1.18也会支持，但无暇测试，仅猜测。
  • mosquitto
    1.6.8， 到 下载。
  • KubeEdge 相关的（云端、边缘端）
    最新发布版本为 v1.3.0， 到 下载。代码仓库为 。
    注意，github并不是一直都十分稳定，所以下载可能会较耗时。

本文部署时间约为2020年5月下旬。KubeEdge目前在快速开发中，请注时效性，以官方文档为准，本文仅针对 KubeEdge 1.3.0 有效。

1.3 方法论

最权威的莫过于 KubeEdge 官方安装文档：

  • 步步为营
    根据官方文档安装，先产生证书，再编译源码得到云端和边缘端核心程序。再修改配置文件，最后运行。

  • 事预则立
    下载官方编译好的二进制文件（cloudcore、edgecore），或者自行编译源码得到这两个二进制文件。准备好配置文件（并做适应性修改）。然后再运行。本文采用此方式。先准备好所有的文件，并统一放置到部署工程目录。

需要注意的是，KubeEdge 官方文档只涉及 KubeEdge 有关的部署，KubeEdge 还要依赖 docker 和 kubernetes（边缘端还要依赖 mosquitto）。而这些需要实践者额外进行，为减少篇幅，本文不过多涉及，但给出部署文章链接。

1.4 新版本主要变化

相比1.2.0 版本，1.3.0版本有如下变化（仅涉及个人感兴趣部分）：
1、不需要手动产生证书，程序自动产生。
2、支持 kubectl logs 命令（据说未来会支持 kubectl exec）。
3、不需要手动分发证书，边缘端自动获取。
4、云端高可用待有空闲有条件测试。

二、准备

在开始之前，必须先安装 Docker 并部署k8s集群。
Docker 安装可参考这里，kubernetes 安装可参考这里。需要指出的是，kubernetes 只部署 master 即可，node 无须部署。但必须安装网络插件（此处存疑，如果不安装，状态不是 Ready）。

2.1 创建部署文件目录

官方文档建议创建单独的目录存储二进制文件，如~/cmd/，在部署 1.1.0 版本时笔者也创建目录，但新版本做了优化，笔者认为无须部署目录，为方便测试，直接在新版本生成的目录下执行程序，其目录为$GOPATH/src/github.com/kubeedge/kubeedge/_output/local/bin。

2.2 KubeEdge 二进制

新版本渐渐使用 keadm 部署，对于不需要了解背后原理者而言，建议使用此方式。
本文使用的 KubeEdge 是从源码编译得到。

2.2.1 官方编译好的文件

到 下载官方编译好的二进制。压缩包名称为 kubeedge-v1.3.0-linux-amd64.tar.gz 。
也可以通过编译源码得到，方法参考文后。
另外，除了编译好的二进制外，还需要下载源码，地址为： 。因为部分配置文件只在仓库源码中才可找到（当然，也可以直接在 github 仓库上找到对应的文件下载）。

2.2.2 KubeEdge 源码编译

1、Golang 环境搭建
下载好 golang，并解压：

1
2
# mkdir ~/tools
# tar xf go1.13.5.linux-amd64.tar.gz -C ~/tools

在 ~/.bashrc 文件最后添加：

1
2
3
export PATH=$PATH:/home/ubuntu/tools/go/bin
export GOROOT=/home/ubuntu/kubeedge
export GOPATH=/home/ubuntu/kubeedge

执行 source ~/.bashrc 生效。验证：

1
2
# ubuntu@ubuntu:~/kubeedge$ go version
go version go1.13.5 linux/amd64

2、克隆仓库：

1
# git clone https://github.com/kubeedge/kubeedge.git $GOPATH/src/github.com/kubeedge/kubeedge

如果克隆速度慢，可以直接下载zip包，并解压源码到 $GOPATH/src/github.com/kubeedge/kubeedge，注意，这个目录一定是源码所在目录。
切换 1.3.0 分支：

1
# git checkout -b release-1.3 remotes/origin/release-1.3

3、检测 gcc 版本：

1
2
3
# gcc --version
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.

如果没有安装 gcc，则自行安装。

编译云端：

1
2
# cd $GOPATH/src/github.com/kubeedge/kubeedge/
# make all WHAT=cloudcore

编译边缘端：

1
2
# cd $GOPATH/src/github.com/kubeedge/kubeedge
# make all WHAT=edgecore

生成的二进制位于_output/local/bin/目录下。

2.3 生成证书

1.3.0 正式版本不需要手动生成证书，如果已经安装了旧版本，则需要清除 /etc/kubeedge/ca 和 /etc/kubeedge/certs 目录的证书。执行如下命令：

1
2
kubectl delete secret casecret -nkubeedge
kubectl delete secret cloudcoresecret -nkubeedge

如果是首次安装，忽略此步骤即可。

生成证书以支持 kubectl logs 命令

确认 k8s 集群正常运行，本文使用 kubeadmin 部署，其证书位于/etc/kubernetes/pki/目录（注：生成证书脚本需要使用/etc/kubernetes/pki/ca.crt和/etc/kubernetes/pki/ca.key文件）。
先设置云端IP：

1
2
3
export CLOUDCOREIPS="192.168.0.102"
注：可同时设置多个，如：
export CLOUDCOREIPS="172.20.12.45 172.20.12.46"

生成证书：

1
$GOPATH/src/github.com/kubeedge/kubeedge/build/tools/certgen.sh stream

确保如下目录存在，如否创建之，否则证书无法生成：

1
2
mkdir -p /etc/kubeedge/ca
mkdir -p /etc/kubeedge/certs

注：

设置 iptables：

1
iptables -t nat -A OUTPUT -p tcp  --dport 10350 -j DNAT --to 192.168.0.102:10003

（注：设置 NAT 端口转发）

2.4 创建设备模块和设备CRD yaml 文件

1
2
3
4
5
6
7
# cd $GOPATH/src/github.com/kubeedge/kubeedge/build/crds/devices
# kubectl create -f devices_v1alpha1_devicemodel.yaml
# kubectl create -f devices_v1alpha1_device.yaml

# cd $GOPATH/src/github.com/kubeedge/kubeedge/build/crds/reliablesyncs
# kubectl create -f cluster_objectsync_v1alpha1.yaml
# kubectl create -f objectsync_v1alpha1.yaml

注：新版本的 yaml 文件有两类，在 devices 和 reliablesyncs 目录。可用kubectl get crds查看。

2.6 配置云端节点

新版本配置文件由 cloudcore 程序生成，执行：

1
2
3
# cd $GOPATH/src/github.com/kubeedge/kubeedge/_output/local/bin
# mkdir -p /etc/kubeedge/config/ 
# ./cloudcore --minconfig > /etc/kubeedge/config/cloudcore.yaml

注1：cloudcore --minconfig生成最小配置，类似有cloudcore --defaultconfig。
注2：cloudcore 默认使用的配置文件为/etc/kubeedge/config/cloudcore.yaml。
边缘端类似，下省略。

接着修改配置文件：

1
# vim /etc/kubeedge/config/cloudcore.yaml

官方默认为kubeconfig: "/root/.kube/config"，本文改为 kubeconfig: "/home/ubuntu/.kube/config"。其它保持默认。注：具体的路径，取决于部署 k8s 时的选择，就前2个路径而言，前者一般由 root 权限运行，后者是普通权限（普通用户）运行。

2.7 配置边缘节点

新版本配置文件由 edgecore 程序生成，因此，需要在边缘端机器上执行。具体参考下文。

2.8 mqtt

mqtt 只有边缘端需要。
如果边缘端为 ubuntu 系统，直接使用源安装：

1
2
3
4
# add-apt-repository ppa:mosquitto-dev/mosquitto-ppa // 添加源
# apt-get update // 更新
# apt-get install mosquitto // 安装mqtt服务端
# apt-get install mosquitto-clients // 如果需要测试，则安装mqtt客户端

另外也可以使用源码编译。

在 ubuntu 系统，安装 mosquitto 成功后会自动启动服务。由于 KubeEdge 使用多个端口，故需用配置文件。服务端添加多端口：

1
2
3
4
5
vim /etc/mosquitto/conf.d/port.conf
port 1883
listener 1884
```  
此处指定 1883 和 1884 端口，从 KubeEdge 生成配置文件可知。没有指定协议，默认使用 mqtt。修改配置后需要重启：

/etc/init.d/mosquitto restart

1
2
3
4

或者手动启动：  
``` 
/usr/sbin/mosquitto -d -c /etc/mosquitto/mosquitto.conf

建议使用系统级别服务，预防漏掉此步骤，导致 KubeEdge 测试失败。

可用如下命令验证服务是否正常：

1
mosquitto_pub -h <mqtt服务IP> -p 1884 -t "hello" -m "this is hello world"

如果出现Error: Connection refused表示服务（及对应的端口）未启动。

题外话：
在嵌入式 ARM Linux 环境中，Buildroot 已包含 mosquitto，可直接勾选。此处略，根据笔者实验，Buildroot 的 mosquitto 所有配置均在文件 /etc/mosquitto/mosquitto.conf 中。使用如下命令操作：

1
2
3
4
5
6
7
8
9
10
systemctl restart mosquitto  // 重启
systemctl stop mosquitto     // 停止
```  

## 三、部署

### 3.1 云端

#### 3.1.1 查看 k8s 集群
查看节点状态：

kubectl get node

NAME STATUS ROLES AGE VERSION
latelee-master Ready master 3m v1.17.3

1
2
3
4
此刻只有云端节点就绪。  

#### 3.1.3 运行云端核心
可以另建目录运行程序，也可以在程序生成目录，此处选择后者，方便调试。

cd $GOPATH/src/github.com/kubeedge/kubeedge/_output/local/bin

./cloudcore // 建议先如此，方便观察日志

也可以：

nohup ./cloudcore > cloudcore.log 2>&1 &

1
2
如果使用系统服务方式，启动脚本为`build/tools/cloudcore.service`，需修改`ExecStart`为真实值。  
示例如下：

[Unit]
Description=cloudcore.service

[Service]
Type=simple
Restart=always
ExecStart=/etc/kubeedge/cloudcore

[Install]
WantedBy=multi-user.target

1
添加服务命令：

cp build/tools/cloudcore.service /etc/systemd/system/cloudcore.service
sudo systemctl daemon-reload
sudo systemctl start cloudcore

1
2
3
4
5
6

**注意，1.3版本不再需要手动生成证书，改为用 k8s secret 方式，因此，必须先运行云端，才会生成 secret(至少成功运行一次，以产生 secret)，否则无法得到 token，无法配置边缘端。**

### 3.2 边缘端
#### 3.2.1 分发
前面已经准备好了文件，直接部署就方便很多。注意，需要将边缘端可执行文件拷贝到边缘机器上。方式多种，建议使用 scp 命令。前提是安装了 SSH 协议。**在边缘端机器上执行拷贝（也称为分发）示例**：

mkdir -p /etc/kubeedge/config ~/kubeedge/

cd ~/kubeedge/

scp -r 192.168.0.102:/home/ubuntu/kubeedge/src/github.com/kubeedge/kubeedge/_output/local/bin/edgecore ~/kubeedge/

1
2
3
4
5
6
注1：此操作在边缘端机器上，非云端。假设部署工程目录为`~/kubeedge`。  
注2：1.3.0 版本无须手动拷贝证书，在运行边缘端时会自动从云端获取并存储在`/etc/kubeedge/`目录下，从结果看，依然生成 /etc/kubeedge/ca 和 /etc/kubeedge/certs ，亦即与前面版本保持一致。  
注3：如果以其它登陆用户身份拷贝，可在IP地址前加用户名，如`sudo scp -r latelee@192.168.0.102:/etc/kubeedge/* /etc/kubeedge`。  

#### 3.2.2 获取 token
**前文已经运行了云端，会自动产生token，这里要先切换到云端机器，获取 secret，再将 tokendata 内容解码得到 token**。示例如下：

kubectl get secret tokensecret -n kubeedge -oyaml

输出：
apiVersion: v1
data:
tokendata: ZWE1NDg3YWNhYjZlMWEwNmE2OGI5OTNkOTMxNGVlMzA5OTg2YzJkM2MyOTkzMmNlNGI2NTE2MzI0NzljMDlhOC5leUpoYkdjaU9pSklVekkxTmlJc0luUjVjQ0k2SWtwWFZDSjkuZXlKbGVIQWlPakUxT1RFeE1USXhNamg5LlVoUHBBdnR6YmhMZkcycUNaZmtqX3Zoak9qbEw5VEFQdElGWkJQTlpuZ0E=
kind: Secret
…

解码：

echo ZWE1NDg3YWNhYjZlMWEwNmE2OGI5OTNkOTMxNGVlMzA5OTg2YzJkM2MyOTkzMmNlNGI2NTE2MzI0NzljMDlhOC5leUpoYkdjaU9pSklVekkxTmlJc0luUjVjQ0k2SWtwWFZDSjkuZXlKbGVIQWlPakUxT1RFeE1USXhNamg5LlVoUHBBdnR6YmhMZkcycUNaZmtqX3Zoak9qbEw5VEFQdElGWkJQTlpuZ0E= | base64 -d

输出结果为：
ea5487acab6e1a06a68b993d9314ee309986c2d3c29932ce4b651632479c09a8.eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE1OTExMTIxMjh9.UhPpAvtzbhLfG2qCZfkj_vhjOjlL9TAPtIFZBPNZngA // 注意解码后字符串没有换行，要仔细核对

1
2
3
4
**再次强调，本小节在云端机器执行。**  

#### 3.2.3 配置
生成配置文件：

./edgecore –minconfig > /etc/kubeedge/config/edgecore.yaml

1
修改配置文件：

vim /etc/kubeedge/config/edgecore.yaml

1
2
3
4
5
6
7
8
注意3处地方。  
1. 修改`websocket`下的`server`，默认为`127.0.0.1:10000`，需改为实际云端 IP 地址，此处为`192.168.0.102:10000`。
2. 修改（确认）`podSandboxImage`，X86平台为`podSandboxImage: kubeedge/pause:3.1`（默认），ARM 平台根据位数不同，可设为`kubeedge/pause-arm:3.1`或`ubeedge/pause-arm64:3.1`。  
3. 填写 edgeHub 下的 token 值，见 3.2.2 小节生成的结果。  
其它要点：cgroup 驱动默认值为：`cgroupDriver: cgroupfs`，无须改 Docker 配置。网络设备接口名称及 IP 地址，会运行上述命令时自动检测获取，无须修改（注：在一台虚拟机中，网卡为 enp0s3，但配置文件中依然为 eth0）。  

#### 3.2.4 运行
接上，运行边缘端核心：

./edgecore // 建议先如此，方便观察日志

也可以：

nohup ./edgecore > edgecore.log 2>&1 &

1
2
3

如果使用系统服务方式，启动脚本为`build/tools/edgecore.service`，需修改`ExecStart`为真实值。  
示例如下：

[Unit]
Description=edgecore.service

[Service]
Type=simple
Restart=always
ExecStart=/etc/kubeedge/edgecore

[Install]
WantedBy=multi-user.target

1
添加服务：

cp build/tools/edgecore.service /etc/systemd/system/edgecore.service
sudo systemctl daemon-reload
sudo systemctl start edgecore

1
2
3
4

这里再强调一次 mqtt，另起终端，运行命令：  
``` 
/usr/sbin/mosquitto -d -c /etc/mosquitto/mosquitto.conf

3.3 验证

在云端查看状态：

1
2
3
4
# kubectl get node
NAME           STATUS   ROLES        AGE    VERSION
latelee-master Ready    master       24m    v1.17.3
latelee-node   Ready    agent,edge   2m9s   v1.17.1-kubeedge-v1.3.0-beta.0.49+5bfca35b2d99a5-dirty

云端和边缘端均为 Ready 状态。

尝试部署官方的 deployment：

1
kubectl apply -f $GOPATH/src/github.com/kubeedge/kubeedge/build/deployment.yaml

输出示例：

1
2
3
# kubectl get pod -owide
NAME                                           READY   STATUS    RESTARTS   AGE     IP       NODE         NOMINATED NODE   READINESS GATES
nginx-deployment-77698bff7d-zf5c6              1/1     Running   0          110s   <none>   latelee-node    <none>           <none>

扩容测试：

1
kubectl scale deployment nginx-deployment --replicas=4

预期效果：有4个pod出现，但只有1个正常运行，因为该 deployment 导出了节点端口，前面的 pod 已经占用，无法再分配。理论上，如果有4个节点，则会自动将 deployment 调度到4个节点上。输出示例：

1
2
3
4
5
6
7
8
9
# kubectl get pod 
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-77698bff7d-b9mlc   0/1     Pending   0          6s
nginx-deployment-77698bff7d-ddvl2   0/1     Pending   0          6s
nginx-deployment-77698bff7d-p6k8t   0/1     Pending   0          7s
nginx-deployment-77698bff7d-zf5c6   1/1     Running   0          2m27s
```  
  
删除：

kubectl delete -f $GOPATH/src/github.com/kubeedge/kubeedge/build/deployment.yaml

1
2
3
4
5
6
7
8

测试小记：
1. 初步测试，可以正常删除 pod了。  
2. 再次运行云端程序，查看 tokensecret，发现值不同，但边缘端使用旧的 token 可以成功连接。

## 四、ARM部署
ARM的部署十分简单，将 edgecore 交叉编译即可，其它与 X86 环境是一致的，这里再列一次：创建对应的目录，拷贝边缘端可执行二进制文件，启动mqtt（一般作为系统服务随系统启动而启动），运行边缘端。  
安装交叉编译器：

sudo apt-get install gcc-arm-linux-gnueabihf

1
设置环境变量并编译：

export GOARCH=arm
export GOOS=”linux”
export GOARM=7
export CGO_ENABLED=1
export CC=arm-linux-gnueabihf-gcc
export GO111MODULE=off
make all WHAT=edgecore

1
2
3
4
5
6
7
8
9
10
11
12
13
14
注：KubeEdge 已经将依赖包纳入代码仓库，直接编译即可，不需要下载额外的包，为安全，可暂时禁止 GO111MODULE。  

## 五、清除
kubeedge运行文件：  
1、/etc/kubeedge/： 证书、配置文件（云边均有）。  
2、/var/lib/kubeedge/： 云端有socket文件kubeedge.sock ，边缘端有数据库文件edgecore.db。  

如果要完全清理kubeedge环境，上述目录需要删除。  

## 六、问题
在测试时发现的问题及解决方法。  

1、  
云端运行时出现：

./cloudcore

[address: Invalid value: “unix:///var/lib/kubeedge/kubeedge.sock”: unixSocketAddress unix:///var/lib/kubeedge/kubeedge.sock dir /var/lib/kubeedge not exist , need create it]

1
解决：此目录保存socket文件，需要手动创建目录

mkdir -p /var/lib/kubeedge

1
2
3
4
5

备注：1.3.0 版本似乎无须手动创建了。  

2、  
云端无法获取请求的资源：

./cloudcore
…
github.com/kubeedge/kubeedge/cloud/pkg/synccontroller/synccontroller.go:162: Failed to list *v1alpha1.ObjectSync: the server could not find the requested resource (get objectsyncs.reliablesyncs.kubeedge.io)

1
2
3
4
没有执行`$GOPATH/src/github.com/kubeedge/kubeedge/build/crds/reliablesyncs`目录的yaml文件，参见 2.4 小节。  

3、  
Cgroup 驱动不匹配：

[CGroupDriver: Invalid value: “groupfs”: CGroupDriver value error]

1
2
3
4
5
6
7
如果 Docker 使用的驱动方式为 systemd，则需要修改 yaml 文件为 systemd，如使用 cgroupfs，Docker 也要保持一致。  

4、  
边缘端机器的配置文件的主机名称、IP，必须与真实主机一致。否则会注册不成功。   

5、  
节点注册失败：

create node LATE-LEE error: Node “LATE-LEE” is invalid: metadata.name: Invalid value: “LATE-LEE”: a DNS-1123 subdomain must consist of lower case alphanumeric characters, ‘-‘ or ‘.’, and must start and end with an alphanumeric character (e.g. ‘example.com’, regex used for validation is ‘a-z0-9?(.a-z0-9?)*’) , register node failed

1
2
3
4
主机名称不合法，必须是小写字母、数字，其它字符只能是`-`或`.`（下划线也不行），而且名称的开头和结尾必须是小写字母。（注：这是k8s dns命名的一个规范）。  

6、  
清理相关。

Failed to check the running environment: Kubelet should not running on edge node when running edgecore

1
一般出现于k8s和kubeedge混用情况，需要完全清理k8s方可。相似问题有：

Orphan pod: Orphaned pod “8685b805-a1c7-4687-8ce8-c77d24af5828” found, but volume paths are still present on disk

1
2
3
4
5

如果要重新运行edgecore，需要删除`/var/lib/kubeedge/edgecore.db`。  

7、  
边缘端有配置 token：

Error: token are in the wrong format

1
2
3
4
需要在云端生成 token，并填写边缘端配置文件的 token 字段。  

8、  
mqtt 服务未运行。提示：

connect error: Network Error : dial tcp 127.0.0.1:1883: connect: connection refused

1
2
3
4
根据前文运行 mqtt。  

9、
无法查看边缘端 pod 日志：

kubectl logs nginx-deployment-77698bff7d-wmqfx

Error from server: Get : dial tcp 192.168.0.140:10350: connect: connection refused

1
在边缘端查看端口是存在的：

netstat -ntpl | grep 10350

tcp 0 0 127.0.0.1:10350 0.0.0.0:* LISTEN 5690/edgecore

1
本机测试该端口：

curl 127.0.0.1:10350

404 page not found
`
提示404。
该问题目前还没排查。

七、小结

KubeEdge 在2020年5月中旬（即本文发表前16天）发布了1.3.0。笔者本想在发布时进行测试验证（主要想看看新特性），但宥于家庭琐事，既想研究技术又想把家庭照料得很好是两难全之事。但最终还是下定决心，利用几个深夜时间慢慢摸索，总算有了本文。

参考

  • 官方源码仓库：
  • 官方镜像：
  • 压缩包：
  • 官方安装文档：
  • KubeEdge環境を構築してみた by AWS EC2:
  • KubeEdge 部署:
  • KubeEdge 1.2.0 部署: