共计 3181 个字符，预计需要花费 8 分钟才能阅读完成。
本文作者：
李志信 ，OpenYurt Member，Apache dubbo PMC，专一于云原生边缘计算的零碎架构和解决方案
张逸飞 ，OpenYurt Member，浙江大学 SEL 实验室
云原生边缘计算智能开源平台 CNCF OpenYurt 于近期公布了 v1.2 版本。OpenYurt 是业界首个对云原生体系无侵入智能边缘计算平台，具备全方位的“云、边、端一体化”能力，可能疾速实现海量边缘计算业务和异构算力的高效交付、运维及治理。
在 v1.2 版本中，OpenYurt 遵循社区提出的“节点池治理”理念，新增组件 Pool-Coordinaotr，提出了一套针对云边场景的资源、网络、利用、监控等角度的边缘治理计划。本文首先聚焦云边场景下的网络优化问题的解决进行解读，敬请继续关注。
Pool-Coordinator 节点池治理及其对云边网络的优化
组件背景
早在去年年初，社区就提出了“节点池治理”的概念。节点池为 OpenYurt 生态概念，示意集群内一组网络互通的边缘机器节点。在云边协同场景，边缘 IOT 设施与算力往往依赖多台机器节点工作，节点池概念为 OpenYurt 生态在边缘算力的管控粒度方面减少了一个维度。而“节点池治理”，专一于边缘机器的资源、网络、生命周期、可观测指标等等角度，提供了边缘测视角与治理思路。
Pool-Coordinator 在社区内首次践行了这一概念，提出了一套针对云边场景的资源、网络、利用、监控等角度的边缘治理计划，具备高可用能力。
边缘根底组件对云边网络的需要与挑战
边缘根底组件对于边云网络的要求，驱使着 OpenYurt 为开发者提供更正当、更优化的解决方案。
首先是云边网络带宽根底条件的问题。在云原生边缘计算的场景中，云边网络通路带宽往往受到各个方面的限度，例如机器资源，物理间隔，资金老本等，这就导致对于局部厂商和用户，其云边网络条件带宽较低，甚至在各别特定环境的节点池带宽极低。
其次是集群资源数据量的问题。边缘集群往往笼罩较多地区、机器节点与物理设施，相比于一般集群，其笼罩地区广大，规模较大，集群整体资源量也就绝对较多。对于局部集群根底组件，例如代理组件、CNI 组件、DNS 组件，甚至局部业务组件，例如设施驱动程序，边缘基础架构中间件等，须要在启动时通过 K8S List/Watch 机制来拉取全量资源并监听，这个过程对网络要求较高。
再者是边缘根底组件的重要性，在新节点纳管入边缘集群时，初始化程序会拉起一系列 OpenYurt 边缘根底组件与配置，待顺利初始化，才会调度业务程序至节点。一旦边缘根底组件因为带宽起因，拉取依赖资源失败，会导致边缘机器业务利用无奈启动，边缘节点算力扩容失败。另一方面，处于运行中的边缘根底组件，如果长时间拉取资源失败，可能造成网络、代理、存储资源与核心不同步，造成业务危险。
能力、架构实现与工作形式
3.1 Pool-Scope（节点池维度）资源缓存
Pool-Coordinator 会为节点池维度的资源提供边缘侧缓存，从而升高因为这些资源的大量 list/watch 申请造成的云边网络带宽问题。
在部署阶段，开发者能够通过装置 Chart 包的形式，将 Pool-Coordinator 组件装置至集群，该过程利用了 OpenYurt 生态的 YurtAppDaemon 资源，将这一组件以节点池粒度部署至所有的边缘节点池，每个节点池一个实例。
待 Pool-Coordinator 实例启动，会由选主机制选出的 Leader YurtHub 将 Pool-Scope 资源，例如 endpoints/endpointslice 拉取至边缘，进而同步至 Pool-Coordinator 组件，缓存起来，以供节点池内全副节点应用。
节点池内全副节点上运行的 YurtHub，将 Pool-Scope 资源读申请代理至 Pool-Coordinator。实践上，针对一个资源的全量申请，一个节点池只须要一条云边长链接即可，节点池内的这些资源的读申请，都交由 Pool-Coordinator 向下提供服务，从而极大水平升高云边网络耗费。特地是在具备带宽要求的弱网络场景，Pool-Coordinator 能够减弱因为边缘根底容器启动 / 重建导致的大量申请，以及缩小运行期间的云边资源下发量。
Pool-Scope 资源默认定义为 endpoints 和 endpointslices 两种资源。这两种资源在 YurtHub 代理的云边流量中占比拟高，这在规模较大集群中体现的更为显著；另外 Pool-Scope 资源要求为节点池内专用的资源，与调用方所属节点无关，这也适配于上述两者。Pool-Scope 资源可由用户配置其余资源，例如 Pods，Node，以及 CR，以应答在特定资源量大的网络优化场景。
3.2 YurtHub 的初始化、选主与容灾机制
当新的节点池创立并增加算力时，YurtHub 作为边缘机器节点的底层过程将最先启动。其优先直连 APIServer，执行失常的初始化逻辑。待节点退出集群，OpenYurt 组件 Yurt-App-Manager 将按需调度边缘节点池组件 Pool-Coordinator 至该机器。等到 Pool-Coordinator 胜利启动，YurtHub 将探知其可用状态，与之建联交互。YurtHub 提供 –enable-coordinator 启动参数，将该参数置为 true 时，YurtHub 会对节点池 Pool-Coordinator 组件进行探知，为节点池内灵便的切流、按需启动提供了反对。
一个节点池内的全副 YurtHub 实例存在读写抵触问题，咱们指定这些 YurtHub 通过 Pool-Coordinator 内的分布式锁执行选主，只有 Leader YurtHub 负责缓存资源写操作。其余 Follower 将时刻监听 Pool-Coordinator 内保留的 Leader Lease 资源，从而确定是否 Leader 存活，只有存活的 Leader 能力保障缓存资源的正确性和时效性。当 Leader YurtHub 因为某些起因，例如和核心网络断开，以及本身起因而退出，将由其余 Follower YurtHub 中从新选主，保障边缘缓存的可用性。
这个过程咱们提供了 Grace Period 机制，即当短暂的云边网络故障导致的 Leader YurtHub 不衰弱状态，不会导致边缘节点池切流至云端，当超过肯定工夫之后再进行切流，以防网络抖动和大量节点切流导致带宽彻底打满。
当 Pool-Coordinator 因异样起因退出后，边缘 YurtHub 将感知，并将代理申请转发至云端，从而取得正确响应。待 Pool-Coordinator 重建后，会重启选主机制，重建边缘缓存，升高云边带宽耗费。
证书与鉴权
Pool-Coordinator 套件提供齐备的证书管理机制，并保障在流量转发过程的权限正确。
在零碎初始化阶段，会由 Yurt-Controller-Manager 签发证书，该证书被 YurtHub 和 Pool-Coordinator 获取，保障 YurtHub 有权限，并能够平安读写缓存。
对于 Pool-Scope 资源申请转发缓存的过程中，会进行 Token 替换，保障这次申请带有缓存读写权限。
瞻望
随着 v1.2 版本的公布，Pool-Coordinator 在后续将持续着重于稳定性建设和生态组件建设，包含可观测能力、网络抖动的鲁棒性优化、断网自制能力、Pool-Coordinator 容器运维能力等。Pool-Coordinator 组件也将会工业生产中的大规模落地实际，并像其余 OpenYurt 生态组件一样在生产过程中迭代和优化，晋升零碎稳定性。
欢送有更多的贡献者与用户参加 Pool-Coordinator 的建设！如果您对于 OpenYurt 有任何疑难，欢送应用钉钉扫描二维码或者搜寻群号（12640034121）退出钉钉交换群。
戳此处，立刻理解 OpenYurt 我的项目