作者：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 网络。
3. 结合每个省站的网络规划，增量为省站配置 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：
