![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/d35db6f1020a4b85bf70f437903c342d.png)

作者 | 唐炳昌
來源|[阿里巴巴雲原生公眾號](https://mp.weixin.qq.com/s/Anr8UhTaNe3FCnKKfKoXNQ)

隨著邊緣計算的快速發展，越來越多的資料需要到網路的邊緣側進行儲存、處理和分析，邊緣的裝置和應用呈爆發式增長。如何高效的管理邊緣側的資源和應用是業介面臨的一個主要問題。當前，採用雲原生的方法，將雲端計算的能力下沉到邊緣並在雲端做統一排程、管控的雲邊端一體化架構得到了業界的廣泛認可。

2020 年 5 月，阿里巴巴開源首個 Kubernetes 無侵入的邊緣計算雲原生專案 [OpenYurt](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247490986&idx=1&sn=0317ec105534c0015f7baba307162b2e&chksm=fae51665cd929f7395c39e6f59d99806e77d54f7f4c2075ac5f892e752bdc9242aed50b961a8&scene=21#wechat_redirect)，並於同年 9 月份進入 CNCF SandBox。OpenYurt 針對邊緣場景中網路不穩定、雲邊運維困難等問題，對原生 Kubernetes 無侵入地增強，重點提供了邊緣節點自治、雲邊運維通道、邊緣單元化的能力。

如圖 1 所示，本文透過在雲端部署 Kubernetes 叢集的控制面，並將樹莓派接入叢集來搭建雲管邊場景。基於這個環境演示 OpenYurt 的核心能力，帶大家快速上手 OpenYurt。

![1.png](https://ucc.alicdn.com/pic/developer-ecology/f42b38da8ea94c149317099862ca3b8d.png)
圖 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.png](https://ucc.alicdn.com/pic/developer-ecology/c174ae3f5854421ab16c586aa197e321.png)
圖 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 <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
```

- 刪除 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/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.png](https://ucc.alicdn.com/pic/developer-ecology/e50b0fdd1a2d4643b8aebd2a2ffd5613.png)
圖 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 能夠很好地支援常用的雲邊運維指令。

## 2. 測試邊緣斷網時對業務的影響

同樣我們重複原生 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
```

### 2）斷網 1 分鐘->重啟邊緣節點->恢復網路

接下來，我們測試在斷網的情況下，邊緣節點的重啟對業務的影響。斷網 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 群內互動交流。</none></none></none></none></none></none></none></none></none></none></none></none></none></none></none></none></none></none></none></none></none></none></none></none></none>

OpenYurt 入門 - 在樹莓派上玩轉 OpenYurt

相關文章