共计 3007 个字符，预计需要花费 8 分钟才能阅读完成。
大赛介绍
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 机制实现的长连贯，用于实时告诉申请资源的数据变动。相干的介绍能够参考：
https://kubernetes.io/docs/re…
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 机制的实时数据推送，能够思考采纳相似流数据的解决计划来解决。
如何拿到好问题
最终问题由数据正确性和解决效率来决定，倡议在保障正确性的根底上，能够各类优化伎俩 (如乐观锁等) 来晋升解决效率。期待各位选手都获得本人称心的问题。
点击这里，立刻报名！
