关于云原生:CNStack-助推龙源电力扛起双碳大旗

作者：CNStack 容器平台、龙源电力：张悦超、党旗

龙源电力容器云我的项目背景

龙源电力集团是世界第一大风电运营商，随着国家西部大开发策略推动，龙源电力曾经把风力发电场铺设到全国各地，甚至是交通极不便当的偏远地区，这使龙源电力成为寰球装机容量、风电占比最大的运营商，但与此同时企业也面临诸多基础设施建设和保护的挑战。分设在全国 30 多个省的 240 多座风电场站有近千台服务器，因为大多地理位置偏远，所以核心到边、端保护不便；另外，风电场站计算资源无限，网络 IP、带宽等资源稀缺给 IT 架构布局、治理带来较高老本。同时，运行在省核心、风电场站的不同业务利用对计算、存储、网络资源需要差异性大，也须要兼顾存量资源的对立治理，场站利用零碎的保护更新须要大量重复性工作，治理老本高、难度大等问题逐步成为企业倒退的瓶颈。

CNStack 利用与龙源电力的最佳实际

CNStack（云原生技术中台）是阿里云云原生最佳实际的输入载体，它能够在多云、混合云场景下集中纳管基础设施资源，对立编排和调度工作负载，帮忙客户高效构建高性能、高可用、高牢靠和平安合规的现代化利用，晋升企业数字化转型的整体效力。CNStack 致力于帮忙企业 IT 架构重组升维，提供用最低的老本构筑业务倒退护城河，产生更大的市场利润技术原动力。CNStack 在过来两年继续打造企业级分布式基础设施 OS，帮忙利用开发者屏蔽底层计算、网络简单拓扑，和异构差异性，并通过适应性优化 IaaS+ 服务，向以业务为核心的企业提供更多指标为导向的组合效用输入。

2.1 分布式云计算和服务

2.1.1  基于 OpenYurt 的云边协同  

龙源我的项目是典型的边缘场景，尽管云核心到省核心架设专线实现了全网算力节点的网络互通，然而因为广袤的地理分布，导致网络带宽资源稀缺，网络传输品质无奈保障。省核心、风电场站不仅是天文上的概念，也是业务多租户隔离的独立单元，在这些单元外部，因为天文上绝对凑近，其网络品质及带宽限度绝对宽松。基于 OpenYurt 的 CNStack 云边协同服务（CNStack EdgePaaS）很好地解决弱网环境下云边协同和边缘自治问题。OpenYurt 是阿里云开源的业界首个以无侵入形式将 Kubernetes 扩大到边缘计算畛域的我的项目，于 2020 年 9 月成为 CNCF 沙箱我的项目。OpenYurt 针对边缘场景中网络不稳固、云边运维艰难等问题，对原生 Kubernetes 无侵入加强，重点提供了边缘节点自治、云边运维通道、边缘单元化的能力。

OpenYurt 提出的“节点池”概念，对应龙源我的项目的组织拓扑，实现了下图的部署构造：

“节点池”带来的可不仅仅是资源分组治理这么简略，OpenYurt 还提供了更多专门针对边缘场景的个性：

• 利用单元化

区别于传统的利用多单元治理，边缘场景下的业务单元数量会显著减少。如果采纳传统的散发模式，边缘 UnitedDeployment 部署模型将用户的工作负载部署在不同的节点池中，业务的实例数、版本、镜像、配置等信息都能够依照节点池的维度进行对立治理、对立散发，而不是每个单元独立治理。

• 服务拓扑

在边缘场景下，业务负载会依照站点的维度创立多实例。不同站点之间的利用，只能通过本站点的利用拜访，而不能由相邻站点拜访。为此，OpenYurt 提供了服务拓扑的能力，确保边缘节点利用只能由雷同节点池的节点拜访，或者只能由本节点拜访。

• 边缘自治

传统的 Kubernetes 对网络有着很高的要求，一但产生了网络中断，Kubernetes 会基于可用性的起因，将工作负载调度到别的能够联通的节点上。这个个性在中心化的集群是很棒的个性，然而这个个性在边缘场景下反倒会带来很大的负面影响。因为这种中断通常只会产生在边缘与核心之间，这种中断一但产生，用户冀望的后果是边缘侧的工作负载持续工作，待网络复原后，核心侧复原比照边缘业务负载的治理即可。通过 OpenYurt，核心侧会在边缘节点不可用的状况下，阻止工作负载的驱赶，同时确保和核心断联的节点上的工作负载持续运行。

2.1.2 云边网络优化

部署在边缘节点上的 CRD Controller，或者 DaemonSet 类型的管控组件都可能对集群不同范畴的资源做 list/watch，可能造成边缘节点到核心节点较多开销的网络 I/O 累赘。为此设计的 OpenYurt Pool-Coordinator  组件，会为节点池维度的资源提供边缘侧缓存，从而升高因为这些资源的大量 list/watch 申请造成的云边网络带宽问题， 相比原生 Kubernetes 云端进口流量峰值升高 90%。

待 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，以应答在特定资源量大的网络优化场景。

该性能已在 Openyurt 最新版本（v1.2）中公布，近期将利用到龙源我的项目中。

除此以外，CNStack 管控组件通过一系列优化降级，曾经将单个边缘节点到核心 master 节点单向实时网络 I/O 从 32Mb/ s 管制在 200Kb/ s 以内。

2.1.3  分布式内容散发服务

在边缘场站除了算力节点以外，还有很多 IOT 设施，例如摄像机，交换机，无线 AP 等等。这些设施并不是装置后就不论，而是同样有降级的须要。以无线 AP 为例，一个 AP 的系统升级包有几十 mb，然而龙源的一个场站就可能存在几个甚至是几十个无线 AP，如果这些 AP 的降级操作全副从云核心或者省核心获取升级包，将会产生极大的流量开销。咱们采纳了，以站点粒度对立散发，再通过站点内共享的形式，实现对云边之间网络流量的节约：

首先在云核心打包须要散发的内容，以内容服务的形式散发到各个场站。此步骤只须要破费 ” 内容散发服务 * 站点数 ” 的流量。内容散发服务在边缘侧部署当前，无线 AP 再通过 ftp 协定拜访本站点的服务端点，这样，无论边缘侧有多少无线 AP，云端之间只须要破费一份内容流量即可。

通过此套计划，取得了如下的成果：

• 以龙源场站 26000 台无线 AP 的 IOT 降级计算，AP 降级工期从 6 个月缩短至 1 个月，全国专线网络带宽占用升高 98%
• 晋升了边缘侧拜访的响应速度
• 晋升边缘侧拜访的可用性
• 对数据的访问者无侵入

CNStack EdgePaas 还将对内容散发服务进一步降级，大幅晋升内容散发能力：

• 动静推送散发内容
• 准确到单个内容 + 站点的散发控制能力
• 边缘侧提供更多的拜访协定反对（http、ftp、sftp）
• 欠缺的访问控制

在边缘站点侧，CNStack EdgePaas 提供站点维度的拜访代理，数据消费者只须要应用标准协议（http、ftp、sftp）即可获取关注的数据。同时依靠于服务协同中就近拜访的个性，用户无需为每个站点的利用做独自的配置，全副共享一个服务即可实现内容的获取。

同时，此计划还具备预热的能力。因为内容散发的流程是独立于数据生产流程的，所以能够在消费行为产生之前，提前将消费者须要应用的数据被动对送到业务单元，进而实现数据预热。

2.1.4  边缘镜像仓库减速  

龙源我的项目遍布在全国各地的省核心及边缘场站节点尽管网络链路上与云核心买通，然而边云网络带宽资源稀缺，利用镜像数量、规格都较大给容器镜像散发造成了微小挑战。中心化镜像仓库服务极易造成云边网络拥塞。

基于 Harbor 的镜像复制能力，提供两级镜像仓库服务计划，实现边缘镜像减速。在各个区域别离部署各自的 docker registry 实例，跟云端的 harbor 服务一起造成一主多从的架构。基于 Harbor 的复制性能配置同步关系，让云端的镜像主动同步到各个区域中的 docker registry 实例。各个区域内的边缘节点间接从本区域的 docker registry 实例拉取镜像。

该计划达成的成果：

• 极大缩小了对核心 Harbor 服务的大量并发
• 一个区域对于一个镜像只须要从核心拉取一次，缩小了对云边网络带宽的耗费
• 区域内的边缘节点就近拜访镜像仓库服务，获取镜像更快，利用更新更快

2.2  多类型利用资源共池调度和治理

2.2.1  虚拟化超交融

龙源治理平台除了须要承载容器化的业务零碎之外，还需部署治理运行在虚拟机内的业务零碎，容器化利用与虚拟化利用间还须要相互拜访。

CNStack 虚拟化服务（CNStack Virtualization）基于 KubeVirt、hybridnet、open-local 等云原生软件构建了云原生虚拟化产品能力，应用一套管制立体同时治理容器和虚拟机，为用户提供虚拟机资源的治理能力，实现容器与虚拟机的资源共池治理、灵便调配、对立调度。

云原生虚拟化基于容器来治理运行 KVM 虚拟机，通过 Kubernetes 自定义资源（CRD）的模式使得虚拟机资源可被视为 Kubernetes 集群的“一等公民”，提供了不同于容器的虚拟机生命周期治理接口，通过与规范的 CNI 容器网络插件和 CSI 容器存储插件对接，使得虚拟机与容器可复用 Kubernetes 集群内的网络与存储资源：

• 通过阿里云自研的 hybridnet 容器网络插件将虚拟机网络与 underlay 物理网络买通，使得虚拟机内的视频监控利用能够间接拜访治理场站节点的摄像头设施。
• 通过阿里云自研的 open-local 容器存储插件将节点的本地存储资源池化，以保留虚拟机磁盘数据。

2.2.2 GPU 调度和隔离  

龙源我的项目多类型业务别离还包含 CPU 和 GPU 利用，CNStack 能够运维和调度其散布在各边缘场站的异构 GPU 节点。CNStack 提供了丰盛的 GPU 敌对的治理界面，如导入、辨认、GPU 设施故障检测等。为了更无效地利用 GPU 并实现老本效益，CNStack 还提供了 GPU 共享调度和 GPU 隔离性能。

通常状况下，Nvidia GPU 容器调度将一个 GPU 卡调配给一个容器。然而，在图像和视频推理场景中，一个容器中的算法模型可能无奈充分利用一张 GPU 卡的算力，导致资源节约。在老本效益的背景下，GPU 共享是一个必然的需要。为了实现 GPU 容器层面的共享，须要对一张 GPU 卡进行细粒度资源划分，将 GPU 的细粒度资源上报到 Kubernetes，而后由调度器进行精细化调度和调配，实现 GPU 的共享应用。CNStack 通过如下外围组件实现了 GPU 共享调度和 GPU 隔离能力：

• 通过阿里云自主研发的 GPU-Share Device Plugin 和强化的调度器，能够实现细粒度的 GPU 资源上报、调度和绑定，从而实现 GPU 的共享调度。
• 通过阿里云自主研发的 AMP eGPU 组件，能够实现各个容器间共享 GPU 的隔离，防止了共享 GPU 中业务的互相烦扰。

2.3  适配简单 IT 架构的容器云底座

除了须要适配简单业务模型的异构利用生命周期治理外，龙源我的项目的网络要求适配和多 ISV 基于大规模研发的风控问题也面临诸多挑战。

2.3.1 基于 hybridnet 的简单网络模型适配  

对于龙源我的项目的网络需要，通过与客户、业务方的沟通确认，总结了以下几点：

1. 平台部署在以 IPv6 网络为主的根底机器环境之上，机器是无奈保障具备 IPv4 地址的，并且机器地址申请艰难，遍布在全国各地的场站、省站与云核心会通过 IPv6 的主机链路进行通信。2. 局部业务利用以后没有实现 IPv6 适配，存在应用 IPv4 地址进行通信的需要，因为 IPv4 地址资源限度，这部分业务无奈应用 IPv4 链路通信。3. 省站中，业务利用所在的虚拟机须要应用独立的机器网段 IPv4/IPv6 地址与集群内部通信（如上所述，虚拟机和容器应用的是雷同网络实现）。综上来看，整体网络架构是非常复杂的，“IPv4/IPv6 双栈”以及“overlay/underlay 链路混合部署”两种场景在需要上交叠了起来，对于容器网络实现的灵活性和健壮性提出了微小挑战。

Hybridnet 网络插件是阿里自研的通用开源 CNI 实现，旨在提供全场景下的 Kubernetes 容器网络部署能力。

目前 hybridnet 曾经全面反对了 IPv4/IPv6 双栈场景以及 VXLAN（overlay）、VLAN（underlay）、BGP（underlay）网络的混合部署，并且通过精简的架构设计，实现了不输于 flannel 的稳定性（管制组件和数据面解藕）。

基于 hybridnet 的能力，CNStack 通过如下设计满足了龙源场景诉求：

1. 所有 Pod 默认部署为 overlay 状态（hybridnet 实现的 VXLAN 网络），容器只有 IPv6 地址，应用 IPv6 链路进行通信，这样，平台自身只依赖底层 IPv6 网络通信，并且不占用额定的底层网络地址。2. 对于局部存在 IPv4 通信诉求的 Pod，hybridnet 基于底层 IPv6 网络虚构出 IPv4 的 overlay 容器网络地址，提供给没有齐全适配 IPv6 网络的利用 Pod 应用，不占用额定的底层网络地址，并且不依赖底层 IPv4 网络。
2. 联合每个省站的网络布局，增量为省站配置 IPv4/IPv6 的 underlay 网络（hybridnet 实现的 VLAN 网络），与物理交换机协同工作，实现容器网络和底层网络间接买通，并且为虚拟机调配对应 underlay 网络的地址。

2.3.2 多 ISV 场景下规模集群运维  

基于 User-Agent 的限流能力

在龙源我的项目中，业务零碎由多 ISV 协同开发，各 ISV 抉择的 Kubernetes 扩大开发框架不尽相同，操作 Kubernetes 资源规模和频率也无法控制，所以极易产生到 Kubernetes apiserver 超出预期的调用量，可能造成雪崩效应。所以，首先为 apiserver 开启限流，kube-apiserver 反对 MaxInflight 和 APF（API Priority and Fairness）两种限流能力：

• MaxInflight 限流能力能够限度 API Server 同时解决的读和写的申请总量，然而粒度较粗无奈对申请起源做限流，不能很好地对 API Server 起到防护作用。
• APF 限流能力能够用来细化限流的治理，比方依照外围管制、个别控制器、节点组件等将总并发量依照比例进行划分，防止某一个用户或组件的异样行为影响全局，然而保护老本较高，目前在业内深度应用的案例并不多。

另外，针对 MaxInflight 和 APF，它们都是通过 User 来做限流，也就说它们须要先通过认证。然而，认证并不是便宜的，在大量申请到来时，API Server 将耗费大量 CPU 来解 x509 证书或 ServerAccount Token 的验证。在应答大量申请的时候，应该通过最小开销来决定是否放行申请。综上来说，已有的限流能力并不能不便、无效地对不同客户端的申请进行不同水平的限流，并且在判断是否放行申请时会存在较大的开销。为此，CNStack 容器服务（ACK Distro）在 API Server 中减少了基于 UA（User-Agent）的限流能力，UA 限流能力能够依据申请中的 User-Agent、申请的操作类型，申请的资源，在 API Server 认证之前就决定是否放行该申请，实现以最小的开销来对申请进行辨别限流。

如图所示，是 UA 限流判断的工夫点。它会从 HTTP 申请中取出 User-Agent、resource、verb 等内容组成一个三元组，如果该三元组与用户设置的 UA 规定中的三元组相匹配的话（User-Agent 反对正则表达式），则会应用令牌桶算法依据 UA 规定的中 QPS/Burst 值判断是否放行该申请。如果放行该申请，则会进入认证阶段；如果回绝该申请，则会返回 429 状态码，并容许申请的客户端在 1 秒后进行重试。

综上，UA 限流能够不便、无效地针对不同客户端的申请进行不同水平的申请，并且以最小开销来决定是否放行申请，同时准确 UA 匹配，防止误伤。

etcd 集群拆分

鉴于龙源集群的规模，以及多 ISV 业务利用须要频繁、大量创立 deployment/pod 等集群资源的业务须要，对 etcd 性能要求较高。针对 event 资源来说，频繁创立、删除的操作会产生大量该资源，但该资源对集群的失常运行影响并不大，因而为了升高单 etcd 集群的压力，该资源能够被存储到其余 etcd 集群中。针对 lease 资源来说，如果该资源申请超时，则会导致许多控制器选举失败。一旦控制器被重启，则会从新发动全量的 List 操作，进一步加剧对 etcd 和 apiserver 的压力。因而，该资源不适宜存储于压力较大的 etcd 集群中，然而该资源相比 Pod 等资源是能够从新生成的。所以，该我的项目中 CNStack ACK Distro 将 event、lease 两种资源存储到独立的 etcd 集群中，缩小了单 etcd 集群的压力，最终减小了单 etcd 集群压力大带来的影响，保障集群的稳定性。

总结

阿里云 CNStack 利用于龙源电力我的项目的分布式云解决方案已于近期实现测试上线，实现核心到 240 多个风电场服务器的对立可视化治理，反对同一个平台对运行于虚拟化、容器上的 CPU、GPU 多类型利用资源共池调度，多租户资源隔离利用开发和运维等，局部云化能力对边缘场景提供就近服务，极大升高边云网络传输开销。 该解决方案利用容器及云原生技术帮忙企业实现一次 IT 架构的跃迁，实现边缘资源、利用运维效率 10 倍晋升，边缘场站资源利用率 3 倍晋升，斩获云原生技术实际联盟（CNBPA）颁发的 2022 年度公共事业行业最佳云原生实际奖。 2023 年，阿里云 CNStack 持续深层解决企业生产环境理论问题，已在边云网络带宽优化，云化能力边缘就近服务，中心化 NoOps 运维等方面布局多项能力，继续打造智慧新能源最佳实际。

参考资料：

CNStack：

https://www.aliyun.com/product/aliware/cnstack

https://github.com/alibaba/CNStackCommunityEdition

ACK Distro：

https://www.aliyun.com/product/aliware/ackdistro

https://github.com/AliyunContainerService/ackdistro

Hybridnet：

https://github.com/alibaba/hybridnet

Open-Local：

https://github.com/alibaba/open-local