OpenYurt 入门 – 在树莓派上玩转 OpenYurt

OpenYurt 入门 - 在树莓派上玩转 OpenYurt

作者 |唐炳昌
来源|阿里巴巴云原生公众号

随着边缘计算的快速发展,越来越多的数据需要到网络的边缘侧进行存储、处理和分析,边缘的设备和应用呈爆发式增长。如何高效的管理边缘侧的资源和应用是业界面临的一个主要问题。当前,采V $ $ & N X用云原生的方法,将云计算的能力下沉到边缘并在云端做统一调度、管控的云边端一体化架构得到了业界的广泛认可。

2020 年 5 月,阿里巴巴开源首个 Kubernetes 无侵入的边缘计算云原生项目OpenYurt,并于同年 9 月份进入 CNCF SandBox。OpenYurt 针对边缘场景中网络不稳定、云边运维困难等问题,对原生 Kubernetes 无侵入地增强,重点提供了边缘节点自治、云边运维通道、边缘单元化的能力。

如图w A + ~ ` ] $ 1 所示,本文通过在云端部署 K& D 7 a n , F Xubernetes 集群的控制面9 I Z * f $ ,并将莓派接入集群来搭建云管边场景。基于这个环境演示 OpenYurt 的核心能力,带大家快速上手 OpenYurt。

OpenYurt 入门 - 在树莓派上玩转 OpenYurt
图 1 原生 Kubernete/ % 0 D y C G ys 集群

环境准备

1y M / y d. 基c 5 Y础环境介绍

在云端,购买 ENS 节点(ENS 节点具有公网 IP,方便通过公网对外暴露服务)来部署原生 K8s 集群的管控组O ~ ( - Z件。其中系统采用 ubunk z E : / O ` 5tu18.04、hostname 为 master-node、docker 版本为 19.03.5。

在边缘,如图 2 所示,将莓派 4 与本地的路由器连接,组成边缘私网环境,路由器通过 4G 网卡访问互联网。其中树莓派 4 预装系统为 ubuntu18.04、hostname为 edge-node、dob 3 Pcker 版本为 19.03.5。

OpenYurt 入门 - 在树莓派上玩转 OpenYurt
图 2 边缘环境实体图

2. 原生 K8s 集群搭建

本文演示环境基于社d P B d -区1.16.6版本的K8` - `s集群,并采用社区提供的kubeadm工具来搭建集群,= S : d o 8 n具体操作如下:

  • 在云端节点和树莓派上分别执行如下命令安装 Kubernetes 组件。
curl -s https://mirrors.aliyun.com/kubernetes/apt/doc/apt-key.gpg | sudo apt-key add -
echo "deb https://mirror= X ` $ q gs.aliyun.com/kubernetes/apt/ kubernetes-xenial main" > /etc/apt/sr : G H 1 sop M l  | 0 {urces.list.d/kubernetes.list
sudo apt-get update
sudo apt in: s I dstall -y kubel} ] 9 V D 8 P Z Vet=1.16.6-00 kA h gubeadm=1.16.6-00 kub( - : f L G 8ec9 d O f : A 9 %tl=1.168 ~ n J s.6-00
  • 使用 kubeadm 初始化云端节z W f T } : :点(在云端节点上执行如下A T T K } Q { ]命令),部署过程中采用阿里云的镜像仓库,为了支持树莓派的接入,该仓库的镜像做了 manifest 列表,能够支持 amd64/arm64 两种不同的 CPU 架构
# master-node
kubeadm init --image-repository=registry.cn-hangzhou.aliyuncs.com/edge-kubernet$ q M h 7 @es --kuberne2 w 7 ) $ qtes-version=v1.16.6 --pod-network-cidr=10.244.0.0/16

依据初始化完成之后的提示,拷贝 config 文件到 $HOMy p Z 3E/.kube 中:

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.z Y a & e C # sconf $HOh O @ W SME/.kube/config
  • 树莓派接入云端集群依据第二步中初始化完成以后输出的节点接入信息,在树莓派上执行接入命令。
kubeadmq p x g 1 ` 9 | join 183.195.233.42:6443 --token XXXX \
--disc` r ~ F hovery-token-ca-cert-hash XXXX
  • 添加 cni 配t - : -置(云端管控节点和树莓派都需要配置),本5 C p - 7 , `文搭建的集群使用主机网络。创建 cni 配置文件 /etc/cni/net.d/0-loopback.conf,并将如下内容拷贝到该文件中。
{
"cniVersion": "0.3.0",
"name": "lo",
"type": "loopback"
}
  • 在 master 节点上查看部署效果。
NAME STATUS ROLES AGE VERO - aSION INTER Q N * + !NAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERe O # f i * C dSION CONTAINER-RUNTIME
edge-node^ U j 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 中$ c & n / % CoreDNS 不需要; 3 L O _ *使用),并将 master 节点的 taints 去掉(方便后续部署 OpenYurt 组件)。
kubectl delete deployment coredns -n kube-system
kubectl taint node master-node node-role.kubernetes.R & ! 0 3 kio/master-

原生 K8s 集g F ` 1 B i e群在边缘场景中的, ) 7 E # 7 { ^问题

基于上述环境,我们来测试一下原生 K8s 在云管边架构中对云边运维的支持和A 0 p Z z a G D对云边网络断开时的反应。首先,我们从云端部署一个测试应用 nginx,在 master 节点上执行 kubectl apply -f nginx.yaml,具体的部署 yaml 如下。

注意:nodeSelector 选择 edi c G sge-node 节点,主机网络配置为 true,并配置 pod 的容忍时间为 5s(默认 5min, 此处配置便于演示 pod 驱逐)。

apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
tolm e I lerations:
- key: "node.kubernetes.io/unreachable"
operator: "Exists"
effect: "NoExecute"
tolerationSeconds: 5
- key:/ m ! = U % g v [ "node.kubernetes.io/not-ready"
operator: "f ! c ~ k # : {Exists"
effect: "NoExecute"
tolerationSeconds. E 0 o G ] q: 5
nodeSelector:
kubernetes.io/hostname: edge-node
containers:
- name: nginx
image: nginx
hostNetworko K G e ! t: true

查看部署结果:

root@master-node:~# kubectl get pods -owide
NAME READY STATUS RESTARTS AGE IP NODE NOw * A N : * m RMINATED NODE READINESS GATES
nginx 1/1 Running 0 11s 192.168.0.100 edge-node <none>           <none>

1. 测试i s 5 f W %常用的集群运% u + Y ` A % } zo B $指令,包括 logs、exec、port-forward。

在 maste{ 0 $ - ; O )r 节点上运维边缘节点应用,执行 logs/exe # / X h ` J - ;c/port-forward 等指令,查看结果。

root@master-node:~# kubectl logs nginx
Error from server: Get htt e W &ps://192.168.0.100:1X { z e N k J U *0250/containerLogs/default/nginx/nginx: dial tcp 192.168.0.100:102t ] ~ u50: connect: connection refused
root@master-node:~# kubectl exec -it nginx sh
kubectl exec [POD]% P T [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
Error from sz r P 0 } 9 ierver: error di6 P haling backend: dial tcp 192.16r ( 2 R X i S ]8.0.100:10250: connect: connection refused
root@master-node:~# kube, E S cctl port-forward pod/nginx 8888:80
error: error upgran + ^ m 6 ading connection: err# k , L hor dialing backend: dial tcp 192.168.0.100:10250: connH Z p Eect: connection refused

从执行结果看,原生的k8s在云管边的场景中,无法提供从云端运维边缘应用的能力。这是因为边缘节点部署在用户的私网环境,从云端无法通过边缘节点的 IP 地址直接访问边缘节点。

2. 测试边缘断网时对业@ p I y务的影响

边缘节点与云端管控通过公网连接,经常会出现网络不稳定,云端断连的情况。这里我们将做两个断网相关的测试:

  • 断网 1 分钟->恢复网络

  • 断网 1 分钟->重启边缘节点->恢复网络

观察两个测试过程中节点和 Pod 的状态变化。本文 Demo 中的断网方式是将路由器的公网连接断开。

1)断网 1 分钟-f y v 8 ] y A>恢复网络W ! = #

断开网络,大约 40s 后,节点变成 NotReady(正常节点 10s 钟上报一次心跳,当 4 次没有上报心跳时,管控组件认为节点异常)。

root@master-node:~# kubectl get nodes
NAME STATUS ROLES AGE VERSION
edge-node NotReady( H A e e v @ 5 <none>   5m13s   v1.16.6
masD ` 2 ; ; ~ !ter-C } E {node   Ready      master   6s u x / 4 Ym4s    v1.16.6

继续等待 5s 之后(正常节点变为 Nh n { q ` votReady 之后,5m 才开始驱逐 pod,此处为了测试效果,将 pod 的容忍时间配成了 5s),应用 pod 被驱逐,状态变为 Terminating。

root@master-nom 3 6de:~# kubectl get pods
NAME READY STATUS RJ 1 xESTARTS AGE
nginx 1/1 Terminating 0 3m45s

将网络恢复,观察节点及 pod 变化。

root@master-node:~# kubectl get pods
No resources found in default namespaU 5 h K 1 P ce.

网络恢复后,节点状态变成 ready,业务 pod 被清除,这是因为边缘节点的 Kubelet 获取到业务 Pod 的 Terminating 状态,对业务 Pod 做删除u } / #操作,并返回删除成功,云端也做了相应的清理。至此,业务 Pod 由于云边网络的不稳定而被驱逐,然而在断网期间,边缘节点其实是可以正常工作的。y S b Z j

重新创建应用 nginx,用于下面测试。

root@master-node:~# kubectl get pods -owide
NAMn % M o m $E READY STATUS RESTARTS AGE IP NODE NOMINATE[ R * n [ , 0D NODE READINESS GATES
nginx 1/1 Running 0 4s 192.168.0.100 edge-node &lt { n . 6 ` At;none>           </ b | & i 7 X;none>

2)断网 1 分钟->重启边缘节点->恢复U q 5 g ~ d网络

接下来,我们测试在断网的C s ( % 7情况下,边缘节点的重启对业务的影响。断网O 8 } f 0 8 Q 1 分钟之后,Node 和 Pod 状态同上X X W 2 / r r面测试结果,Node 变为 NotReadyW i 8 - a ` b X C,Pd w ; } ^od 的状态变为 Terminating。此时,切换到私有网络环境,登录到树莓派上,将树莓派重启,重启完成后等待大f ^ P约 1 分钟,观察重启前后节点上的容器列表。

重启前边缘节点容器列表(此时云边端开,虽然在云端获取的 pod 是 Terminating 状态,但是边缘并未 Watch 到 Terminating 的操作,所以边缘的应用还正常运行)。

root@edge-node:~# dockX $ . ` a S w ~ ber ps
CONn f x T wTAIN8 Z m w [ 2 V fER ID IMA, [ Z K E D d GGE COMMAND CREATED STATUS PORTS NAMES
9671cbf28ca6 e86f991e@ ` T P } ; }5d10 "/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_ngl b 1 W K T uinx_default_efdf11c6-a41c-4b95-8ac8-45e02c9e1f4d_0
698bb024c3db f9ea384ddb34 "/usr/loca] ~ i k X + @ Ml/bin/kube…^ c M l | I" 8 minutes ago Up 8 minutes k8s_kube-proxy_kube-proxy-rjws7_kube-system_51576be4-2b6d-434d-b50b-b88e2d436fef_0
319527 J g00c95be K c ] y u registry.cn-hangzhou.aliyuncs.com/edge-kubernetes/pause:3.1 "/pause" 8 minutes ago UpL ) z 1 K ~ _ S - 8 mA ( f S v ) 7inutes k8s_POD_kube-proxy-rjws7_kube-system_N { Q z p ^ s F n51576be4-2b6d-434d-b50b-b88e2d436fef_0

重启后节点容器列表,断网重启后,kubelet 无法从云端获取 Pod 信息,不会重建 Pod。

root@edge-node:s C p 0 * 6 g N~#T k 0 k v ! & { D docker ps
Ce M V ?O6 B S 5 6 B u @ )NTAINER ID IMAG& 2 O u v 5 x 2E COMMAND CREATED STATUS PORTS NAMES
root@edge-node:~#

从重启前后的对比看,边缘节点在断网重启之后,节点X ! g }上的 Pod 全部无法恢复。这就会导致在云边* O & y b + F断网时,一旦节点重启,应用将无法工作。

将网络恢复,观察节点及 pod 变化,同上面测试结果,网络恢复后,节点变为 Ready,业务 Pod 被清除) S / q

root@master-node:~# kubectl# 8 P z W y A 6 / get nodes
NAME STATUS ROLESx G i j _ & m ~ | AGEE ( N m @ g VERSION
edge-node Ready <none>   11m   v1.16.6
mastD  uer-node   Ready    master   12m   v1.16.6
root@master-node:~# kubectl get pon K C Tds
No resources foundk 0 z # 0 in1 t l default namespace.

接下来,再次部署业务 nginx,测试 Opu - ! ( b tenYurt 集群对云边运维的支持和对云边断y ` l p Z F M _ X网时的反应。

root@master-node:~# kubectv ! - _ Wl get pods -owide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
ngiX L ) % 7 ~ ` ( [nx 1/1 Running 0 12s 192.168.0.100 edge-node <none>           &R a u S ) Clt;none>

原生 K8x y zs 集群一键转换为 Open$ v HYurt 集群

探究了原生 Kubernetes 在云边一体化架构中的不足之后,我们来看下 OpenYu% m ; / 9rt 集群是否能满足这种$ T ; |场景。现在,我们利用 OpenYurt 社区提供的集群转换工具 yurtctl,V T ) W V来将原生 K8s 集群转换成 OpenYq B W Wurt 集群。在 mas( B G + Y 3ter 节点上执行如下命令,该命令指定了组件的镜像以及云端节点,并指定安装云边运维通道 yurt-tunnel。

yurtctl convert --yurt-controller-manager-image=registry.cn-hangzhou.aliyuncs.com/openyurt/yurt-controller-manager:v0.2.1 --yurt-tu? c b ( W b Z @ %nnel-agent-image=registry.cn-hangzhou.aliyuncs.com/openyurt/yurt-tunnm u  c r pel-agent:v0.2.1 --yurt-tunnel-serv ~ c zer-image=registry.cn-hangzhou.aliyuncs.com/openyurt/yurt-tunnel-server:v0.2.1 --yurtctl-servant-image=registry.cn-hangzh` P ^ y z mou.aliK ~ 3 Qyuncs.cs : }om/openyur z j brt/yurtctl-servant:v0.2.1 --yurthub-imag} . F 1 .e=registry.cn-ha@ - / : r } y nng} i kzhou.aliyuncs.com/openyurt/yurthw P & 9 F Qub:v0./ 9  7 z h * V2.1 --cloud-nodes=master-node --deploy-yurttunneO 6 6 q Ll

转换大概需要 2min,转换: - A G完成之后,观察业务 pod 的状态,可以看到转换过程中对业务 pod 无影响(也可以在转换过程中在新的终端使用 kubectl get pod -w 观察业务 pod 的状态)。

root@master-node:~# kubectl3 u { _ i get pods -owide
NAME READY STATUS Rl ~ 5 Y L C h E SESTARTS AGE IP NODE NOMINATED NODE READIE  K o R d 6NESS GATES
ngib c N 4 6 l Cnx 1/1 Running 0 2m4s 192.168.0.100 edge-node <nog E nne>           <none>

执行完成之后的组件分布如图 3 所示,其中橙色部分是 OpenYurt. + o ` d 相关的组件,蓝色部分是原生 K8s 组件。相应地,我们观k U | S F f a察云端节点和边缘节点的 pod。

OpenYurt 入门 - 在树莓派上玩转 OpenYurt
图 3 Opei S M M + h B bnYurt 集群组件分布图

云端节点 yurt 相关的 pod:yurt-controller-manager 和 yurt-tunnew 5 R z f - jl-server。

root@master-node:~# kubectl get pods --all-nl 0 ^ D wamespaces -owide | grep master | grep yu?  7 P - rt
kube-system yurt-controllC t [er-manager-7d9db5bfM S f  B 0 G x =85-6542h 1/1 Runnm I $ b 5 sing 0 103s 183.195.233.42 master-n@ $ J + 4 1ode <none>           <none>
kube-system   yurt-tunnel-server-65784dfdf-pl5bn         1/1     Running   0          103s    183.195.233.42   masQ w w E [ter-node   <none>           <none&gv i ? U E |t;

边缘节点新增 yurt 相关的 pod: yurtG $ n L X I x-hub(static pod)和 yurt-tunnel-agent。

root@master-node:~# kubectl get pods_ t h D V --all-namespacB @ a * A 1 5 % des -owide | grep edge | grep yurt
kube-system yurt-hub$ l % 9 # + A-edM r | E cge-node 1/1 Runnin& v 6 f _ Z k E tg 0 117s 192.168.0.100 edge-node <none>           <none>
kube-t ; * Psystem   yurt-tunnel-agent-7l8nv                    1/1     Running   0          2m      192.168.0.1$ T J - 6 m @00    edge-node 4 = h g }     <none>           <none&A ! V - N w S Hgt;

测试 OpenYurt 集群在边缘场景中的能力

1. 测试 logs/exec/port-forward 等运维指令,查看结果

root@master-node:~# kubectl logs nginx
/docker-entrypoint.sh: /docz 5 E L ; kker-entrypoint.db [ p E/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypox & 6 r @ j @int.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.z ( 6 Y D g C k Iconf
10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
/doc6 U P eker-entrG T 1 Typoint.sh: Lh h _ ^aunching /docker-e2 x 0 z 2 t $ k 7ntrypoint.d/20-envsubsM j h 4 g c Wt-on-templates.sh
/docker-entrypoint.s$ J % * oh: ConfI u ;  . s *ig4 0 0 ^ k % . Kuration complete; ready for start up
root@master-node:~# kubectl exec -it nginx sP + B o j = l Fh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl e% U o L 7 K , |xecS  e A i 6 [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 vary I } s
# exit
root@master-node:~# kubectl port-forward pod/nginx 8888:80
Forwarding from 127.0.0.1:8888 -> 80
Handling c5 G +onnection for 8888

测试 port-forward 时? / r 0 _ h S,在 master 节点上执行 curl 127.0.0.1:8888,可以访问 nginx 服务。

从演示结果看,OpenYurt 能够很好地支持常用的云边运维指令。

2. 测试边缘断网时对业务的影响

同样我们重复原生 K8s 中断网的两个测试,在测试之前我们先为边缘节点 edge-node 开启自治。在 OpenYurt 集群中,边缘节点的自治是通过一个 annotation 来标识的。

root@mastej S } ` } a 5 k jr-node:~# kube# j ? Y _ctl annotate node edge-node node.beta.alibabacloud.com/autonomy=true
node/edge-node annotated

1)断网 1 分钟->网络恢复

同样,将路由器公网断开,观察 Node 和 Pod 的状态。大约过了 40s,节点的状态变成 N[ J h : iotReadK [ /y,而大约过 1$ S 5 p z = (min 以后,Pod 的状态一直是 Running,并不会被驱逐。

root@mE # *aster-node:~# kubectl get nodes
NAMU u } E t AE STATUS ROLES AGEr p H v ( ( 2 VERSION
edge-node NotReady <none>   24m   v1.16.6
master-nodev 8 q f   Ready      master   25m   v1.16.6
root@master-node:~# kubectl get pods
NAME    READY   STATUe r R k uS    RESTARTS   AG$ M XE
nginx   1/1     Running   0          5m7s

恢复网络,观察 Node 和 Pod 的状态,Nodeb D 3 状态变为 Ready,Pod 保持 Running。可见云边网络不稳定时,对边缘节点的业务 Pod 无影响。

root@master-node:~# kubectl get nod1 3 : 4 7es
NAME STATUS ROL` V O % I ( x _ GES AGE VERSION
edge-node Ready <none>   25m   v1.16.6
master-node   Ready    master   26m   v1.j : M C =16.6
root@mat R C + $ % D Tster-node:~# kubectl get pods
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          6m30s

2)断网 1 分钟->重启边缘节点->恢复网络

接下来,我们测试在断网的情况下,边缘节点的重启对业务的影响。断网 1 分钟之后,Node 和 Pod 状态同上面测试结果,Node 变为 NotReM C j % ? b P X Yady,Pod 保持 Running{ O ; a c 。同样,我们登( d 7 [录到树莓派上,将树莓派重启,观察重启前后节点上的容器列表。

重启前边缘节点容器列表:

root@edge-node:~# docker ps
COw ) ? 7 *NTAINER ID IMAGE COMMANDW  r 5 CREATED STATUS PORTS NAMES
38727ec9270c 70bf6668c7eb "yurthub --v=2 --ser…" 7 minutes ago Up 7 minutes k8s_yurt-hub_yurt-hub-edge-node_kuB P , v 0 1  wbe-system_d75d12+ 5 P 9 5 O h2e752b90d436a71af44c0a53be_0
c403ace1d4ff registry.cn-hangzhou.aliyuncs.com/edge-kubernetes/pause:3.1 "/:  X z S v 8 : Kpause" 7 minutes ago Up 7 minuteh  1 %s k8s_POD_yurt-hub-edge-node_kube-system_d/ : 7 % x K75d122e752b90d436a71af44c0a5& y * $ J 9 6  ]3be_0
de0d693e9e74 473ae979be68 "yurt-tunnel-agent -…" 7 min_  k X  m C rutes ago Up 7 minutes k8s_yurt-tunnel-agent_yurt-tunnel-agent-7l8nv_kube-system_75? 5 [ E , vd28494-f577-43fa-9cac-6 T T . T X a w :681a1215498_0
aa 4 l0763f143f74 registry.cn-hangzhou.aliyuncs.com/edge-kubernetes/pause:3.1 "/pause" 7 minutes ago Up 7 minutes k8s_POD_yurt-tup Z M ? f /nnel-agent-7l8nv_kube-system_75d28494-f577-43fa-9cac-6681a1215498_0
80c247714402 e86f991e5d10 "/docker-entrypoint.…" 7 minutes aU n z j 6go Up 7 minutes k8s_nginx_nginx_default_b45baaac-eebc-466b-9199-I : ; t U 22ca5c1ede9fd_0
01f7770cb0f7 registry.cn-hanU 1 Xgzhou.aliyuncs.com/edge-( y 2 o lkubernetes/pause:3.1 "/pause" 7 minute4 ` a : ; ! x R hs ago Up 7 minutes k8s_P8 b @ Q C *OD_nginx_default_b45baaac-eebc-466b-9199-2ca5c1ede9Q + E O H Qfd_0
7e65f83090f6 f9ea384ddb34 "/usr/local/bin/kube…" 17 minutes ago Up 17 minutes k8s_kube-proxy_kube-proxy-rjws7_kube-system_o R w51G % 0 i576be4-2b6d-434d-b50b-c d % $ p Q T ab88e2d436fef_1
c1ed142fc75b registry.cn-hangzhou.aliyuncs.com/edge-kubernetes/pa7 Z z J [ Q duse:3.1 "/pause" 17 minutes ago Up 17 minuts A 7es k8s_POD_kube-proxy-rjws7_kube-system_5152 z G76be4-2b6d-434d-b50b-b88e2d4K g R  & 8 136fef_1

重启后边缘节点容器列表:

root@edge-node:~# docker ps
CONTAINER ID= _ V h n $ m % IMAGE COMMAND CREATED STATUS PORTS NAMES
0c66b87066a0 473ae979be68 "yurt-tunnel-agent -…" 12 seconds ago Up 11 seconds k8s_yl 7 J W d R = & 2urt-tunneO h * y q P Fl-agent_yurt-tunnel-agent-7l8nv_kube-system_75d28494-f577-43fa-9cac-6681f ~ n B Ea1215498_2
a4fb3w 6 se4e8c8f e86f991e9 & q c q c c Z `5d10 "/2 ] 3   U ^ | Edocker-ent. i [ ! H /rypoint.` k ] ( 9 x ( X {…" 58 seconds ago Up 56 seconds k8s_nginx_ngin5 W % Nx_default_b45baaac-eebc-466b-9199-2ca5c1ede9fd_1
fce730d64b32 f9ea384ddb34 "/usr/local/bin/kube…" 58 seconds ago Up 57 seconds k8s_kubeK e Y J % # M B @-proxy_kub6 I 7 m o ? Le-proxy-rjws7_kube-system_51! , ^ 2 R P W 0 J576be4-2b6d-434dt } U k _ ~-b50b-b88e2d436fef_2
c78166e6 & h * 2a563f registry.cn-hangzhou.aliyuncs.coJ 0 &m/edge-kubernetes/pause:3.1 "/pm A c J J _ause" 59 seconds ago Up 57 seconds k8s_POD_yurt-tunnel-agE 7 ; &ent-7l8nv_ku$ * ]be-system_75d28494-y / c j 9 of577-43fa-9cac-66z  p | 8 Z O ) ,81a1215498_1
7+ % R i 099ad14bcd3b registrj B @ Ly.cn-hangzhou.aliyu| s Yncs.com/edge-kuberneQ A & 7 | P @tes/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-kubes k Z B d j prnetes/pause:3.1 "/pause" 59 secv . ! n Iondv B ! ,s ago Up 58 se+ d E W Z j _conds k8s_POD_kube-proxy-rjws7_kube-system_51576be4-2b6d-434d-b50b-b8+ 4 l B [ T8e2d436fef_2
04da705e4120 70bf6668c7eb "yurt! X I U ~ Mhub --v=2 --ser…" About a minute ago Up About a minute k8s_yurt-hub_yurt-hub-edge-node_kubeu | 3-system_d75dm 7 h122e752b90d436a{ & 9 g l + W71af44c0a53be4 7 j = V 4_1
260057d935ee registry.cn-hangzhou.aliyuncs.com/edX K , P ?ge-kubernetes/pause:3.1 "/pause" Abo_ m K % Y n ,ut a minute ago Up About a minutej n J M k8s_POD_yurt-hub-edge-node_kube-system_d75d122e752b90d436a71af44c0a53be_1

从重启前后的对比看,边缘节点在断网重启之后,节点上的 pod 能正常拉起,OpenYurt 的节点自治能力可以在断网下保证业务的稳定运行。

恢复网络,节点 Ready,观察业务 pod 的状态,网络恢复后,业务 pod 状态保持 running,有一次重启记录,符合预期。

rW : G ! _ 1 ! uoot@master-node:~# kubectl get5 k ! J ] V O H t pods -owide) 0 - M
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 的能j N 5 3力将 OpenYurt 集群,转换为原生 K8s 集群。同样,可以观察转换过程中对现有业务不会q z 6 M ? L E *有影响。

yurtctl revert --yk x ~ K I N M r Purtctl-servant-image=registry.cn-hangzhou.aliyuncs.com/openyurt/yurtctl-servant:v0.2.1

OpenYurt 作为阿里首个边缘云原生开源项目,基于商业化产品 ACK@Edge,在f & c ( = :集团内部经历了长时间的S R _ ( -打磨。已经应用在 CD} q h s . ZN、IoT、盒马、ENS、菜鸟物等众多场景。针对边缘场景,该项目坚持保持原f U U ^ D 4 q S _生 K8s 的特性,以 Addon 的形式提供了边缘2 ? J D C i节点自治、云边端一体化运维通道等能力。最近在社区同学的一起努力下又开源了边缘单元化管理能力,同时后续还会继续开源更多的边缘管理能力,欢迎大家积极参与贡献。