作者：龙源电力：张悦超 、党旗 阿里云原生: 李志信
OpenYurt 介绍
OpenYurt 是业界首个对云原生体系无侵入的智能边缘计算平台，具备全方位的“云、边、端一体化”能力，能够快速实现海量边缘计算业务和异构算力的高效交付、运维及管理。其在云平台、云游戏、AI、IOT 领域早已有众多落地用户。
OpenYurt 完美适配和解耦于原生 K8s 组件，例如 Kubelet、Kube-Proxy、CoreDNS 等。其核心能力为边缘节点的边云网络代理，由 Yurthub 组件提供，旨在保证跨云场景下的 K8s 节点正常纳管和运行，从而为边缘 IOT 设备赋予云原生能力。OpenYurt 经过生产验证，可支持上千节点以及上万 Pods 大规模集群的稳定生产能力。下面我们将介绍其集成于 CNStack 云原生技术中台，落地于龙源电力企业的具体场景。
CNStack（云原生技术中台）介绍
CNStack（云原生技术中台）是阿里云云原生最佳实践的输出载体，它可以在多云、混合云场景下集中纳管基础设施资源，统一编排和调度工作负载，帮助客户高效构建高性能、高可用、高可靠和安全合规的现代化应用，提升企业数字化转型的整体效能。CNStack 致力于帮助企业 IT 架构重组升维，提供用最低的成本构筑业务发展护城河，产生更大的市场利润的技术原动力，CNStack 在过去两年持续打造企业级分布式基础设施 OS，帮助应用开发者屏蔽底层计算、网络复杂拓扑，和异构差异性，并通过适应性优化 IaaS+ 服务，向以业务为中心提供更多目标为导向的组合效用输出。
案例落地架构
龙源电力拥有七百多个服务器节点，分布于中国数十个省市，期望引入高可用的云原生平台，实现“本部-省公司-场站” 三级服务器的统一纳管能力。并需要在中心节点实现对边缘节点容器进行统一的调度、监控、运维能力；并针对边缘场景，对弱网络、云边断网场景的服务稳定性提出要求。
3.1 案例边缘能力整体架构
龙源场景具有规模大、节点多、业务容器数量庞大的特点，并由于节点之间物理距离大和网络成本问题，导致边缘至中心站点的网络资源带宽小；另外，还存在中心站点断电维护时，保证边缘业务依然正常工作的诉求。CNStack 云原生技术中台引入 OpenYurt v0.7.0 版本组件来支持这种场景。
我们对于 OpenYurt 边缘组件的部署架构如下所示。
整个集群拥有一个由多个节点组成的中心站点，负责整个集群的管控。同时，主要的业务工作负载位于数十个省市的上百个边缘节点中，如上述介绍，边缘节点至中心站点的网络带宽较小，网速大致在 40KB/s 至2MB/s。
如上图所示，在中心站点上，部署了 CNStack 云原生技术中台提供的 K8s 基础组件例如 CoreDNS、Kube-Controller-Manager、APIServer ；以及集成的 OpenYurt 云端组件，包括负责边缘节点池资源生命周期管理和证书签发的 Yurt-Controller-Manger、负责反向运维能力支持的 Tunnel-Server 等组件。
在边缘站点上，也拥有原生组件和 OpenYurt 边缘组件，其中边缘组件包括边缘 DNS 缓存服务 Local-DNS，其可以大幅减少边缘应用查询 DNS 记录所消耗的跨站点流量，还有 Tunnel-Agent 组件。其中最重要的为 Yurthub 组件，其负责代理边缘节点内的 APIServer 请求，从而实现在云边网络暂时断开的情况下，通过读本地缓存，保证代理的请求正确返回，维持基础组件和业务负载的正常工作；此外，它还负责心跳代理和容器内 APIServer 证书的重写与控制，从而保证业务直连 APIServer 请求也经由 Yurthub 转发。
通过这样的架构，我们将 OpenYurt 在大规模边缘集群场景落地，以求满足用户诉求。
3.2 断网边缘自治能力
龙源电力需要我们支持中心站点断网维护的场景，需要在中心侧机器停机维护的情况下，保证全部边缘机器业务正常运行。对于原生的 K8s 集群，云边网络断开会导致边缘容器被驱逐，部分边缘组件也会由于 APIServer 无法连接，资源同步失败而报错，甚至退出，导致业务异常和生产事故。
OpenYurt 组件解决了断网自治的问题，首先通过对节点生命周期的配置，以及 Yurt-Controller-Manager 对于边缘自治节点的容器控制，保证云边断网情况，即使节点状态为 NotReady，边缘业务容器依然不被驱逐，且恢复后丝毫不影响业务的正常运行。其次，Yurthub 通过代理边云方向目的为 APIServer 的全部请求，在连接至云端的远程连接不健康时，如中心停机，则将请求切流至本地缓存，使得边缘组件依然能成功获取资源。直到网络恢复后，Yurthub 切流至中心站点，本地缓存得以更新，代理请求恢复正常转发。
在龙源场景引入 OpenYurt 组件，保证了在云边断网甚至中心站点停机维护的场景下，边缘节点的业务应用依然能正常运行。这一能力在生产中得到了反复验证。
3.3 可编程的资源访问控制
YurtHub 组件内置的可编程的数据过滤框架，可以帮助用户对云端请求的返回数据进行无感知，按需的改造，从而满足云边协同场景下的特定业务需求。如服务拓扑的路由选择， 云端访问链路的自适应等。
InClusterConfig
Openyurt 的组件 Yurthub 将通过 kubelet 为所有 pods 注入指向代理端点的 InClusterConfig，整个过程对于业务无感。基于这一配置注入，需要通过容器内部鉴权配置访问 APIServer 的业务容器，都可以在边缘侧直接部署，正常运行，无需进行改动。访问 APIServer 的所有请求都将经过 Yurthub 代理，从而能够使用缓存和断网自治能力，达到增强系统稳定性和资源消耗的目的。
流量拓扑规则
服务拓扑（Service Topology）可以让一个服务根据集群的节点拓扑进行流量路由。例如，一个 Service 可以指定流量被优先路由到和客户端 pod 相同的节点或者节点池上。例如，我们可以为 Service 增加注解：openyurt.io/topologyKeys=openyurt.io/nodepool，这时站在一个边缘节点池内，一个业务应用的客户端视角，向这个 Service 发起的网络请求都将被路由至位于相同节点池的目标端点。其主要解决了两个问题：其一为就近原则，降低响应时延；其二为边缘节点池之间网络不互通的场景下，可以保证全部业务应用都能面向这个 Service 名进行开发，从而保证在边缘节点池内部署后，无需对业务程序进行改造，即可自适应的将流量路由至可达的端点。
3.4 反向运维能力
在龙源场景我们实践了基于 OpenYurt Tunnel 组件的反向运维能力。当边缘站点和云端站点处于不同 VPC 内，边缘机器 IP 在云端不可见的情况下，我们可以通过 Tunnel 组件提供的长链接，完成由云端至边缘请求转发。我们在龙源场景验证和测试阶段使用了大量 kubectl 提供的运维命令如 logs、exec 等，都基于这一连接实现，提高了测试验证的效率。
上述边缘集群监控、日志采集方案，就是基于 Tunnel 反向运维能力实现，保证在云端不可见的边缘节点资源，依然可以通过这一通道进行采集。
Tunnel 长链接为云边单向可见的场景提供了云边反向请求的底层数据通路保证，我们也可以基于这一能力，延伸更多的应用场景，例如边缘机器端口云端代理，多站点内容分发等。
3.5 边云网络优化套件
边云网络优化套件是 OpenYurt 项目 v1.2 版本的新功能，其核心组件是 Pool-Coordinator，它会为节点池维度的资源提供边缘侧缓存，从而降低因为这些资源的大量 list/watch 请求造成的云边网络带宽问题。
在部署阶段，开发者可以通过安装 Chart 包的方式，将 Pool-Coordinator 组件安装至集群，该过程利用了 OpenYurt 生态的 YurtAppDaemon 资源，将这一组件以节点池粒度部署至所有的边缘节点池，每个节点池一个实例。待 Pool-Coordinator 实例启动，会由选主机制选出的 Leader YurtHub 将 Pool-Scope (节点池内共享） 资源，例如 endpoints/endpointslice 拉取至边缘，进而同步至 Pool-Coordinator 组件，缓存起来，以供节点池内全部节点使用。
随着社区最新版本 v1.2 版本的发布，Pool-Coordinator 在后续将继续着重于稳定性建设和生态组件建设，包括可观测能力、网络抖动的鲁棒性优化、断网自治能力、Pool-Coordinator 容器运维能力等。Pool-Coordinator 组件也将会工业生产中的大规模落地实践，并像其他 OpenYurt 生态组件一样在生产过程中迭代和优化，提升系统稳定性。
总结
时至今日，基于 OpenYurt 组件的 CNStack 云原生技术中台在龙源电力已经生产交付近一年时间。而近期龙源电力首创的云边协同服务资源调度平台在全国范围正式上线，为企业数字化转型筑牢基础，最终斩获云原生技术实践联盟“2022最佳云原生行业实践奖”。我们相信在不断的生产实践验证中，OpenYurt 携手用户，将会走的更扎实，走的更稳健！
如果您对于 OpenYurt 有任何疑问，欢迎使用钉钉扫描二维码或者搜索群号（钉钉群号：12640034121）加入钉钉交流群。
点击此处，立即了解 OpenYurt 项目
