大赛介绍
2022 第三届云原生编程应战赛，是由阿里云、Intel 主办，云原生运用平台、天池联合承办的云原生顶级品牌赛事。
本届大赛将继续深度探究服务网格、边际容器、Serverless 三大抢手技术领域，为热爱技术的年轻人供给一个应战世界级技术问题的舞台，期望用技术为全社会发明更大价值。咱们从速报名参赛吧！
丰厚奖励等你来报名！
- 分割510,000 元现金大奖
- 三大抢手赛道恣意选择
- 邀请小伙伴报名兑换精美礼品
- 完结 Serverless 场景体会领阿里云背包
赛题背景
ACK@Edge 是阿里云容器服务针对边际核算场景推出的云边一体化云原生处理方案，主打“云端托管、边际自治”的产品理念，为用户供给云边多维度协同，海量异构算力管理，边际 AI 套件，可观测，轻量化，弹性等能力。现已广泛运用于边际云、物联网等典型边际核算场景，掩盖交通、动力、新零售、才智驾驭、CDN 等多个行业。一起，ACK@Edge 依托 CNCF OpenYurt 强大的社区生态，积极参与并协同社区继续打磨和完善设备孪生、云边协同网络、高可用等领先技术能力。
为了处理在边际核算场景下云边网络通信断连时，确保边际侧节点上事务能够自愈，OpenYurt 在边际侧组件和 APIServer 之间新增 YurtHub 组件。边际侧的组件（kubelet,kube-proxy..）对 apiserver 的恳求，会首要经过 YurtHub 组件的然后再转发给 apiserver，YurtHub 会将 apiserver 回来的数据缓存到本地。当云边网络断开时，Yurthub 还能将本地缓存的数据回来给边际侧组件。
可是在实践过程中咱们发现，在云边协同的边际场景架构体系下，有着很多的轻量级的设备，这些设备的配置相对比较低，下降边际侧组件的资源占用率，为设备上的事务腾出更多的资源，已经成为了必需求处理的问题。
本赛题期望完成一个边际侧的 edge-proxy 组件，担任转发边际侧组件例如 kubelet,kube-proxy 的恳求，一起能够将云上 apiserver 回来的数据进行过滤，一起在回来给恳求端时能够缓存到本地，并尽或许的下降 cpu，内存等资源占用率。
赛题解析
在 Kubernetes 体系中，list/watch 机制首要处理组件间实时数据的异步同步。其中 List 恳求是普通的 HTTP GET 恳求，一次 List 恳求将回来恳求类型资源的全量数据。而 watch 恳求是依据 HTTP 协议的 chunked 机制完成的长衔接，用于实时告诉恳求资源的数据改变。相关的介绍能够参考：
kubernetes.io/docs/refere…
List/Watch 机制是 Kubernetes 中完成集群操控模块最核心的规划之一，它选用一致的异步音讯处理机制，确保了音讯的实时性、可靠性、顺序性和功用等，为声明式风格的 API 奠定了杰出的根底。Informer 模块是 Kubernetes 中的根底组件，担任各组件与 Apiserver 的资源与事情同步。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 与云上的 APIServer 网络断开， 此时主机发送了重启， 按照 list-watch 的逻辑， kubelet 要首要经过 APIServer list 全量属于本主机上的 pod 数据， 然后再经过 CRI 接口对 POD 进行重建，因为云边网络断开，kubelet 无法经过 list 机制获取本主机上的 pod 数据，自然无法对 pod 进行重建，导致事务无法正常运转。
处理方案
因而咱们需求在边际侧新增一个组件 edge-proxy, edge-proxy 组件包括能力首要有边际组件(如 kubelet 等)的 pods, configmaps 的 list/watch 恳求的转发，以及对 kube-apiserver 回来 response 的过滤和缓存处理。总结一句话便是完成一个带有数据过滤和缓存功用的 7 层反向署理。不过这里的 7 层恳求是 Kubernetes 体系中定制的 List/Watch 恳求。一起 edge-proxy 在离线状态下还能回来 kubelet ,kube-proxy 这些边际侧组件 list-watch 的数据，充任离线的 APIServer。
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 机制的实时数据推送，能够考虑选用相似流数据的处理方案来处理。
怎么拿到好成果
终究成果由数据正确性和处理功率来决定，主张在确保正确性的根底上，能够各类优化手段(如乐观锁等)来提高处理功率。等待各位选手都取得自己满足的成果。
点击这里，立即报名！
