第三届云原生编程应战赛是由阿里云、Intel 主办，云原生运用平台、天池联合承办的云原生顶级赛事。自 2015 年开始，大赛现已成功举办了七届，共吸引了超越 36000 支队伍，掩盖 10 余个国家和地区，为全球酷爱技能的年轻人供给了一个探究云原生技能、应战难题的舞台。
在云原生实践不断深化的过程中咱们发现，随着边际设备和边际事务的规划增加，以及事务创新带来的频频改变，在云边协同的边际场景架构体系下，“云边协同”正在面对巨大的管理功率和成本应战。
作为本次大赛三大热门技能领域之一，“边际容器”赛道的主张就希望在这样的布景下，经过集结重视、酷爱云原生的开发者的智慧、技能和能量，探究研究如安在云边协同的边际场景架构体系下，下降边际侧组件的资源占用率，完成一个高效的边际自治计划。
现在，云原生编程应战赛“边际容器赛题”现已吹响集结号，全面敞开报名，等待有才能、有魄力、有生机的开发者们前来应战！
参与边际容器赛道应战，瓜分 170,000 元现金奖赏
本次大赛面向全球敞开，大赛分为初赛和决赛，各赛道初赛 TOP6 战队入围决赛辩论。最终排即将根据初赛及决赛辩论成果归纳得出。
专属赛道奖赏，周周送不断
除了云原生编程大赛官方奖赏，为了鼓励更多开发者参与边际容器赛道应战，即日起，成功提交赛题任务并在每周排行榜中位列 Top 1 的用户，均将获得云原生边际容器开源平台 OpenYurt 定制随行杯一个！（每人限一次）
明星导师
张杰，阿里云云原生技能专家，CNCF OpenYurt 开源社区核心成员
赛题解析
赛题布景
ACK@Edge 是阿里云容器服务针对边际核算场景推出的云边一体化云原生解决计划，主打“云端保管、边际自治”的产品理念，为用户供给云边多维度协同，海量异构算力管理，边际 AI 套件，可观测，轻量化，弹性等才能。现已广泛运用于边际云、物联网等典型边际核算场景，掩盖交通、能源、新零售、智慧驾驭、CDN 等多个职业。一起，ACK@Edge 依托 CNCF OpenYurt 强壮的社区生态，积极参与并协同社区持续打磨和完善设备孪生、云边协同网络、高可用等抢先技能才能。
为了解决在边际核算场景下云边网络通信断连时，确保边际侧节点上事务能够自愈，OpenYurt 在边际侧组件和 APIServer 之间新增 YurtHub 组件。边际侧的组件（kubelet,kube-proxy..）对 api server 的恳求，会首要经过 YurtHub 组件的然后再转发给 api server，YurtHub 会将 api server 回来的数据缓存到本地。当云边网络断开时，Yurthub 还能将本地缓存的数据回来给边际侧组件。
可是在实践过程中咱们发现，在云边协同的边际场景架构体系下，有着大量的轻量级的设备，这些设备的装备相对比较低，下降边际侧组件的资源占用率，为设备上的事务腾出更多的资源，现已成为了必需求解决的问题。
本赛题希望完成一个边际侧的 edge-proxy 组件，负责转发边际侧组件例如 kubelet,kube-proxy 的恳求，一起能够将云上 api server 回来的数据进行过滤，一起在回来给恳求端时能够缓存到本地，并尽可能的下降 cpu，内存等资源占用率。
赛题解析
在 Kubernetes 体系中，list/watch 机制首要解决组件间实时数据的异步同步。其中 List 恳求是普通的 HTTP GET 恳求，一次 List 恳求将回来恳求类型资源的全量数据。而 watch 恳求是根据 HTTP 协议的 chunked 机制完成的长连接，用于实时告诉恳求资源的数据改变。相关的介绍能够参阅：
kubernetes.io/docs/refere…
List/Watch 机制是 Kubernetes 中完成集群操控模块最核心的设计之一，它选用统一的异步消息处理机制，确保了消息的实时性、可靠性、次序性和性能等，为声明式风格的 API 奠定了良好的基础。Informer 模块是 Kubernetes 中的基础组件，负责各组件与 api server 的资源与事件同步。Kubernetes 中的组件，如果要拜访 Kubernetes 中的 Object，绝大部分情况下会运用 Informer 中的 Lister()办法，而非直接恳求 Kubernetes API。
client-go：
Reflector：reflector 用来 watch 特定的 K8s API 资源。详细的完成是经过 ListAndWatch 的办法，watch 能够是 K8s 内建的资源或者是自定义的资源。当 reflector 经过 watch API 接收到有关新资源实例存在的告诉时，它运用相应的 list API 获取新创建的目标，并将其放入 watchHandler 函数内的 Delta Fifo 行列中。
Informer：informer 从 Delta Fifo 行列中弹出目标。履行此操作的功用是 processLoop。base controller 的作用是保存目标以供以后检索，并调用咱们的操控器将目标传递给它。
Indexer：索引器供给目标的索引功用。典型的索引证例是根据目标标签创建索引。Indexer 能够根据多个索引函数维护索引。Indexer 运用线程安全的数据存储来存储目标及其键。
云边应战
上述 List watch 机制适合在网络通信质量比较好的数据中心内运转， 可是在云边场景，云边网络连接不可靠的情况下带来很大的应战。以 kubelet 为例，若 kubelet 与云上的 api Server 网络断开， 此刻主机发送了重启， 按照 list-watch 的逻辑， kubelet 要首要经过 api Server list 全量归于本主机上的 pod 数据， 然后再经过 CRI 接口对 POD 进行重建，由于云边网络断开，kubelet 无法经过 list 机制获取本主机上的 pod 数据，自然无法对 pod 进行重建，导致事务无法正常运转。
解决计划
因此咱们需求在边际侧新增一个组件 edge-proxy, edge-proxy 组件包括才能首要有边际组件(如 kubelet 等)的 pods, configmaps 的 list/watch 恳求的转发，以及对 kube-api server 回来 response 的过滤和缓存处理。总结一句话便是完成一个带有数据过滤和缓存功用的 7 层反向署理。不过这里的 7 层恳求是 Kubernetes 体系中定制的 List/Watch 恳求。一起 edge-proxy 在离线状态下还能回来 kubelet ,kube-proxy 这些边际侧组件 list-watch 的数据，充当离线的 api Server。
7层恳求的署理转发，如果云边网络通信正常时，恳求需求转发到云端 kube-apiserver。而当云边网络断连时，list 恳求需求回来本地的缓存数据。
kube-apiserver 回来 response 的过滤和缓存处理，首要回来给恳求端的数据应该过滤完成的。而缓存和过滤的处理先后次序并没有要求，选手能够根据自身需求来决议。可是需求注意 List/Watch 恳求的 response 数据不太一样，List 恳求的 response 中能够一次性读取出全量数据，而 Watch 恳求归于云端实时推送，是长连接，当云端有数据改变时，才能从 response 中读取云端推送过来的改变数据。不管是 List，还是 Watch 恳求，edge-proxy 都需求回来给恳求方过滤好之后的数据。
一起针对大规划 response 数据的过滤，缓存，以及回来等功用，怎么高效且实时的处理，将直接影响到处理的功率，以及 edge-proxy 消耗的资源。
解题思路
完成一个带数据过滤和缓存功用的 7 层反向署理：
- 当接收到 List 恳求时，能够考虑直接转发到云端 kube-apiserver。当恳求转发失败时（网络断开），则运用本地缓存数据回来到恳求方。当然需求确保回来数据是契合过滤需求的。
- 针对 http.Response 数据的缓存和回来处理，尽可能完成并行处理，这样减少对回来处理的阻塞，从而可能获得更好的处理功率。
- http.Response 数据的过滤处理主张能够在缓存前履行。当云边网络断连时，从本地缓存回来的数据将不需求进行二次过滤。
- Watch 恳求的 http.Response 数据是 chunked 机制的实时数据推送，能够考虑选用类似流数据的处理计划来解决。
怎么拿到好成果
最终成果由数据正确性和处理功率来决议，主张在确保正确性的基础上，能够各类优化手段(如达观锁等)来提升处理功率。期待各位选手都获得自己满足的成果。
点击此处，立即报名！
