作者 | 唐炳昌
來源|
阿裡巴巴雲原生公衆号随着邊緣計算的快速發展，越來越多的資料需要到網絡的邊緣側進行存儲、處理和分析，邊緣的裝置和應用呈爆發式增長。如何高效的管理邊緣側的資源和應用是業界面臨的一個主要問題。目前，采用雲原生的方法，将雲計算的能力下沉到邊緣并在雲端做統一排程、管控的雲邊端一體化架構得到了業界的廣泛認可。
2020 年 5 月，阿裡巴巴開源首個 Kubernetes 無侵入的邊緣計算雲原生項目
OpenYurt，并于同年 9 月份進入 CNCF SandBox。OpenYurt 針對邊緣場景中網絡不穩定、雲邊運維困難等問題，對原生 Kubernetes 無侵入地增強，重點提供了邊緣節點自治、雲邊運維通道、邊緣單元化的能力。
如圖 1 所示，本文通過在雲端部署 Kubernetes 叢集的控制面，并将樹莓派接入叢集來搭建雲管邊場景。基于這個環境示範 OpenYurt 的核心能力，帶大家快速上手 OpenYurt。
圖 1 原生 Kubernetes 叢集
環境準備
1. 基礎環境介紹
在雲端，購買 ENS 節點（ENS 節點具有公網 IP，友善通過公網對外暴露服務）來部署原生 K8s 叢集的管控元件。其中系統采用 ubuntu18.04、hostname 為 master-node、docker 版本為 19.03.5。
在邊緣，如圖 2 所示，将樹莓派 4 與本地的路由器連接配接，組成邊緣私網環境，路由器通過 4G 網卡通路網際網路。其中樹莓派 4 預裝系統為 ubuntu18.04、hostname為 edge-node、docker 版本為 19.03.5。
圖 2 邊緣環境實體圖
2. 原生 K8s 叢集搭建
本文示範環境基于社群1.16.6版本的K8s叢集，并采用社群提供的kubeadm工具來搭建叢集，具體操作如下：
- 在雲端節點和樹莓派上分别執行如下指令安裝 Kubernetes 元件。
curl -s https://mirrors.aliyun.com/kubernetes/apt/doc/apt-key.gpg | sudo apt-key add -
echo "deb https://mirrors.aliyun.com/kubernetes/apt/ kubernetes-xenial main" > /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt install -y kubelet=1.16.6-00 kubeadm=1.16.6-00 kubectl=1.16.6-00 - 使用 kubeadm 初始化雲端節點（在雲端節點上執行如下指令），部署過程中采用阿裡雲的鏡像倉庫，為了支援樹莓派的接入，該倉庫的鏡像做了 manifest 清單，能夠支援 amd64/arm64 兩種不同的 CPU 架構。
# master-node
kubeadm init --image-repository=registry.cn-hangzhou.aliyuncs.com/edge-kubernetes --kubernetes-version=v1.16.6 --pod-network-cidr=10.244.0.0/16 依據初始化完成之後的提示，拷貝 config 檔案到 $HOME/.kube 中：
```
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
- 樹莓派接入雲端叢集依據第二步中初始化完成以後輸出的節點接入資訊，在樹莓派上執行接入指令。
kubeadm join 183.195.233.42:6443 --token XXXX \
--discovery-token-ca-cert-hash XXXX
- 添加 cni 配置（雲端管控節點和樹莓派都需要配置），本文搭建的叢集使用主機網絡。建立 cni 配置檔案 /etc/cni/net.d/0-loopback.conf，并将如下内容拷貝到該檔案中。
{
"cniVersion": "0.3.0",
"name": "lo",
"type": "loopback"
}
- 在 master 節點上檢視部署效果。
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
edge-node Ready 74s v1.16.6 192.168.0.100 Ubuntu 18.04.4 LTS 4.19.105-v8-28 docker://19.3.5
master-node Ready master 2m5s v1.16.6 183.195.233.42 Ubuntu 18.04.2 LTS 4.15.0-52-generic docker://19.3.5
- 删除 CoreDNS（本文 Demo 中 CoreDNS 不需要使用），并将 master 節點的 taints 去掉（友善後續部署 OpenYurt 元件）。
kubectl delete deployment coredns -n kube-system
kubectl taint node master-node node-role.kubernetes.io/master-
# 原生 K8s 叢集在邊緣場景中的問題
基于上述環境，我們來測試一下原生 K8s 在雲管邊架構中對雲邊運維的支援和對雲邊網絡斷開時的反應。首先，我們從雲端部署一個測試應用 nginx，在 master 節點上執行 kubectl apply -f nginx.yaml，具體的部署 yaml 如下。
> 注意：nodeSelector 選擇 edge-node 節點，主機網絡配置為 true，并配置 pod 的容忍時間為 5s（預設 5min, 此處配置便于示範 pod 驅逐）。
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
tolerations:
-
key: "node.kubernetes.io/unreachable"
operator: "Exists"
effect: "NoExecute"
tolerationSeconds: 5
-
key: "node.kubernetes.io/not-ready"
nodeSelector:
kubernetes.io/hostname: edge-node
containers:
-
image: nginx
hostNetwork: true
檢視部署結果：
root@master-node:~# kubectl get pods -owide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx 1/1 Running 0 11s 192.168.0.100 edge-node <none> <none> 1. 測試常用的叢集運維指令，包括 logs、exec、port-forward。
在 master 節點上運維邊緣節點應用，執行 logs/exec/port-forward 等指令，檢視結果。
root@master-node:~# kubectl logs nginx
Error from server: Get https://192.168.0.100:10250/containerLogs/default/nginx/nginx: dial tcp 192.168.0.100:10250: connect: connection refused
root@master-node:~# kubectl exec -it nginx sh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
Error from server: error dialing backend: dial tcp 192.168.0.100:10250: connect: connection refused
root@master-node:~# kubectl port-forward pod/nginx 8888:80
error: error upgrading connection: error dialing backend: dial tcp 192.168.0.100:10250: connect: connection refused 從執行結果看，原生的k8s在雲管邊的場景中，無法提供從雲端運維邊緣應用的能力。這是因為邊緣節點部署在使用者的私網環境，從雲端無法通過邊緣節點的 IP 位址直接通路邊緣節點。
2. 測試邊緣斷網時對業務的影響
邊緣節點與雲端管控通過公網連接配接，經常會出現網絡不穩定，雲端斷連的情況。這裡我們将做兩個斷網相關的測試：
- 斷網 1 分鐘->恢複網絡
- 斷網 1 分鐘->重新開機邊緣節點->恢複網絡
觀察兩個測試過程中節點和 Pod 的狀态變化。本文 Demo 中的斷網方式是将路由器的公網連接配接斷開。
1）斷網 1 分鐘->恢複網絡
斷開網絡，大約 40s 後，節點變成 NotReady（正常節點 10s 鐘上報一次心跳，當 4 次沒有上報心跳時，管控元件認為節點異常）。
root@master-node:~# kubectl get nodes
NAME STATUS ROLES AGE VERSION
edge-node NotReady <none> 5m13s v1.16.6
master-node Ready master 6m4s v1.16.6 繼續等待 5s 之後（正常節點變為 NotReady 之後，5m 才開始驅逐 pod，此處為了測試效果，将 pod 的容忍時間配成了 5s），應用 pod 被驅逐，狀态變為 Terminating。
root@master-node:~# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx 1/1 Terminating 0 3m45s 将網絡恢複，觀察節點及 pod 變化。
root@master-node:~# kubectl get pods
No resources found in default namespace. 網絡恢複後，節點狀态變成 ready，業務 pod 被清除，這是因為邊緣節點的 Kubelet 擷取到業務 Pod 的 Terminating 狀态，對業務 Pod 做删除操作，并傳回删除成功，雲端也做了相應的清理。至此，業務 Pod 由于雲邊網絡的不穩定而被驅逐，然而在斷網期間，邊緣節點其實是可以正常工作的。
重新建立應用 nginx，用于下面測試。
root@master-node:~# kubectl get pods -owide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx 1/1 Running 0 4s 192.168.0.100 edge-node <none> <none> 2）斷網 1 分鐘->重新開機邊緣節點->恢複網絡
接下來，我們測試在斷網的情況下，邊緣節點的重新開機對業務的影響。斷網 1 分鐘之後，Node 和 Pod 狀态同上面測試結果，Node 變為 NotReady，Pod 的狀态變為 Terminating。此時，切換到私有網絡環境，登入到樹莓派上，将樹莓派重新開機，重新開機完成後等待大約 1 分鐘，觀察重新開機前後節點上的容器清單。
重新開機前邊緣節點容器清單（此時雲邊端開，雖然在雲端擷取的 pod 是 Terminating 狀态，但是邊緣并未 Watch 到 Terminating 的操作，是以邊緣的應用還正常運作）。
root@edge-node:~# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
9671cbf28ca6 e86f991e5d10 "/docker-entrypoint.…" About a minute ago Up About a minute k8s_nginx_nginx_default_efdf11c6-a41c-4b95-8ac8-45e02c9e1f4d_0
6272a46f93ef registry.cn-hangzhou.aliyuncs.com/edge-kubernetes/pause:3.1 "/pause" 2 minutes ago Up About a minute k8s_POD_nginx_default_efdf11c6-a41c-4b95-8ac8-45e02c9e1f4d_0
698bb024c3db f9ea384ddb34 "/usr/local/bin/kube…" 8 minutes ago Up 8 minutes k8s_kube-proxy_kube-proxy-rjws7_kube-system_51576be4-2b6d-434d-b50b-b88e2d436fef_0
31952700c95b registry.cn-hangzhou.aliyuncs.com/edge-kubernetes/pause:3.1 "/pause" 8 minutes ago Up 8 minutes k8s_POD_kube-proxy-rjws7_kube-system_51576be4-2b6d-434d-b50b-b88e2d436fef_0 重新開機後節點容器清單，斷網重新開機後，kubelet 無法從雲端擷取 Pod 資訊，不會重建 Pod。
root@edge-node:~# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
root@edge-node:~# 從重新開機前後的對比看，邊緣節點在斷網重新開機之後，節點上的 Pod 全部無法恢複。這就會導緻在雲邊斷網時，一旦節點重新開機，應用将無法工作。
将網絡恢複，觀察節點及 pod 變化，同上面測試結果，網絡恢複後，節點變為 Ready，業務 Pod 被清除。
root@master-node:~# kubectl get nodes
NAME STATUS ROLES AGE VERSION
edge-node Ready <none> 11m v1.16.6
master-node Ready master 12m v1.16.6
root@master-node:~# kubectl get pods
No resources found in default namespace. 接下來，再次部署業務 nginx，測試 OpenYurt 叢集對雲邊運維的支援和對雲邊斷網時的反應。
root@master-node:~# kubectl get pods -owide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx 1/1 Running 0 12s 192.168.0.100 edge-node <none> <none> 原生 K8s 叢集一鍵轉換為 OpenYurt 叢集
探究了原生 Kubernetes 在雲邊一體化架構中的不足之後，我們來看下 OpenYurt 叢集是否能滿足這種場景。現在，我們利用 OpenYurt 社群提供的叢集轉換工具 yurtctl，來将原生 K8s 叢集轉換成 OpenYurt 叢集。在 master 節點上執行如下指令， 該指令指定了元件的鏡像以及雲端節點，并指定安裝雲邊運維通道 yurt-tunnel。
yurtctl convert --yurt-controller-manager-image=registry.cn-hangzhou.aliyuncs.com/openyurt/yurt-controller-manager:v0.2.1 --yurt-tunnel-agent-image=registry.cn-hangzhou.aliyuncs.com/openyurt/yurt-tunnel-agent:v0.2.1 --yurt-tunnel-server-image=registry.cn-hangzhou.aliyuncs.com/openyurt/yurt-tunnel-server:v0.2.1 --yurtctl-servant-image=registry.cn-hangzhou.aliyuncs.com/openyurt/yurtctl-servant:v0.2.1 --yurthub-image=registry.cn-hangzhou.aliyuncs.com/openyurt/yurthub:v0.2.1 --cloud-nodes=master-node --deploy-yurttunnel 轉換大概需要 2min，轉換完成之後，觀察業務 pod 的狀态，可以看到轉換過程中對業務 pod 無影響（也可以在轉換過程中在新的終端使用 kubectl get pod -w 觀察業務 pod 的狀态）。
root@master-node:~# kubectl get pods -owide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx 1/1 Running 0 2m4s 192.168.0.100 edge-node <none> <none> 執行完成之後的元件分布如圖 3 所示，其中橙色部分是 OpenYurt 相關的元件，藍色部分是原生 K8s 元件。相應地，我們觀察雲端節點和邊緣節點的 pod。
圖 3 OpenYurt 叢集元件分布圖
雲端節點 yurt 相關的 pod：yurt-controller-manager 和 yurt-tunnel-server。
root@master-node:~# kubectl get pods --all-namespaces -owide | grep master | grep yurt
kube-system yurt-controller-manager-7d9db5bf85-6542h 1/1 Running 0 103s 183.195.233.42 master-node <none> <none>
kube-system yurt-tunnel-server-65784dfdf-pl5bn 1/1 Running 0 103s 183.195.233.42 master-node <none> <none> 邊緣節點新增 yurt 相關的 pod: yurt-hub（static pod）和 yurt-tunnel-agent。
root@master-node:~# kubectl get pods --all-namespaces -owide | grep edge | grep yurt
kube-system yurt-hub-edge-node 1/1 Running 0 117s 192.168.0.100 edge-node <none> <none>
kube-system yurt-tunnel-agent-7l8nv 1/1 Running 0 2m 192.168.0.100 edge-node <none> <none> 測試 OpenYurt 叢集在邊緣場景中的能力
1. 測試 logs/exec/port-forward 等運維指令，檢視結果
root@master-node:~# kubectl logs nginx
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
root@master-node:~# kubectl exec -it nginx sh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
# ls
bin dev docker-entrypoint.sh home media opt root sbin sys usr
boot docker-entrypoint.d etc lib mnt proc run srv tmp var
# exit
root@master-node:~# kubectl port-forward pod/nginx 8888:80
Forwarding from 127.0.0.1:8888 -> 80
Handling connection for 8888 測試 port-forward 時，在 master 節點上執行 curl 127.0.0.1:8888，可以通路 nginx 服務。
從示範結果看，OpenYurt 能夠很好地支援常用的雲邊運維指令。
同樣我們重複原生 K8s 中斷網的兩個測試，在測試之前我們先為邊緣節點 edge-node 開啟自治。在 OpenYurt 叢集中，邊緣節點的自治是通過一個 annotation 來辨別的。
root@master-node:~# kubectl annotate node edge-node node.beta.alibabacloud.com/autonomy=true
node/edge-node annotated 1）斷網 1 分鐘->網絡恢複
同樣，将路由器公網斷開，觀察 Node 和 Pod 的狀态。大約過了 40s，節點的狀态變成 NotReady，而大約過 1min 以後，Pod 的狀态一直是 Running，并不會被驅逐。
root@master-node:~# kubectl get nodes
NAME STATUS ROLES AGE VERSION
edge-node NotReady <none> 24m v1.16.6
master-node Ready master 25m v1.16.6
root@master-node:~# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 5m7s 恢複網絡，觀察 Node 和 Pod 的狀态，Node 狀态變為 Ready，Pod 保持 Running。可見雲邊網絡不穩定時，對邊緣節點的業務 Pod 無影響。
root@master-node:~# kubectl get nodes
NAME STATUS ROLES AGE VERSION
edge-node Ready <none> 25m v1.16.6
master-node Ready master 26m v1.16.6
root@master-node:~# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 6m30s 接下來，我們測試在斷網的情況下，邊緣節點的重新開機對業務的影響。斷網 1 分鐘之後，Node 和 Pod 狀态同上面測試結果，Node 變為 NotReady，Pod 保持 Running。同樣，我們登入到樹莓派上，将樹莓派重新開機，觀察重新開機前後節點上的容器清單。
重新開機前邊緣節點容器清單：
root@edge-node:~# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
38727ec9270c 70bf6668c7eb "yurthub --v=2 --ser…" 7 minutes ago Up 7 minutes k8s_yurt-hub_yurt-hub-edge-node_kube-system_d75d122e752b90d436a71af44c0a53be_0
c403ace1d4ff registry.cn-hangzhou.aliyuncs.com/edge-kubernetes/pause:3.1 "/pause" 7 minutes ago Up 7 minutes k8s_POD_yurt-hub-edge-node_kube-system_d75d122e752b90d436a71af44c0a53be_0
de0d693e9e74 473ae979be68 "yurt-tunnel-agent -…" 7 minutes ago Up 7 minutes k8s_yurt-tunnel-agent_yurt-tunnel-agent-7l8nv_kube-system_75d28494-f577-43fa-9cac-6681a1215498_0
a0763f143f74 registry.cn-hangzhou.aliyuncs.com/edge-kubernetes/pause:3.1 "/pause" 7 minutes ago Up 7 minutes k8s_POD_yurt-tunnel-agent-7l8nv_kube-system_75d28494-f577-43fa-9cac-6681a1215498_0
80c247714402 e86f991e5d10 "/docker-entrypoint.…" 7 minutes ago Up 7 minutes k8s_nginx_nginx_default_b45baaac-eebc-466b-9199-2ca5c1ede9fd_0
01f7770cb0f7 registry.cn-hangzhou.aliyuncs.com/edge-kubernetes/pause:3.1 "/pause" 7 minutes ago Up 7 minutes k8s_POD_nginx_default_b45baaac-eebc-466b-9199-2ca5c1ede9fd_0
7e65f83090f6 f9ea384ddb34 "/usr/local/bin/kube…" 17 minutes ago Up 17 minutes k8s_kube-proxy_kube-proxy-rjws7_kube-system_51576be4-2b6d-434d-b50b-b88e2d436fef_1
c1ed142fc75b registry.cn-hangzhou.aliyuncs.com/edge-kubernetes/pause:3.1 "/pause" 17 minutes ago Up 17 minutes k8s_POD_kube-proxy-rjws7_kube-system_51576be4-2b6d-434d-b50b-b88e2d436fef_1 重新開機後邊緣節點容器清單：
root@edge-node:~# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
0c66b87066a0 473ae979be68 "yurt-tunnel-agent -…" 12 seconds ago Up 11 seconds k8s_yurt-tunnel-agent_yurt-tunnel-agent-7l8nv_kube-system_75d28494-f577-43fa-9cac-6681a1215498_2
a4fb3e4e8c8f e86f991e5d10 "/docker-entrypoint.…" 58 seconds ago Up 56 seconds k8s_nginx_nginx_default_b45baaac-eebc-466b-9199-2ca5c1ede9fd_1
fce730d64b32 f9ea384ddb34 "/usr/local/bin/kube…" 58 seconds ago Up 57 seconds k8s_kube-proxy_kube-proxy-rjws7_kube-system_51576be4-2b6d-434d-b50b-b88e2d436fef_2
c78166ea563f registry.cn-hangzhou.aliyuncs.com/edge-kubernetes/pause:3.1 "/pause" 59 seconds ago Up 57 seconds k8s_POD_yurt-tunnel-agent-7l8nv_kube-system_75d28494-f577-43fa-9cac-6681a1215498_1
799ad14bcd3b registry.cn-hangzhou.aliyuncs.com/edge-kubernetes/pause:3.1 "/pause" 59 seconds ago Up 57 seconds k8s_POD_nginx_default_b45baaac-eebc-466b-9199-2ca5c1ede9fd_1
627673da6a85 registry.cn-hangzhou.aliyuncs.com/edge-kubernetes/pause:3.1 "/pause" 59 seconds ago Up 58 seconds k8s_POD_kube-proxy-rjws7_kube-system_51576be4-2b6d-434d-b50b-b88e2d436fef_2
04da705e4120 70bf6668c7eb "yurthub --v=2 --ser…" About a minute ago Up About a minute k8s_yurt-hub_yurt-hub-edge-node_kube-system_d75d122e752b90d436a71af44c0a53be_1
260057d935ee registry.cn-hangzhou.aliyuncs.com/edge-kubernetes/pause:3.1 "/pause" About a minute ago Up About a minute k8s_POD_yurt-hub-edge-node_kube-system_d75d122e752b90d436a71af44c0a53be_1 從重新開機前後的對比看，邊緣節點在斷網重新開機之後，節點上的 pod 能正常拉起，OpenYurt 的節點自治能力可以在斷網下保證業務的穩定運作。
恢複網絡，節點 Ready，觀察業務 pod 的狀态，網絡恢複後，業務 pod 狀态保持 running，有一次重新開機記錄，符合預期。
root@master-node:~# kubectl get pods -owide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx 1/1 Running 1 11m 192.168.0.100 edge-node <none> <none> 最後，我們利用 yurtctl 的能力将 OpenYurt 叢集，轉換為原生 K8s 叢集。同樣，可以觀察轉換過程中對現有業務不會有影響。
yurtctl revert --yurtctl-servant-image=registry.cn-hangzhou.aliyuncs.com/openyurt/yurtctl-servant:v0.2.1 OpenYurt 作為阿裡首個邊緣雲原生開源項目，基于商業化産品 ACK@Edge，在集團内部經曆了長時間的打磨。已經應用在 CDN、IoT、盒馬、ENS、菜鳥物流等衆多場景。針對邊緣場景，該項目堅持保持原生 K8s 的特性，以 Addon 的形式提供了邊緣節點自治、雲邊端一體化運維通道等能力。最近在社群同學的一起努力下又開源了邊緣單元化管理能力，同時後續還會繼續開源更多的邊緣管理能力，歡迎大家積極參與貢獻。釘釘搜尋群号：31993519，即可進群交流。