【视频】边缘容器赛题解析 | 学习笔记

开发者学堂课程【2022云原生编程挑战赛培训课程：【视频】边缘容器赛题解析】学习笔记，与课程紧密连接，让用户快速学习知识。

课程地址：https://developer.aliyun.com/learning/course/1049/detail/15337

【视频】边缘容器赛题解析

内容介绍：

一、赛题背景

二、赛题解析

三、评分和排名规则

四、参赛方式

一、赛题背景

1.赛题背景

今天赛题的题目是针对云原生边原计算场景的ACK@Edge高效的边缘自治方案。

万物智联时代的到来，越来越多的企业希望在靠近端测或者是数据源头的地方，部署边缘集团的业务，以此获得更快的响应时间，更低的延迟，同时也减少更多的云与边之间的网络流量，另外，将AR的能力下沉到边缘侧，也使得边缘具有更强的智能决策的能力。但是，在边缘计算场景下，随着智能设备的剧增以及业务下沉诉求增多，使得边缘计算在规模以及业务复杂度出现不断的增长，传统的运维手段，难以满足边缘计算场景的日益复杂的需求，同时，在云与边场景下也缺少统一的交付运维管控标准。在边缘计算场景下，异构资源的特性非常明显，比如在边缘里有着不同的硬件架构，有x86、ARM，有不同的硬件规格，有服务器、刀片、小盒子，以及不同的通信协议，如何在种场景下基于异构资源、网络规模等差异化的种场景下，提供一种统一标准的服务，带来一个非常大的挑战。

2.云边一体的价值

实际上边缘计算和云计算它们之间并不是互相割裂或互相替代的一种关系，云计算更加擅长需要将海量和可扩展的种存储的能力，比较适合非实时并且周期相对比较长的数据处理或分析，比如大数据、在线业务等，边缘计算是脱胎于云计算的，擅长在局部短周期数据的实时处理和分析。

通过图中可以了解到，云计算和边缘计算，只有将它们之间互相协同，二者之间紧密结合，才能更好的满足各种长久的需求，如何将边缘计算和云计算进行有机的统一结合，需要一套技术架构或体系作为支撑，

3.云原生

云业生最早的概念是在2013年被提出的，经过几年的发展，尤其是2015年来谷歌牵头成立CNCF以来，云原生的技术开始进入公共的视线，并且不断演变成包括DevOps、持续交付、微服务、容器、基础设施等一系列的基础实践和方法论的结合。使用云原生的技术，可以在任何的基础设施之上提供和云上一致的功能和体验，同时也可以实现云边端一体化的应用和分发，保证运维切面的统一性。在云生领域最典型的代表技术是Kubernetes。

4.Kubernetes架构

从左图中可以看到Kubernetes是一典型的控制面和计算面的两层架构。在控制面层面有几个核心的组件的，首先是etcd，保存整个Kubernetes里面的核心数据，对应的核心数据，第二就是API Server，API Server是为整个Kubernetes的集群对外提供rest API服务。比如通过rest API，对Kubernetes集群里面的各种资源进行操作，比如pod资源，Node的资源，Secret资源进行增删改查list、watch等各种操作。另外的一组件是controller manager的组件，controller manager的组件可以认为是Kubernetes资源的控制器，另一个是scheduler，scheduler核心的作用，是将用户创建的pod经过一系列的算法，在整个Kubernetes集群里面找到合适的node调度上去。计算层面主要是以Kubelet，在每一个计算节点上会部署一个Kubelet图里面可以看到核心的组件就是Kubelet和Kube-proxy，

如右图Kubelet主要是负责在本之际整个pod生命周期的管理，Kube-proxy主要是对于整个网络层面的转发、负载均衡，比如service层面的处理，在整Kubernetes集群中所有的最work node的资源里，最低的调度单元是pod的，一个pod里面可以包含多容器，这是整个Kubernetes的架构。

阿里云边缘容器服务ACK@Edge，ACK@Edge是阿云容器服务针对于边缘计算场景推出的云边一体化云原生的解决方案，它是基于Kubernetes基础之上，采用非嵌入式的方式，对Kubernetes在边缘场景的能力做增强，主打云端托管、边缘自制的产品理念，为用户提供云边多维度的系统，海量易构算异管理、边缘AR套件、可观测、轻量化、弹性等能力。现在已经广泛应于像边缘云、物联网等典型的边缘计算场景，也覆盖交通、能源、新零售，智慧驾驶、CDN等多行业，ACK@Edge依托于CNCF open yurt开源社区强大的社区生态，也积极参与并协同社区打磨和完善设备孪生、云边协同、高可用等领先的技术能力。这是整个ACK@Edge阿里云边缘中心服务ACK@Edge的产品。ACK@Edge在整个Kubernetes基础能力之上，也衍生出像针对于边缘计算场景的一些额外能力，像边缘自治，边缘单元，单元流量化，单元部署等具有典型边缘计算场景的一些业务形态。

5.OpenYurt架构

OpenYurt社区和ACK@Edge关系。首先，ACK@Edge产品的内核代码也是使用OpenYurt，图是OpenYurt整体架构，为了解决在边缘计算场景下云边网络通信断联时，保证边缘侧节点业务上可以自愈，OpenYurt的在边缘侧组件和API server之间新增了一个YurtHub组件，在边缘侧的组件，像蓝色的部分Kubelet、KubeProxy、Flannel或者其他一些。如果对API server进行请求，首先请求YurtHub组件，再由YurtHub转发给API server，同时YurtHub将API server返回过来的数据缓存到本地。如Kubelet去请求API server的所有的本主机上的pod数据执行list请求，请求会先经过YurtHub，YurtHub会转而转发给API server，API server返回给YurtHub的pod数据，YurtHub做了两件事，一件是将数据返回给请求的Kubelet，另一件是将pod数据缓存到本地。好处是当云边网络断开时，在edge侧和cloud侧网络断开，YurtHub由于缓存了云上的一些数据，同样在Kubelet请求时，可以模拟API server将缓存的数据返回给Kubelet，就做到了在断网的情况下，边缘侧的主机和业务还能做到自治的能力。实践过程中发现在云边协同的边缘计算架构之下，有着大量的轻量化设备，设备的配置比较低，CPU和内存相对配置会低，使得降低边缘侧组件的资源占用率，尤其是像YurtHub这些核心的组件的资源占用率，为设备上的业务腾出更多的资源，已经成为必须要解决的问题。这也是本赛题的核心诉求。

二、赛题解析

1.Kubernetes list-watch 机制

在Kubernetes系统中，List和watch机制主要解决了组件间实时数据的同步问题。其中list的请求是普通的HTTP请求，一次list请求将返回请求类型资源的全量数据，而Watch请求是基于HTTP协议的机制实现超链接，用于实时通知请求资源的数据变化。list-wash机制是Kubernetes中实现集群控制模块最核心的设计之一，采用统一的异步消息处理机制，保证了消息的实时性、可靠性、顺序性和性能等。为声明式风格的API奠定了良好的基础。其中，整个Informer模块是Kubernetes中的基础组件，负责各组件与API server资源与事件的同步。基本的原理是如果组件要监听一些资源的变化，比如scheduler组件想监听所有pod资源的变化，首先会list全量的pod数据list完后会通过watch的机制将云上变化的pod数据去不断的去watch下来，缓存到本机内存里面。

上述的list watch机制，是比较适合于在网络通信质量比较好的数据中心的运行，因为Kubernetes在设计之初，是脱胎于传统的云计算数据中心中，要求网络质量比较好，但是在云边场景，云边网络连接不可靠的情况下这种机制会带来非常大的挑战，以Kubelet为例，若Kubelet部署在边缘侧，云上的API Server部署在云上。云与边之间是弱网的情况下，假设Kubelet与云上的APS server网络连接断开，此时主机又发生了重启，按照整list-watch的逻辑Kubelet首先要通过API server进行list的全量属于本主机上pod数据。再通过CI接口对pod进行重建，但是，由于云边网络断开，Kubelet无法通过list的机制获得全量的本主机上的pod数据，自也无法对pod进行重建，导致业务无法正常运行。这是Kubernetes在云边场景下所面临的一很核心的一挑战

2.解决方案

本赛题希望实现边缘测一个叫edge-proxy的组件，就类似于edge Hub，主要负责转发边缘侧的组件，例如Kubelet、Kube-Proxy请求，同时能将云上API server返回的数据进行过滤，在返回给请求端时，可以将数据缓存在本地。在整个过程中，也要尽量的降低CPU内存等资源的占用率，edge-proxy的组件，主要包含的能力有为边缘侧的组件，像Kubelet、pod、list-Watch请求的转发，以及对API server返回的response数据进行过滤和缓存的处理，edge-proxy就是实现带有数据过滤和缓存功能的七层反应代理。七层请求是Kubernetes系统中定制的list-watch请求，edge-proxy在离线的状态下能返回给Kubelet数据来充当离线的API server。

关于七层请求的代理转发，如果云边网络重新正常时，请求需要转发到云端的API server，有云端的API server返回真正的数据，而当云边网络断开的时候。List请求则需要返回本地的缓存数据，由edge-proxy来充当API server的角色，Kube API server返回response的过滤和缓存处理的逻辑，首先是返回给请求端的数据应该是过滤完成的，而缓存和过滤的处理的先顺序是并没有要求的，选手可以根据自身需求来决定。需要注意的是list watch请求的response的数据不太一样，因为list的请求的response中可以一次性读取全量的数据，但watch请求属于云端的实时推送，属于长链接，当云端有数据变化时，才能从response中读取云端推送过来的变化数据。不管是list的还是watch请求，edge-proxy都需要返回给请求方过滤好以后的数据。同时针对大规模response数据的过滤换缓的功能，edge-proxy要尽量的做到轻量化，降低CPU内存的使用率，来为边缘测的些业务腾挪出更多的资源

3.程序要求

例举edge-proxy的一些要求，首先可以简单的认为edge-proxy可以为Kubelet等边缘的组件或者业务提供基于HTTP的list-watch的能力，第二点要支持pod的或者configmap资源对象的转发和缓存。为了简化开发，只只要求edge-proxy支持pod或者是configmap资源的转发和缓存。第三点是edge-proxy的数据缓存能力，edge-proxy转发边缘侧组件的请求给云端的API server，并将API server返回来的数据，一方面返回给边缘侧的组件，另一方面要返回的数据缓存到本地。第四点是需要支持过滤的功能，需要对特定的pod或者是configmap进行过滤，要求带有skip-的前缀的pod或者configmap进行过滤，比如Kubelet请求云上所有的pod数据，100个数据里面有20个带有skip-杠前缀的podname带有skip-前缀的pod，edge-proxy需要对这些pod进行过滤，不会返回给kubelet，最后一点，在设计整个edge-proxy的过程中，要尽量做到资源占用率低。资源占用率的有两指标，一是内存，一是CPU

三、评分和排名规则

评测环境是运行在Kubernetes集群的1.20.11版本，评测项目是分为四评测，第一评测项目是功能性评测。第二是过滤性评测，第三是一致性评测，最后是资源占用率的评测、整评分标准是在评测流程中，参赛选手每一次提交的评测，评测程序都会根据评测指标，根据每个评测指标进行打分，记录所有的评测指标的总和，最终上报成绩，分数越高排名越靠前。

功能性评测

参赛选手提交评测后，系统会在Kubernetes集群里面去创建一个pod，pod包含两容器，一是参赛队伍提供的edge-proxy的容器，也就是图中橙色的部分，另一是官方提供的评测程序。评测程序会评测以下几种资源，首先是pod资源的list，评测程序启动后，会多次执行list pod的请求，每次测试用率都会比较edge-proxy返回的数据和实际的pod数据是否一致，并取得一致的百分比。若实际pod数据有100个，测试的反馈数据为80个，得分为80除100乘100。计算所有的测试的平均值为本轮测试的分数a。第二点，是pod资源的watch，评测程序也会创建一组pod，并对pod进行大量的patch操作，以label为例，会加入不同的label，同时会使用informal机制，对pod进行watch，最终watch成功的pod数目a与总的一组数据B计算得分，A除以B乘以百。第三点和第四点，是对于configmap的list和watch，会计算它的分数，最终记录所有的分数总和为功能性评测的最终得分

过滤性评测

参赛选手提交评测后，系统会创建一个pod。Pod里面会包含两个容器，跟上一个评测是一样的。一个是edge-proxy的参赛选手业务，另一个是官方提供的测评程序，整测评程序会对pod资源进行过滤测试，以及对configmap的资源行过滤测试。edge-proxy需要支持对特定pod资源进行filter功能。以pod为例，当客户端向edge-proxy发送list pod请求时，edge-proxy需要过滤掉name前缀为skip-的pod，评测程序会首先向集群中写入一定数量的pod，其中有的pod name会带有skip-的前缀，评测程序会通过edge-proxy发送list请求，记录返回的pod数量与name前缀不是skip-的pod数量的百分比，举例，若写入总的pod数量为100，其中name前缀skip-的pod数量是40，通过edge-proxy返回的pod的数量记录为A，最终得分是a除以100减40乘以100，记录它的百分比。同样对于configmap资源的过滤也是类似的测评方式，最终记录两种的得分之和为过滤性评测的最终得分。

一致性评测

官方会启动一个pod，pod里面包括两容器，第一个容器是edge-proxy，第二个容器是官方提供的评测程序，评测程序会首先向API Server里面创建一定数量的pod和configmap数据，云上的API Server里面会对等数量的pod和configmap，数据创建完后，评测程序会让edge-proxy的容器禁止访问API Server，来模拟网络断开情况下。在网络断开以后，评测程序一方面list命令直接请求API Server获取pod和configmap的数据，另一方面edge-proxy服务执行list请求，请求pod和configmap数据，评测程序期望a和B的数据完全一致。评测程序会根据一致的数量和总的数量做百分比来记录分数。

资源占有率评测

参赛选手提交评测以后，评测程序会通过edge-proxy、list大量的pod和configmap的数据对pod进行压测，评测程序会通过go tool pprof对edge-proxy进行CPU和内存的使用率的计算，使用率越低，得分会越高

四、参赛方式

首先，在阿里云天池里面找到云原生编程挑战赛，进入到边缘计算赛题进行报名参加，另外官方提供了edge-proxy框架代码，可以fork框架代码到自己的仓库里面实现自己的逻辑。edge-proxy里面已经提供了make cloud的命令，可以为参赛选手直接提供make build和make release的操作，提供构建二进制以及构建镜像的服务，里面有read mi有完善的说明，最终只需要将构建出来的镜像push到自己的镜像仓库里面就可以。

同时每个测评程序会有一个日志保文件，日志文件只保存一天，如何评测，首先，可以在自己的本开发机上去安装docker，使用make build的命令将构建出来的镜像push到阿里云的镜像仓库里面。可以去开通阿里云的镜像商库，最终将构建出来的镜像提交给评测程序，只需要在评测程序里面，在提交结果里面提交自己的镜像仓库的地址以及用户名密码即可，一旦提交以后，就会触发后端的评测程序，对参赛选手的提交的镜像进行评测。