随着邊緣計算的快速發展，越來越多的資料需要到網絡的邊緣側進行存儲、處理和分析，邊緣的裝置和應用呈爆發式增長。如何高效的管理邊緣側的資源和應用是業界面臨的一個主要問題。目前，采用雲原生的方法，将雲計算的能力下沉到邊緣并在雲端做統一排程、管控的雲邊端一體化架構得到了業界的廣泛認可。
今年5月，阿裡巴巴開源首個k8s無侵入的邊緣計算雲原生項目
OpenYurt，并于9月份進入CNCF SandBox。OpenYurt針對邊緣場景中網絡不穩定、雲邊運維困難等問題，對原生K8s無侵入地增強，重點提供了邊緣節點自治、雲邊運維通道、邊緣單元化的能力。
如圖1所示，本文通過在雲端部署K8s叢集的控制面，并将樹莓派接入叢集來搭建雲管邊場景。基于這個環境示範OpenYurt的核心能力，帶大家快速上手OpenYurt。
一、 環境準備
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工具來搭建叢集，具體操作如下。
（1）在雲端節點和樹莓派上分别執行如下指令安裝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 (2)使用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 (3)樹莓派接入雲端叢集
依據（2）中初始化完成以後輸出的節點接入資訊，在樹莓派上執行接入指令。
kubeadm join 183.195.233.42:6443 --token XXXX \
--discovery-token-ca-cert-hash XXXX (4)添加cni配置（雲端管控節點和樹莓派都需要配置），本文搭建的叢集使用主機網絡。建立cni配置檔案/etc/cni/net.d/0-loopback.conf，并将如下内容拷貝到該檔案中。
{
"cniVersion": "0.3.0",
"name": "lo",
"type": "loopback"
} (5)在master節點上檢視部署效果
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
edge-node Ready <none> 74s v1.16.6 192.168.0.100 <none> 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 <none> Ubuntu 18.04.2 LTS 4.15.0-52-generic docker://19.3.5 (6)删除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"
operator: "Exists"
effect: "NoExecute"
tolerationSeconds: 5
nodeSelector:
kubernetes.io/hostname: edge-node
containers:
- name: nginx
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/fordward等指令，檢視結果。
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變為NodeReady，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變為NodeReady，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 作為阿裡首個邊緣雲原生開源項目，基于商業化産品ACK@Edge，在集團内部經曆了長時間的打磨。已經應用在CDN、IoT、盒馬、ENS、菜鳥物流等衆多場景。針對邊緣場景，該項目堅持保持原生K8s的特性，以Addon的形式提供了邊緣節點自治、雲邊端一體化運維通道等能力。後續會繼續開源邊緣單元化管理、邊緣節點健康探測等能力，歡迎大家積極參與貢獻。