写点什么

重磅!KubeEdge 单集群突破 10 万边缘节点|云原生边缘计算峰会前瞻

  • 2022 年 6 月 06 日
  • 本文字数:7109 字

    阅读完需:约 23 分钟

近日, 云原生边缘计算 KubeEdge 社区开展了支持 100000 边缘节点大规模测试。在边缘计算行业应用的高速发展时期,作为 CNCF 唯一孵化级的云原生边缘计算项目,KubeEdge 在智能交通、智慧城市、智慧园区、智慧能源、智慧工厂、智慧银行、智慧工地、CDN 等行业发挥着全面的驱动作用。本次大规模测试,KubeEdge 单集群突破 10 万边缘节点!


《KubeEdge 单集群突破 10 万边缘节点 | 技术报告》也会在 6 月 25 日即将开展的云原生边缘计算峰会(KubeEdge Summit 2022)中进行应用解析。我们先来一睹为快吧!


摘要


随着 KubeEdge 在越来越多的企业以及组织大规模落地,KubeEdge 可扩展性和大规模逐步成为社区用户新的关注点。因此,我们开展了 KubeEdge 的大规模测试工作,现在我们宣布 Kubernetes + KubeEdge 集群能够稳定支持 100,000 边缘节点同时在线,并且管理超过 1,000,000 的 pod。在本篇文章中,我们将介绍测试使用的相关指标,如何开展的大规模测试以及我们如何实现大规模边缘节点接入。

背景介绍


随着 5G 网络、工业互联网、AI 等领域的高速发展,边缘计算成为引领数字化发展的潮流。智慧城市、智慧交通、智慧医疗、智能制造等未来场景更多被人熟知,边缘计算也受到了空前的关注。Gartner 里面明确提出,到 2023 年,网络边缘的智能设备数量可能是传统 IT 的 20 倍以上。到 2028 年,传感器、存储、计算和高级人工智能功能在边缘设备中的嵌入将稳步增长。由于物联网设备本身存在类型繁杂和数量众多的特点,物联网设备接入的数量级增加的同时,给我们的统一管理和运维带来了巨大的挑战。


与此同时,KubeEdge 社区的用户也提出了大规模边缘节点和应用管理的诉求。基于 KubeEdge 的高速取消省界项目中,在全国的省界收费站拥有将近 10 万边缘节点,超过 50 万边缘应用接入,并且随着项目的演进,边缘节点和应用规模将进一步扩大。使用 KubeEdge 打造的车云协同管理平台,是汽车行业的首款“云、边、端”一体化架构,助力软件定义汽车实现软件快速升级迭代。在此平台中,每一辆汽车,均作为一个边缘节点接入,边缘节点的规模将达到数百万级别。

KubeEdge 简介


KubeEdge 是面向边缘计算场景、专为边云协同设计的业界首个云原生边缘计算框架,在 Kubernetes 原生的容器编排调度能力之上实现了边云之间的应用协同、资源协同、数据协同和设备协同等能力,完整打通了边缘计算中云、边、设备协同的场景。


KubeEdge 架构主要包含云边端三部分,云上是统一的控制面,包含原生的 Kubernetes 管理组件,以及 KubeEdge 自研的 CloudCore 组件,负责监听云端资源的变化,提供可靠和高效的云边消息同步。边侧主要是 EdgeCore 组件,包含 Edged、MetaManager、EdgeHub 等模块,通过接收云端的消息,负责容器的生命周期管理。端侧主要是 device mapper 和 eventBus,负责端侧设备的接入。


KubeEdge 以 Kubernetes 管控面作为底座,通过将节点拉远的方式,扩展了边云之间的应用协同、资源协同、数据协同和设备协同等能力。 目前,Kubernetes 社区官方支持的规模是 5,000 个节点和 150,000 个 Pod,在边缘计算的场景,随着万物互联时代的到来,这种规模是远远不够的。大规模边缘设备的接入,对边缘计算平台的可扩展性和集中管理的需求将会增加,如何使用尽可能少的云端资源和集群,管理尽可能多的边缘设备,简化基础设施的管理和运维。KubeEdge 在全面兼容 Kubernetes 原生能力的基础上,对云边消息通道和传输机制进行了优化,突破了原生 Kubernetes 的管理规模,支撑更大规模的边缘节点接入和管理。

SLIs/SLOs


可扩展性和性能是 Kubernetes 集群的重要特性,作为 K8s 集群的用户,期望在以上两方面有服务质量的保证。在进行 Kubernetes + KubeEdge 大规模性能测试前,我们需要定义如何衡量集群大规模场景下服务指标。Kubernetes 社区定义了以下几种 SLIs(Service Level Indicator)/SLOs(service-level objective)指标项,我们将使用这些指标来衡量集群服务质量。


1.API Call Latency



2.Pod Startup Latency



社区还定义了 In-Cluster Network Programming Latency(Service 更新或者其 Ready Pod 变化最终反映到 Iptables/IPVS 规则的时延),In-cluster network latency,DNS Programming Latency( Service 更新或者其 Ready Pod 反映到 dns server 的时延), DNS Latency 等指标,这些指标当前还尚未量化。满足所有 SLO 为大规模集群测试的目标,因此本报告主要针对 Official 状态 SLIs/SLOs 进行测试。

Kubernetes 可伸缩性维度和阈值


Kubernetes 的可伸缩特性不单指节点规模,即 Scalability != #nodes,实际上 Kubernetes 可伸缩性包含很多维度的测量标准,包含 namespaces 的数量,Pod 的数量,service 的数量,secrets/configmap 的数量等。下图是 Kubernetes 社区定义的描述集群可扩展性的重要维度(尚在持续更新中):



Kubernetes 集群无限制扩展资源对象而且又满足 SLIs/SLOs 各项指标显然是不可能实现的,为此业界定义了 Kubernetes 多个维度资源上限。


Pods/node 30

Backends <= 50k & Services <= 10k & Backends/service <= 250

Pod churn 20/s

Secret & configmap/node 30

Namespaces <= 10k & Pods <= 150k & Pods/namespace <= 3k

…..


各个维度不是完全独立的,某个维度被拉伸相应的其他维度就要被压缩,可以根据使用场景进行调整。例如 5k node 拉伸到 10k node 其他维度的规格势必会受到影响。如果各种场景都进行测试分析工作量是非常巨大的,在本次测试中,我们会重点选取典型场景配置进行测试分析。在满足 SLIs/SLOs 的基础上,实现单集群支持 100k 边缘节点,1000k pod 规模管理。

测试工具

ClusterLoader2


ClusterLoader2 是一款开源 Kubernetes 集群负载测试工具,该工具能够针对 Kubernetes 定义的 SLIs/SLOs 指标进行测试,检验集群是否符合各项服务质量标准。此外 Clusterloader2 为集群问题定位和集群性能优化提供可视化数据。ClusterLoader2 最终会输出一份 Kubernetes 集群性能报告,展示一系列性能指标测试结果。


Clusterloader2 性能指标:


  • APIResponsivenessPrometheusSimple

  • APIResponsivenessPrometheus

  • CPUProfile

  • EtcdMetrics

  • MemoryProfile

  • MetricsForE2E

  • PodStartupLatency

  • ResourceUsageSummary

  • SchedulingMetrics

  • SchedulingThroughput

  • WaitForControlledPodsRunning

  • WaitForRunningPods

Edgemark


Edgemark 是类似于 Kubemark 的性能测试工具, 主要用于 KubeEdge 集群可扩展性测试中,用来模拟 KubeEdge 边缘节点,在有限资源的情况下构建超大规模 Kubernetes+KubeEdge 集群,目标是暴露只有在大规模集群情况下才会出现的集群管理面问题。Edgemark 部署方式如下图:



  • k8s master --- Kubernetes 物理集群主节点

  • edgemark master --- Kubernetes 模拟集群主节点

  • CloudCore --- KubeEdge 云端管理组件,负责边缘节点的接入

  • hollow pod --- 在物理集群上启动的 pod,通过在 pod 内启动 edgemark 向 edgemark master 注册成为一台虚拟边缘节点,edgemark master 可以向该虚拟边缘节点上调度 pod

  • hollow edgeNode --- 模拟集群中可见的节点,为虚拟节点,由 hollow pod 注册获得

测试集群部署方案


Kubernetes 底座管理面采用单 master 进行部署,ETCD、Kube-apiserver、Kube-Scheduler、Kube-Controller 均为单实例部署,KubeEdge 管理面 CloudCore 采用 5 实例部署,通过 master 节点 IP 连接 Kube-apiserver,南向通过 Load Balancer 对外暴漏服务,边缘节点通过 Load Balancer 轮询策略随机连接到某一个 CloudCore 实例。

测试环境信息


1、管理面 OS 版本


CentOS 7.9 64bit 3.10.0-1160.15.2.el7.x86_64


2、Kubernetes 版本


Major:"1", Minor:"23", GitVersion:"v1.23.4", GitCommit:"e6c093d87ea4cbb530a7b2ae91e54c0842d8308a", GitTreeState:"clean", BuildDate:"2022-02-16T12:38:05Z", GoVersion:"go1.17.7", Compiler:"gc", Platform:"linux/amd64"


3、KubeEdge 版本


KubeEdge v1.11.0-alpha.0


4、Master 节点配置


  • CPU

Architecture:          x86_64  CPU op-mode(s):        32-bit, 64-bit  Byte Order:            Little Endian  CPU(s):                128  On-line CPU(s) list:   0-127  Thread(s) per core:    2  Core(s) per socket:    32  Socket(s):             2  NUMA node(s):          2  Vendor ID:             GenuineIntel  CPU family:            6  Model:                 106  Model name:            Intel(R) Xeon(R) Platinum 8378A CPU @ 3.00GHz  Stepping:              6  CPU MHz:               2999.998  复制
复制代码
  • MEMORY

Total online memory: 256G


  • ETCD DISK

Type: SAS_SSD

Size: 300GB


5、CloudCore 节点配置


  • CPU

Architecture:          x86_64  CPU op-mode(s):        32-bit, 64-bit  Byte Order:            Little Endian  CPU(s):                12  On-line CPU(s) list:   0-11  Thread(s) per core:    2  Core(s) per socket:    6  Socket(s):             1  NUMA node(s):          1  Vendor ID:             GenuineIntel  CPU family:            6  Model:                 106  Model name:            Intel(R) Xeon(R) Platinum 8378A CPU @ 3.00GHz  Stepping:              6  CPU MHz:               2999.998  复制
复制代码
  • MEMORY

Total online memory: 48G

组件参数配置


1、kube-apiserver 参数

--max-requests-inflight=2000--max-mutating-requests-inflight=1000复制
复制代码

2、kube-controller-manager 参数

--kube-api-qps=100--kube-api-burst=100复制
复制代码

3、kube-scheduler 参数

--kube-api-qps=200--kube-api-burst=400复制
复制代码

4、CloudCore 参数配置

apiVersion: cloudcore.config.kubeedge.io/v1alpha1kind: CloudCorekubeAPIConfig:  kubeConfig: ""  master: ""  qps: 60000  burst: 80000modules:  cloudHub:    advertiseAddress:      - xx.xx.xx.xx    nodeLimit: 30000    tlsCAFile: /etc/kubeedge/ca/rootCA.crt    tlsCertFile: /etc/kubeedge/certs/server.crt    tlsPrivateKeyFile: /etc/kubeedge/certs/server.key    unixsocket:      address: unix:///var/lib/kubeedge/kubeedge.sock      enable: false    websocket:      address: 0.0.0.0      enable: true      port: 10000  cloudStream:    enable: false  deviceController:    enable: false  dynamicController:    enable: false  edgeController:    buffer:      configMapEvent: 102400      deletePod: 10240      endpointsEvent: 1      podEvent: 102400      queryConfigMap: 10240      queryEndpoints: 1      queryNode: 10240      queryPersistentVolume: 1      queryPersistentVolumeClaim: 1      querySecret: 10240      queryService: 1      queryVolumeAttachment: 1      ruleEndpointsEvent: 1      rulesEvent: 1      secretEvent: 1      serviceEvent: 10240      updateNode: 15240      updateNodeStatus: 30000      updatePodStatus: 102400    enable: true    load:      deletePodWorkers: 5000      queryConfigMapWorkers: 1000      queryEndpointsWorkers: 1      queryNodeWorkers: 5000      queryPersistentVolumeClaimWorkers: 1      queryPersistentVolumeWorkers: 1      querySecretWorkers: 1000      queryServiceWorkers: 1      queryVolumeAttachmentWorkers: 1      updateNodeStatusWorkers: 10000      updateNodeWorkers: 5000      updatePodStatusWorkers: 20000      ServiceAccountTokenWorkers: 10000    nodeUpdateFrequency: 60  router:    enable: false  syncController:    enable: true复制
复制代码

Density 测试

测试执行


在使用 ClusterLoader2 进行性能测试之前,我们需要自己通过配置文件定义性能测试策略, 本次测试我们使用官方的 Kubernetes density 测试用例,使用的配置文件如下链接所示:


https://github.com/kubernetes/perf-tests/blob/master/clusterloader2/testing/density/config.yaml


Kubernetes 资源详细的配置如下表所示:



详细的测试方法和过程,可以参考


https://github.com/kubeedge/kubeedge/tree/master/build/edgemark

https://github.com/kubernetes/perf-tests/blob/master/clusterloader2/docs/GETTING_STARTED.md

测试结果


APIResponsivenessPrometheusSimple:

1、mutating API latency(threshold=1s):

2、Read-only API call latency(scope=resource, threshold=1s)

3、Read-only API call latency(scope=namespace, threshold=5s)

4、Read-only API call latency(scope=cluster, threshold=30s)

PodStartupLatency

注:延迟时间理论上应该总是大于零的,因为 kube-apiserver 不支持 RFC339NANO,导致时间戳精度只能达到秒级,故在延迟比较小的情况下,由于精度损失,ClusterLoader2 统计到的某些数值为 0。

结论及分析


在以上的测试结果中,API Call Latency 和 Pod Startup Latency 均符合 Kubernetes 社区定义的 SLIs/SLOs 指标。因此,Kubernetes + KubeEdge 集群能够稳定支持 100,000 边缘节点同时在线,并且管理超过 1,000,000 的 pod。在实际的生产环境中,因为网络安全、分区管理等相关问题,边缘节点和云端的网络并不会一直保持联通,会根据运维等需要按需连通网络,因此根据实际的边缘节点的在离线比例,单集群可以管理边缘节点的规模可以同比例的放大。此外,在 Kubernetes 控制面叠加使用数据分片技术,将不同的资源存储到相应的 etcd 存储,可以很容易突破更大的规模。

KubeEdge 如何实现大规模边缘节点接入

1)高效的云边消息通道


List-watch 是 Kubernetes 组件内部统一的异步消息处理机制,list-watch 由 list 和 watch 两部分组成。list 通过调用资源的 list API 获取资源,可以获取资源的全量数据,基于 HTTP 短链接实现;watch 通过调用资源的 watch API 监测资源变更事件,持续获取资源的增量变化数据,基于 HTTP 长链接和分块传输编码实现。在原生的 Kubernetes 中,每个 node 节点除了 list-watch node 本身、分配到本节点的 pod 以及全量的 service 元数据外,Kubelet 还必须 watch(默认)运行的 Pod 使用数据卷挂载的 Secret 和 ConfigMap,在大规模的集群中,随着节点和 pod 规模的增加,list-watch 的数量是非常大的,极大的增加了 Kube-apiserver 的负担。


KubeEdge 采用双向多路复用的边云消息通道,支持 websocket(默认)和 quic 协议,边缘侧 EdgeCore 主动发起和云端 CloudCore 连接,CloudCore list-watch Kubernetes 资源的变化,并通过云边双向通道主动将元数据下发至边缘测。上行元数据,如边缘侧节点状态和应用状态,EdgeCore 通过云边通道上传至 CloudCore,CloudCore 将接收到的元数据上报到 kube-apiserver。


CloudCore 统一负责上行和下行数据的汇聚处理,Kube-apiserver 只有来自 CloudCore 的数个 list-watch 请求,极大的降低了 Kube-apiserver 的负担,集群的性能得到了提高。


在同等节点和 pod 规模下,原生 Kubernetes kube-apiserver 的 memory 使用


Kubernetes + KubeEdge 场景下,kube-apiserver 的 memory 使用

2)可靠和增量的云边数据传输


在边缘网络拓扑复杂、网络通信质量低的场景下,云边通信面临着网络时延高、闪断闪连、频繁断连等问题。当云边网络恢复,边缘节点重新连接到云端时,边缘到云端会产生大量的全量 List 请求,从而对 Kube-apiserver 造成比较大的压力。在大规模场景下,将会给系统稳定性带来不小的挑战。KubeEdge 采用基于增量数据的云边推送模式,云端会记录成功发送到边缘侧的元数据版本号,当云边网络中断重新连接时,云端会从记录的元数据版本号开始增量发送,可以解决边缘重连或者 watch 失败时的重新全量 list 引发的 kube-apiserver 压力问题,相比原生 Kubernetes 架构可以提升系统稳定性,保障在高时延、低质量网络环境下正常工作。

3)边缘极致轻量+云边消息优化


KubeEdge 边缘侧 EdgeCore 对原生的 kubelet 进行了裁剪,去除了 in-tree volume、cloud-provider 等边缘场景下用不到的特性,压缩节点上报的状态信息,以及通过优化边缘代理软件资源占用,EdgeCore 最低开销只需 70MB 内存,最小可支持百兆边缘设备。同时,通过 WebSocket 通道统一管理所有的云边连接,以及对云边的消息合并,数据压缩等,大幅减少云边的通信压力,减轻了对管理面的访问压力,保障在高时延高抖动下仍可正常工作。


100,000 边缘节点接入下,云端 ELB 连接数为 100,000。



100,000 边缘节点以及超过 1,000,000 pod 场景下,云端 ELB 网络流入速率约为 3MB/s, 平均到每个边缘节点上行带宽约为 0.25Kbps。


下一步计划


目前我们只是测试了大规模场景下节点和 pod 的场景,下一步我们将对边缘设备 device、边云消息、边缘服务网格进行针对性测试。此外,针对边缘的一些特殊场景,如大规模节点网络中断重连、边缘网络高时延、闪断闪连等,我们需要引入新的 SLIs/SLOs 来衡量集群的服务质量,并进行进一步的大规模测试。


2022 年 6 月 25 日,CNCF KubeEdge 社区首届云原生边缘计算峰会(KubEdge Summit 2022)将在北京/线上同步进行。本次峰会,是面向开发者的一场技术盛会,聚合行业伙伴、开发者、业界大咖、技术专家,聚焦边缘计算最为关切的话题,激发一体化的边端云协同解决效能,让边缘计算的应用实践触手可及。KubeEdge 社区诚邀全球开发者、企业共话行业新机遇!



华为伙伴暨开发者大会 2022 火热来袭,重磅内容不容错过!

【精彩活动】

勇往直前·做全能开发者→12 场技术直播前瞻,8 大技术宝典高能输出,还有代码密室、知识竞赛等多轮神秘任务等你来挑战。即刻闯关,开启终极大奖!点击踏上全能开发者晋级之路吧!

【技术专题】

未来已来,2022 技术探秘→华为各领域的前沿技术、重磅开源项目、创新的应用实践,站在智能世界的入口,探索未来如何照进现实,干货满满点击了解


点击关注,第一时间了解华为云新鲜技术~

发布于: 刚刚阅读数: 4
用户头像

提供全面深入的云计算技术干货 2020.07.14 加入

华为云开发者社区,提供全面深入的云计算前景分析、丰富的技术干货、程序样例,分享华为云前沿资讯动态,方便开发者快速成长与发展,欢迎提问、互动,多方位了解云计算! 传送门:https://bbs.huaweicloud.com/

评论

发布
暂无评论
重磅!KubeEdge单集群突破10万边缘节点|云原生边缘计算峰会前瞻_云计算_华为云开发者联盟_InfoQ写作社区