开源之夏介绍​

开源之夏是由中国科学院软件研究所“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，培养和发掘更多优秀的开发者，促进优秀开源软件社区的蓬勃发展，助力开源软件供应链建设。学生通过远程线上协作方式，通过社区资深导师指导，参与到开源社区各组织项目开发中，并收获证书及最高12000元奖金。活动官网：https://summer-ospp.ac.cn/

开源之夏学生报名4月30日正式开启。KubeEdge云原生边缘计算社区已连续4年参与开源之夏，在本届开源之夏共带来 18个 精选课题，包括应用与 算法创新、AI大模型、机器学习、深度学习、系统研发与集成 等多个领域，由来自 高校、产业等资深学者、产业巨擘与技术领英组成的导师带队，为同学们引领迈向顶尖开发者之路。历届开源之夏KubeEdge社区课题聚焦行业前沿方向，为学生职业生涯增添浓墨重彩的一笔，多位入选组委会官方优秀学生。

为帮助学生更好地了解与选报课题，KubeEdge社区将于 5月8日、5月9日 开展课题线上宣讲会（详见下文），同学们不可错过。

KubeEdge云原生边缘计算社区​

KubeEdge[(https://github.com/kubeedge)]（https://github.com/kubeedge） 是 业界首个云原生边缘计算框架、云原生计算基金会内部唯一孵化级边缘计算开源项目 。KubeEdge 连接云原生和边缘计算生态，聚焦于提供一致的云边资源协同、数据协同、智能协同和应用协同体验，为边缘计算领域的应用提供更好的支持和解决方案，在全球已拥有 1500+ 贡献者和 100 贡献组织，在GitHub获得 7.3k+Stars和 2.1k+Forks。

KubeEdge社区持续开拓创新，目前已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式。

KubeEdge开源之夏2024课题​

项目1：支持边缘节点上报event​

• 项目编号：2498a0328
• 项目难度：进阶/Advanced
• 导师联系：鲍玥 baoyue2@huawei.com
• 项目简述：在目前的KubeEdge版本中，由于云边通道没有开发event相关接口，因此用户无法在云端获取到边缘pod的事件，尤其当pod状态异常时，用户必须要登录边缘节点获取pod事件，运维成本比较高。本项目希望能在云边通道增加event接口，支持边缘节点上报event，提高KubeEdge易用性与运维效率。
• 项目链接https://summer-ospp.ac.cn/org/prodetail/2498a0328?lang=zh&list=pro

项目2：基于KubeEdge的移动自组织网络边缘计算架构设计与实现​

• 项目编号：2498a0330
• 项目难度：进阶/Advanced
• 导师联系：赖俊宇（ Jason）laijy@uestc.edu.cn
• 项目简述：边缘计算（Edge Computing）与移动自组织网络（MANET）的结合，在应急等场景下有广泛的需求和良好的前景。本项目拟基于业界最流行的云原生云边协同计算架构KubeEdge，设计和实现面向无人机/无人系统集群等典型MANET场景的边缘计算架构，以更好支持MANET中的“云-边”协同、“边-边”协同计算能力。
• 项目链接： https://summer-ospp.ac.cn/org/prodetail/2498a0330?lang=zh&list=pro

项目3：使用 KubeEdge 实现基于深度学习的设备故障检测场景​

• 项目编号：2498a0332
• 项目难度：进阶/Advanced
• 导师联系：张红兵（Hongbing） hongbing.zhang@daocloud.io
• 项目简述：边缘计算作为人工智能的最后一公里，跟 AI 结合的应用场景也很广泛。在工业制造领域，边缘 AI 发挥着越来越重要的作用。场景：面向生产制造过程，刀具、冲压设备等声音检测，将老师傅听音多年经验迁移至算法模型，设备运行故障及时发现，提升设备巡检运维效率。1. 使用 KubeEdge 将故障检测模型应用下发至边缘节点，模型应用的资源消耗不超过4c8g；2. 运行模型应用，通过模拟modbus设备采集声音信号，模型应用能够通过设备声音识别出设备故障，控制边缘模拟灯泡的亮灭，并录制视频；3. （可选）将终端设备接入平台纳管。
• 项目链接： https://summer-ospp.ac.cn/org/prodetail/2498a0332?lang=zh&list=pro

项目4： Sedna 联合推理、联邦学习控制器优化​

• 项目编号：2498a0315
• 项目难度：进阶/Advanced
• 导师联系：唐明 ming.tang@daocloud.io
• 项目简述：Sedna是在KubeEdge SIG AI中孵化的一个边云协同AI项目。得益于KubeEdge提供的边云协同能力，Sedna可以实现跨边云的协同训练和协同推理能力，如联合推理、增量学习、联邦学习、终身学习等。Sedna支持目前广泛使用的AI框架，如TensorFlow/Pytorch/PaddlePaddle/MindSpore等，现有AI类应用可以无缝迁移到Sedna, 快速实现边云协同的训练和推理，可在降低成本、提升模型性能、保护数据隐私等方面获得提升。但是当前 Sedna 项目中联合推理、联邦学习控制器依然存在一些功能缺陷需要解决，主要表现在以下方面：联合推理：1、在创建联合推理任务或联邦学习任务以后，其生成的云和边的任务实例在出现故障或手动删除以后不会自动重建，即缺少自愈能力；2、联合推理任务CR在被删除以后，其生成的任务实例以及service配置不会被级联删除，该缺陷会导致后续再次创建联合推理任务失败。需要做的事情：对当前Sedna的联合推理和联邦学习控制器进行优化以解决上述功能缺陷。
• 项目链接： https://summer-ospp.ac.cn/org/prodetail/2498a0315?lang=zh&list=pro

项目5：大语言模型边侧基准测试套件：基于KubeEdge-Ianvs实现​

• 项目编号：2498a0318
• 项目难度：进阶
• 导师联系：胡创 hchuchuang@gmail.com
• 项目简述：由于模型尺寸和数据规模，LLMs往往在云端训练。同时由于大语言模型使用过程往往涉及商业机密或用户隐私，在边侧设备部署LLMs也逐渐成为了研究热点。LLMs量化技术正在使能LLMs边侧推理，然而，边侧设备的有限资源对云端训练LLMs的推理延迟和推理精度产生了影响。Ianvs旨在利用容器资源管理能力和边云协同能力对云端训练LLMs做边侧部署基准测试。
• 项目链接： https://summer-ospp.ac.cn/org/prodetail/2498a0318?lang=zh&list=pro

项目6：行业大模型基准测试套件：基于KubeEdge-Ianvs实现​

• 项目编号：2498a0319
• 项目难度：进阶
• 导师联系：郑子木 zimu.zheng@huawei.com
• 项目简述：大模型进入规模化应用时代，云已为大模型提供基础设施和服务，相关客户进一步提出包括个性化、数据合规、实时性等边缘侧的针对性应用需求，而云边协同的人工智能服务成为大趋势。但是，当前在产品定义、服务质量、服务资质、行业影响力等方面，存在通用竞争力和客户信任问题两大挑战，其症结在于，当前大模型基准测试聚焦对通用基础能力的考核，未能从行业角度牵引大模型应用。本项目从大模型产业以及云边协同人工智能角度、藉由行业应用反映大模型真实价值，以行业基准测试牵引大模型应用孵化。本项目基于协同人工智能基准测试套件KubeEdge-Ianvs，补充大模型测试工具接口，配套测试数据集，并构建政务等行业大模型测试套件。
• 项目链接： https://summer-ospp.ac.cn/org/prodetail/2498a0319?lang=zh&list=pro

项目7：代码大模型基准测试套件：基于 KubeEdge-Ianvs 构建​

• 项目编号：2498a0323
• 项目难度：进阶/Advanced
• 导师联系：韩洋（Brooks） yangbrooks.han@gmail.com
• 项目简述：大语言模型(LLMs) 在代码生成、自动编程、代码分析等任务中展现出了强大的能力。然而,这些模型通常基于通用的代码数据进行训练,无法充分利用软件工程师在实际工作中的协作和反馈。为了构建更加智能、高效的代码生态系统,有必要建立一个代码大模型数据集和评测基准,通过LLMs促进代码工程项目与软件工程师的紧密协作。本项目将基于开源的协同人工智能基准测试套件KubeEdge-Ianvs,构建一个面向LLMs的协作式代码智能体对齐数据集和评测基准。该数据集将包含软件工程师在开发过程中的行为轨迹、反馈和迭代过程,以及相关的代码版本和注释信息。通过这些数据,我们将设计评测指标和基准,以衡量LLMs在代码生成、推荐和分析等任务上的性能,并促进LLMs与软件工程师的协作。
• 项目链接： https://summer-ospp.ac.cn/org/prodetail/2498a0323?lang=zh&list=pro

项目8：大语言模型云边协同推理：基于KubeEdge-Ianvs实现​

• 项目编号：2498a0324
• 项目难度：进阶/Advanced
• 导师联系：胡时京 sjhu21@m.fudan.edu.cn
• 项目简述：目前以Llama2-70b，Qwen-72b为首的百亿、千亿参数规模的LLM模型大多只能部署在算力充足的云端提供推理服务。然而对于边缘终端的用户来说，一方面云端LLM服务面临推理速度慢、响应时延长的问题，另一方面将边缘的隐私数据上传云端处理可能面临隐私泄露的风险。同时在边缘环境可以部署的LLM模型（如TinyLlama-1.1b）推理准确率相较云端LLM有较大差距。因此，单独使用云端LLM或是边缘LLM都无法同时兼顾隐私保护、推理实时性和推理准确率，所以我们需要通过云边协同的策略结合云端LLM推理准确率高和边缘LLM推理隐私性强、速度快的优势，从而更好满足边缘用户的需求。
• 项目链接： https://summer-ospp.ac.cn/org/prodetail/2498a0324?lang=zh&list=pro

项目9：多语言mapper支持​

• 项目编号：2498a0316
• 项目难度：进阶/Advanced
• 导师联系：刘家伟（jiawei） jiawei.liu@daocloud.io
• 项目简述：所有的设备都可以通过厂商的驱动进行连接和控制，但是从设备拿到的信息需要转换成Kubeedge所理解的格式。Mapper就是Kubeedge和devices之间相互联系的应用程序。Mapper-framework 是一个框架，通过提供mapper运行时库和用于脚手架和代码生成的工具来生成新的mapper，使编写mapper变得更容易。目前社区有基于go语言实现的Mapper-framework，但其它语言(c、java、python)在实际业务中也有需求。需要做的事情：基于 (c、java、python)中至少一种语言实现。
• 项目链接： https://summer-ospp.ac.cn/org/prodetail/2498a0316?lang=zh&list=pro

项目10：KubeEdge边缘设备管理插件Mapper支持设备发现​

• 项目编号：2498a0331
• 项目难度：进阶/Advanced
• 导师联系：王彬丞 wangbincheng4@huawei.com
• 项目简述：目前KubeEdge使用Mapper插件管理边缘设备，能够将边缘设备以设备孪生的形式纳管至KubeEdge集群中，以云原生的方式对边缘设备进行生命周期管理。目前Mapper管理边缘设备时，需要用户实现并提交设备CRD文件至KubeEdge集群，Mapper根据CRD文件中的定义连接并管理设备。但部分情况下设备支持自动发现，例如Onvif网络摄像头设备。本项目计划为边缘设备管理插件Mapper提供设备发现功能，能够让Mapper自动扫描发现设备，并将其纳管至KubeEdge集群，简化用户操作流程。
• 项目链接： https://summer-ospp.ac.cn/org/prodetail/2498a0331?lang=zh&list=pro

项目11：大语言模型智能体（LLM Agent）个性化研究：基于KubeEdge-Ianvs云边协同终身学习​

• 项目编号：2498a0333
• 项目难度：进阶
• 导师联系：杨步芳 bfyang@link.cuhk.edu.hk
• 项目简述：大语言模型 (LLM)由于其卓越的推理能力和零样本能力受到广泛关注。其中，LLM Agent被视作LLM在物理世界中的一个重要落地方向。一个LLM Agent可以通过任务规划、工具调用、自我反思和任务执行，在物理世界中实现各种复杂的任务。本项目旨在通过利用云边协同框架，结合云端大模型的回答和边侧基于隐私数据生成的回答，实现个性化LLM Agent。我们计划基于KubeEdge-lanvs边云协同平台终身学习（知识库维护用户个性化的数据，终身学习本身可以支持不同边缘上有不同的模型）开发一个个性化LLM Agent。该系统能够结合云端大型LLM的泛化能力和边缘设备上的个性化用户数据，生成高质量、个性化的回答。
• 项目链接： https://summer-ospp.ac.cn/org/prodetail/2498a0333?lang=zh&list=pro

项目12：面向标注稀缺问题的联邦类增量学习研究：基于KubeEdge-Ianvs实现​

• 项目编号：2498a0334
• 项目难度：进阶
• 导师联系：陈浩锐 sechenhr@mail.scut.edu.cn
• 项目简述：在边缘环境中，数据随时间不断到达边缘设备，其所包含的类别随时间不断增加。受制于赋予标记所需的成本，这些数据之中仅有少量数据带有标注。为了利用这些数据优化模型，可以通过联邦学习的方式在边缘设备间进行协作分布式模型训练。然而，传统的联邦学习仅考虑在数据不变的场景中进行有监督学习，无法在动态变化且标注稀缺的数据集上进行训练。本项目旨在充分利用不同边缘设备上标注稀缺的流式数据，通过联邦学习的方式对模型进行分布式训练，从而缓解模型在类增量学习场景中的遗忘程度，提升模型的泛化能力。
• 项目链接： https://summer-ospp.ac.cn/org/prodetail/2498a0334?lang=zh&list=pro

项目13：面向高移动场景的异构多边协同神经网络推理​

• 项目编号：2498a0335
• 项目难度：进阶
• 导师联系：李蕴哲 yunzhe.li@sjtu.edu.cn
• 项目简述：在高速公路、高铁等高移动场景下，个人终端设备与基站等边缘设备连接不稳定，使得基于云的服务质量难以保证。然而，近几年，AI技术已经深入我们生活的方方面面，我们在高移动场景下也需要使用有高计算、存储需求且延迟敏感的AI技术，例如对话大模型等，这给边缘AI服务带来了新的挑战。本项目旨在利用边缘的多个异构计算单元（例如个人的手机、平板、手环、笔记本电脑等多个计算设备）进行协同的AI神经网络推理，使得AI任务可以利用更近的边缘设备以较低的延迟执行完毕，提高用户的使用体验。
• 项目链接： https://summer-ospp.ac.cn/org/prodetail/2498a0335?lang=zh&list=pro

项目14：批量节点接入​

• 项目编号：2498a0325
• 项目难度：基础/Basic
• 导师联系：侯玲玉（lingyu） lingyu.hou@daocloud.io
• 项目简述：KubeEdge将Kubernetes的能力延伸到了边缘场景中，为云和边缘之间的网络，应用部署和元数据同步提供基础架构支持。在边缘场景中，边端节点可能处于私网中，无法从云端访问边端节点，因此需要从边端节点接入云端，反向建立双向通信链路。目前kubeedge只支持了单个节点接入，但是实际业务场景中，可能存在大量的边端节点，单个接入非常麻烦，所以需要支持批量接入节点。需要做的事情：支持批量接入节点，可以借助脚本或者其它方式实现 。
• 项目链接： https://summer-ospp.ac.cn/org/prodetail/2498a0325?lang=zh&list=pro

项目15：提供一个通用的 MQTT 协议​

• 项目编号：2498a0326
• 项目难度：基础/Basic
• 导师联系：方志颖（Zhiying） zhiying.fang@daocloud.io
• 项目简述：在设备硬件市场中，MQTT协议是较为常见的设备协议。我们希望能有一个通用的MQTT Mapper来处理这些使用MQTT协议的设备，并且它能够支持常见的序列化方式（json、yaml 和 xml）中获取属性值。为了实现上述需求，我们需要您完成这些任务：1. 我们期望您使用最新的Mapper-Framework框架在 kubeedeg/mappers-go 项目中新增 MQTT 协议的Mapper；2. 我们期望这个Mapper能够从指定MQTT服务的Topic获取报文，并且能用常见序列化方式（json、xml）从报文中解析出属性值；3. （可选）我们期望您能提供一个更有扩展性的方案来从更多的自定义报文中解析属性值；
• 项目链接： https://summer-ospp.ac.cn/org/prodetail/2498a0326?lang=zh&list=pro

项目16：边缘节点支持OTA升级​

• 项目编号：2498a0327
• 项目难度：基础/Basic
• 导师联系：胡炜 wei.hu@daocloud.io
• 项目简述： 为了使边缘节点更为方便、迅速的得到升级，我们将一种远程升级方案OTA（Over-The-Air）引入到 KubeEdge 中，在OTA主要流程（制作升级包-> 下载升级包 -> 验签升级包 -> 固件更新）中，我们已经实现了大多步骤。我们发布版本会生成新的名为installation-package的镜像版本，然后通过NodeUpgradeJob CRD定义实现在边端节点获取镜像中的安装工具 keadm 执行升级命令升级边端节点。但在这个过程中如果黑客在节点中伪装镜像，这会导致 keadm 是不受信的，我们需要在keadm执行升级前，对镜像的摘要进行验证，也就是第三步验签升级包。并且在一些业务场景下（车联网、物联网）我们还需要提供一个可选项，使节点在等待收到一个有权限者确认后，再执行升级操作。为了实现上述需求，我们需要您完成这些任务：1. 我们期望您在边端节点升级前完成对升级镜像包摘要的验证；2. 我们期望您在NodeUpgradeJob CRD中新增一个参数，用于定义是否需要边端进行确认，如果需要，等待确认后再执行节点更新；3. 我们期望您在 MetaService 中提供确认边端节点升级的 AP I接口，并且在 keadm ctl 子命令中提供确认边端节点升级的命令操作；
• 项目链接： https://summer-ospp.ac.cn/org/prodetail/2498a0327?lang=zh&list=pro

项目17：KubeEdge支持边缘节点离线场景下对数据面资源的操作​

• 项目编号：2498a0352
• 项目难度：进阶/Advanced
• 导师联系：杨志佳 2938893385@qq.com
• 项目简述：边缘计算场景中，边缘节点常处于离线状态，用户需要在离线状态下查看本节点的数据面资源，比如pod，device,在某些场景下可能还需要对资源进行操作，比如重启pod，修改device instance等，同时在离线场景中开发一些资源操作的API供用户或上层应用。①在kubeedge1.17中将支持边缘节点离线时对pod的重启和状态查看，还需要进一步扩展离线状态下数据面操作的功能，比如对pod的logs/exec/describe ②离线状态下支持对device资源查看，device资源的修改，上线后与云端自动同步 ③提供离线状态下操作数据面资源的API，供上层应用使用 ④保证边缘节点从离线到在线后，边缘数据同步到云
• 项目链接： https://summer-ospp.ac.cn/org/prodetail/2498a0352?lang=zh&list=pro

项目18：Windows非WSL虚拟化节点环境，改造mapper支持 Windows节点运行​

• 项目编号：2498a0428
• 项目难度：进阶
• 导师联系：吕涛涛（ttlv） steven.lv@nio.com
• 项目简述：汽车试验台架，Windows的环境下，devops自动化流水线，不开启WSL虚拟化的Windows上位机环境，将边缘的Windows节点做为边缘设备纳管的同时，依托云端的device和deviceModel的CRD定义和edgecore的devicetwin以及evenbus模块，将边缘侧的mapper做为统一的业务处理模块，实现批量下发测试多业务场景的测试任务并且实时反馈测试结果的需求。
• 项目链接： https://summer-ospp.ac.cn/org/prodetail/2498a0428?lang=zh&list=pro

如何报名开源之夏课题？​

报名对象​

• 本活动面向年满 18 周岁的高校在校学生。
• 暑期即将毕业的学生，只要申请时学生证处在有效期内，就可以报名活动。
• 中国籍学生参与活动时需提供身份证、学生证、教育部学籍在线验证报告（学信网）或在读证明。
• 外籍学生参与活动时需提供护照，同时提供录取通知书、学生卡、在读证明等文件用于证明学生身份。

报名时间​

4月30日-6月4日 ，学生可在系统（https://summer-ospp.ac.cn/） 注册账号并填写个人资料，资料审核通过的学生可在系统提交项目申请书。注：个人资料应在06/03 15:00 UTC+8 前完成填写并提交审核，项目申请书应在06/04 18:00 UTC+8 前完成提交。

我可以在开源之夏获得什么？​

• 结识开源界小伙伴和技术大牛
• 获得社区导师的专业指导，与开源项目开发者深度交流
• 丰富项目实践经验，提升项目开发技能
• 为学习方向提供参考，为职业发展积累人脉
• 通过结项考核的学生将获得结项奖金和结项证书（基础难度税前8000元RMB，进阶难度税前12000元RMB），更有机会获选优秀学生

如何快速选定项目​

对KubeEdge社区开源之夏课题感兴趣的同学，可以 通过本文上方导师邮箱，及时联系导师沟通锁定课题。为方便同学们更快了解与找到最适合自己的课题方向，KubeEdge社区将于 5月8日、5月9日特别组织18个课题线上宣讲会，大咖导师空降，为你娓娓道来，欢迎同学们通过以下方式参会：https://zoom.us/my/kubeedge

北京时间2024年1月23日，KubeEdge发布1.16版本。新版本新增多个增强功能，在集群升级、集群易用性、边缘设备管理等方面均有大幅提升。

KubeEdge v1.16 新增特性：​

• 集群升级：支持云边组件自动化升级
• 支持边缘节点的镜像预下载
• 支持使用Keadm安装Windows边缘节点
• 增加多种容器运行时的兼容性测试
• EdgeApplication中支持更多Deployment对象字段的Override
• 支持基于Mapper-Framework的Mapper升级
• DMI数据面内置集成Redis与TDEngine数据库
• 基于Mapper-Framework的USB-Camera Mapper实现
• 易用性提升：基于Keadm的部署能力增强
• 升级K8s依赖到v1.27

新特性概览​

集群升级：支持云边组件自动化升级​

随着KubeEdge社区的持续发展，社区版本不断迭代；用户环境版本升级的诉求亟需解决。针对升级步骤难度大，边缘节点重复工作多的问题，v1.16.0版本的 KubeEdge 支持了云边组件的自动化升级。用户可以通过Keadm工具一键化升级云端，并且可以通过创建相应的Kubernetes API，批量升级边缘节点。

• 云端升级

  云端升级指令使用了三级命令与边端升级进行了区分，指令提供了让用户使用更便捷的方式来对云端的KubeEdge组件进行升级。当前版本升级完成后会打印ConfigMap历史配置，如果用户手动修改过ConfigMap，用户可以选择通过历史配置信息来还原配置文件。我们可以通过help参数查看指令的指导信息：

  keadm upgrade cloud --help
  Upgrade the cloud components to the desired version, it uses helm to upgrade the installed release of cloudcore chart, which includes all the cloud components
  
  Usage:
    keadm upgrade cloud [flags]
  
  Flags:
        --advertise-address string    Please set the same value as when you installed it, this value is only used to generate the configuration and does not regenerate the certificate. eg: 10.10.102.78,10.10.102.79
    -d, --dry-run                     Print the generated k8s resources on the stdout, not actual execute. Always use in debug mode
        --external-helm-root string   Add external helm root path to keadm
        --force                       Forced upgrading the cloud components without waiting
    -h, --help                        help for cloud
        --kube-config string          Use this key to update kube-config path, eg: $HOME/.kube/config (default "/root/.kube/config")
        --kubeedge-version string     Use this key to set the upgrade image tag
        --print-final-values          Print the final values configuration for debuging
        --profile string              Sets profile on the command line. If '--values' is specified, this is ignored
        --reuse-values                reuse the last release's values and merge in any overrides from the command line via --set and -f.
        --set stringArray             Sets values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)
        --values stringArray          specify values in a YAML file (can specify multiple)
  

  升级指令样例：

  keadm upgrade cloud --advertise-address=<init时设置的值> --kubeedge-version=v1.16.0
  

• 边端升级

  v1.16.0版本的KubeEdge支持通过NodeUpgradeJob的Kubernetes API进行边缘节点的一键化、批量升级。API支持边缘节点的升级预检查、并发升级、失败阈值、超时处理等功能。对此，KubeEdge支持了云边任务框架。社区开发者将无需关注任务控制、状态上报等逻辑实现，只需聚焦云边任务功能本身。

  升级API样例：

  apiVersion: operations.kubeedge.io/v1alpha1
  kind: NodeUpgradeJob
  metadata:
    name: upgrade-example
    labels:
      description: upgrade-label
  spec:
    version: "v1.16.0"
    checkItems:
      - "cpu"
      - "mem"
      - "disk"
    failureTolerate: "0.3"
    concurrency: 2
    timeoutSeconds: 180
    labelSelector:
      matchLabels:
        "node-role.kubernetes.io/edge": ""
        node-role.kubernetes.io/agent: ""
  

• 兼容测试

  KubeEdge社区提供了完备了版本兼容性测试，用户在升级时仅需要保证云边版本差异不超过2个版本，就可以避免升级期间云边版本不一致带来的问题。

更多信息可参考:

https://github.com/kubeedge/kubeedge/pull/5330 https://github.com/kubeedge/kubeedge/pull/5229 https://github.com/kubeedge/kubeedge/pull/5289

支持边缘节点的镜像预下载​

新版本引入了镜像预下载新特性，用户可以通过ImagePrePullJob的Kubernetes API提前在边缘节点上加载镜像，该特性支持在批量边缘节点或节点组中预下载多个镜像，帮助减少加载镜像在应用部署或更新过程，尤其是大规模场景中，带来的失败率高、效率低下等问题。

镜像预下载API示例：

apiVersion: operations.kubeedge.io/v1alpha1
kind: ImagePrePullJob
metadata:
  name: imageprepull-example
  labels:
    description:ImagePrePullLabel
spec:
  imagePrePullTemplate：
    images:
      - image1
      - image2
    nodes：
      - edgenode1
      - edgenode2
    checkItems:
      - "disk"
    failureTolerate: "0.3"
    concurrency: 2
    timeoutSeconds: 180
    retryTimes: 1

更多信息可参考:

https://github.com/kubeedge/kubeedge/pull/5310 https://github.com/kubeedge/kubeedge/pull/5331

支持使用Keadm安装Windows边缘节点​

KubeEdge 1.15版本实现了在Windows上运行边缘节点，在新版本中，我们支持使用安装工具Keadm直接安装Windows边缘节点，操作命令与Linux边缘节点相同，简化了边缘节点的安装步骤。

更多信息可参考:

https://github.com/kubeedge/kubeedge/pull/4968

增加多种容器运行时的兼容性测试​

新版本中新增了多种容器运行时的兼容性测试，目前已集成了containerd，docker，isulad和cri-o 4种主流容器运行时，保障KubeEdge版本发布质量，用户在安装容器运行时过程中也可以参考该PR中的适配安装脚本。

更多信息可参考:

https://github.com/kubeedge/kubeedge/pull/5321

EdgeApplication中支持更多Deployment对象字段的Override​

在新版本中，我们扩展了EdgeApplication中的差异化配置项（overriders），主要的扩展有环境变量、命令参数和资源。当您不同区域的节点组环境需要链接不同的中间件时，就可以使用环境变量（env）或者命令参数（command, args）去重写中间件的链接信息。或者当您不同区域的节点资源不一致时，也可以使用资源配置（resources）去重写cpu和内存的配置。

更多信息可参考:

https://github.com/kubeedge/kubeedge/pull/5262 https://github.com/kubeedge/kubeedge/pull/5370

支持基于Mapper-Framework的Mapper升级​

1.16版本中，基于Mapper开发框架Mapper-Framework构建了Mapper组件的升级能力。新框架生成的Mapper工程以依赖引用的方式导入原有Mapper-Framework的部分功能，在需要升级时，用户能够以升级依赖版本的方式完成，简化Mapper升级流程。

• Mapper-Framework代码解耦:

  1.16版本中将Mapper-Framework中的代码解耦为用户层和业务层。用户层功能包括设备驱动及与之强相关的部分管理面数据面能力，仍会随Mapper-Framework生成在用户Mapper工程中，用户可根据实际情况修改。业务层功能包括Mapper向云端注册、云端下发Device列表等能力，会存放在kubeedge/mapper-framework子库中。

• Mapper升级框架:

  1.16版本Mapper-Framework生成的用户Mapper工程通过依赖引用的方式使用kubeedge/mapper-framework子库中业务层功能，实现完整的设备管理功能。后续用户能够通过升级依赖版本的方式达到升级Mapper的目的，不再需要手动修改大范围代码。

更多信息可参考:

https://github.com/kubeedge/kubeedge/pull/5308 https://github.com/kubeedge/kubeedge/pull/5326

DMI数据面内置集成Redis与TDEngine数据库​

1.16版本中进一步增强DMI数据面中向用户数据库推送数据的能力，增加Redis与TDengine数据库作为内置数据库。用户能够直接在device-instance配置文件中定义相关字段，实现Mapper自动向Redis与TDengine数据库推送设备数据的功能，相关数据库字段定义为：

type DBMethodRedis struct {
    // RedisClientConfig of redis database
    // +optional
    RedisClientConfig *RedisClientConfig `json:"redisClientConfig,omitempty"`
}
type RedisClientConfig struct {
    // Addr of Redis database
    // +optional
    Addr string `json:"addr,omitempty"`
    // Db of Redis database
    // +optional
    DB int `json:"db,omitempty"`
    // Poolsize of Redis database
    // +optional
    Poolsize int `json:"poolsize,omitempty"`
    // MinIdleConns of Redis database
    // +optional
    MinIdleConns int `json:"minIdleConns,omitempty"`
}

type DBMethodTDEngine struct {
    // tdengineClientConfig of tdengine database
    // +optional
    TDEngineClientConfig *TDEngineClientConfig `json:"TDEngineClientConfig,omitempty"`
}
type TDEngineClientConfig struct {
    // addr of tdEngine database
    // +optional
    Addr string `json:"addr,omitempty"`
    // dbname of tdEngine database
    // +optional
    DBName string `json:"dbName,omitempty"`
}

更多信息可参考:

https://github.com/kubeedge/kubeedge/pull/5064

基于Mapper-Framework的USB-Camera Mapper实现​

基于KubeEdge的Mapper-Framework，新版本提供了USB-Camera的Mapper样例，该Mapper根据USB协议的Camera开发，用户可根据该样例和Mapper-Framework更轻松地开发具体业务相关的Mapper。

在样例中提供了helm chart包，用户可以通过修改usbmapper-chart/values.yaml部署UBS-Camera Mapper，主要添加USB-Camera的设备文件, nodeName, USB-Camera的副本数，其余配置修改可根据具体情况而定，通过样例目录中的Dockerfile制作Mapper镜像。

global:
  replicaCounts:
......
    cameraUsbMapper:
      replicaCount: 2  #USB-Camera的副本数
      namespace: default
......
  nodeSelectorAndDevPath:
    mapper:
       - edgeNode: "edgenode02"  #USB-Camera连接的缘节点nodeName
         devPath: "/dev/video0"  #USB-Camera的设备文件
       - edgeNode: "edgenode1"
         devPath: "/dev/video17"
......

USB-Camera Mapper的部署命令如下：

helm install usbmapper-chart ./usbmapper-chart

更多信息可参考:

https://github.com/kubeedge/mappers-go/pull/122

易用性提升：基于Keadm的部署能力增强​

• 添加云边通信协议配置参数

  在KubeEdge v1.16.0中，使用keadm join边缘节点时，支持使用--hub-protocol配置云边通信协议。目前KubeEdge支持websocket和quic两种通信协议，默认为websocket协议。

  命令示例：

  keadm join --cloudcore-ipport <云节点ip>:10001 --hub-protocol=quic --kubeedge-version=v1.16.0 --token=xxxxxxxx
  

  说明：当--hub-protocol设置为quic时，需要将--cloudcore-ipport的端口设置为10001，并需在CloudCore的ConfigMap中打开quic开关，即设置modules.quic.enable为true。

  操作示例：使用kubectl edit cm -n kubeedge cloudcore，将quic的enable属性设置成true，保存修改后重启CloudCore的pod。

  modules：
  ......
    quic:
      address: 0.0.0.0
      enable: true  #quic协议开关
      maxIncomingStreams: 10000
      port: 10001
  

  更多信息可参考:

  https://github.com/kubeedge/kubeedge/pull/5156

• keadm join与CNI插件解耦

  在新版本中，keadm join边缘节点时，不需要再提前安装CNI插件，已将边缘节点的部署与CNI插件解耦。同时该功能已同步到v1.12及更高版本，欢迎用户使用新版本或升级老版本。

  说明：如果部署在边缘节点上的应用程序需要使用容器网络，则在部署完edgecore后仍然需要安装CNI插件。

  更多信息可参考:

  https://github.com/kubeedge/kubeedge/pull/5196

升级K8s依赖到v1.27​

新版本将依赖的Kubernetes版本升级到v1.27.7，您可以在云和边缘使用新版本的特性。

更多信息可参考:

https://github.com/kubeedge/kubeedge/pull/5121

版本升级注意事项​

新版本我们使用DaemonSet来管理边端的MQTT服务Eclipse Mosquitto了，我们能够通过云端Helm Values配置来设置是否要开启MQTT服务。使用DaemonSet管理MQTT后，我们可以方便的对边端MQTT进行统一管理，比如我们可以通过修改DaemonSet的配置将边端MQTT替换成EMQX。

但是如果您是从老版本升级到最新版本，则需要考虑版本兼容问题，同时使用原本由静态Pod管理的MQTT和使用新的DaemonSet管理的MQTT会产生端口冲突。兼容操作步骤参考：

1. 您可以在云端执行命令，将旧的边缘节点都打上自定义标签

kubectl label nodes --selector=node-role.kubernetes.io/edge without-mqtt-daemonset=""

2. 您可以修改MQTT DaemonSet的节点亲和性

nodeAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
    nodeSelectorTerms:
      - matchExpressions:
          - ...
          - key: without-mqtt-daemonset
            operator: Exists

3. 将节点MQTT改为由DaemonSet管理

# ------ 边端 ------
# 修改/lib/systemd/system/edgecore.service，将环境变量DEPLOY_MQTT_CONTAINER设置成false
# 这步可以放在更新EdgeCore前修改，这样就不用重启EdgeCore了
sed -i '/DEPLOY_MQTT_CONTAINER=/s/true/false/' /etc/systemd/system/edgecore.service

# 停止EdgeCore
systemctl daemon-reload && systemctl stop edgecore

# 删除MQTT容器，Containerd可以使用nerdctl替换docker
docker ps -a | grep mqtt-kubeedge | awk '{print $1}' | xargs docker rm -f

# 启动EdgeCore
systemctl start edgecore

# ------ 云端 ------
# 删除节点标签
kubectl label nodes <NODE_NAME> without-mqtt-daemonset

新版本的keadm join命令会隐藏with-mqtt参数，并且将默认值设置成false，如果您还想使用静态Pod管理MQTT，您仍然可以设置参数--with-mqtt来使其生效。with-mqtt参数在v1.18版本中将会被移除。

KubeEdge 社区已于 2022 年 7 月份完成整个 KubeEdge 项目的第三方安全审计，已发布云原生边缘计算安全威胁分析和防护白皮书，并根据安全威胁模型和安全审计的建议，对 KubeEdge 软件供应链进行持续安全加固。经过社区的不断努力，我们很兴奋地宣布，在 2023 年 1 月 18 日发布的 v1.13.0 版本中，KubeEdge 项目已达到 SLSA L3 等级（包括二进制和容器镜像构件），成为 CNCF 社区首个达到 SLSA L3 等级的项目。

为什么说达到 SLSA L3 等级对 KubeEdge 项目十分重要​

软件供应链完整性攻击（对软件包的未经授权的修改）在过去三年中呈上升趋势，KubeEdge 实现 SLSA L3 等级标准后，可以端到端的从源码构建到发布流程进行安全加固，保障用户获取到的二进制或容器镜像产物不被恶意篡改。基于 SLSA 安全框架，可以潜在地加强软件构件的完整性。SLSA 提供端到端的指导原则，可以作为软件的一组防御措施，并防止对组成软件产品的软件包的篡改或任何类型的未经授权的修改。采用 SLSA 框架可以保护项目软件免受常见的供应链攻击。

关于 SLSA​

什么是 SLSA（Supply chain Levels for Software Artifacts 软件构件的供应链级别）：

Google 提出的用于保证整个软件供应链完整性的框架 SLSA，是一套基于行业共识的安全准则，也是一个安全框架、一份标准和控制清单，用于防止篡改、提高完整性以及保护项目、业务或企业中的软件包和基础设施。它不是一个单一的工具，而是一个逐步采用的大纲，以防止工件被篡改和被篡改的工件被使用，并在更高层次上强化构成供应链的平台。生产商遵循 SLSA 准则使他们的软件更加安全，用户则根据软件包的安全状况来做出决策。

截止目前，SLSA 标准处于 alpha 阶段，相关的定义可能会发生变化。

下图描述了软件供应链中已知的攻击点。更多详细描述，可参考https://slsa.dev/

SLSA 框架引入了许多新的工具和概念，例如：

• Artifact（软件制品）：由构建流水线生成的任何制品文件，如容器镜像、语言包、编译的二进制文件等；
• Provenance （来源证据链）： 构建的元数据包括构建过程、构建源和依赖关系；
• Digest （数字摘要）：加密哈希函数的结果，该函数生成唯一标识工件的固定大小值，例如容器镜像的 SHA-256 哈希；
• Attestation （证书）：一个加密签名的文件，记录当时生成软件产物的来源；
• Immutable references（不可变引用-一种标识符）：，保证始终指向相同的、不可变的软件制品，如特定的容器图像或语言包；
• Build integrity（构建完整性）：验证构建流水线的输出完整性。

KubeEdge 项目如何达到 SLSA L3​

截止目前，SLSA 评估等级共分为 4 个等级 L1~L4，安全性由低到高，每个等级有不同的达标要求，详细的达标要求可参考 SLSA 详细标准（https://slsa.dev/spec/v0.1/requirements）。

在去年 7 月发布的第三方安全审计报告中，KubeEdge 项目在软件供应链 SLSA Provenance 维度暂未达到 L3 等级，经过 SIG-Security 的持续安全加固，在今年 1 月发布的 v1.13.0 版本中，KubeEdge 项目在所有的 SLSA 维度中均达到 L3 等级。以下表格展示了 KubeEdge 在Source、Build、Provenance、Common中的达标情况（Y 表示 KubeEdge 已达标，空格表示 SLSA 在该等级下未要求）。

SLSA 评估表格及达标情况

本章节将着重介绍 KubeEdge 如何达成 SLSA L3 等级在 Build、Provenance 维度的要求。Build/Provenance Requirements 及 KubeEdge 相应的解决方案如下。

Build Requirements：

a) 通过脚本构建：所有的构建步骤都是通过脚本自动化执行。

b) 通过构建服务进行构建：所有的构建步骤由构建服务完成，不在开发者本地环境。构建服务如 GitHub Actions、第三方云平台提供的构建服务等。

c) 作为源码构建：构建服务执行的构建定义文件和配置文件来源于版本控制系统中的文本文件，并且是可验证的。

d) 构建环境临时性：构建服务确保构建步骤在临时环境中运行，例如容器或 VM，仅为此构建提供，而不是复用先前的构建 。

e) 构建的隔离性：构建服务确保构建步骤在隔离的环境中运行，不受其他构建实例(无论是先前的还是并发的)的影响。

f) 无用户自定义参数：除了构建入口点和初始源配置之外，构建输出不会受到用户参数的影响。换句话说，构建完全是通过构建脚本定义的，而不是其他。

g) 封闭性：所有可传递的构建步骤、源和依赖项都使用不可变引用预先完全声明，并且构建步骤在没有网络访问的情况下运行。

解决方案：

KubeEdge 项目所有的构建流程均在 GitHub 上由脚本自动化执行，GitHub Actions 作为构建服务（相关的定义文件和配置文件保存在.github/workflows 目录下），可保障构建过程的可回溯、可验证以及构建环境的临时性、隔离性、构建参数和依赖项不可篡改。

Provenance Requirements：

a) 可用性：Provenance 通过用户可接受的格式提供。应该满足 SLSA Provenance 格式，但如果生产商和用户都同意，并且满足所有其他要求，可以使用另一种格式。

b) 可验证：Provenance 的真实性和完整性可以由用户验证。这应该通过来自私钥的数字签名来实现，只有生成 Provenance 的服务才能访问私钥。

c) 通过构建服务生成：Provenance 中的数据必须从构建服务中获得。

d) 不可伪造：构建服务的用户不能伪造 Provenance。

e) 第三方依赖的完整性：Provenance 记录运行构建步骤时可用的所有构建依赖项。包括构建的机器、VM 或容器的初始状态。

解决方案：

在 KubeEdge 版本发布的产物中，包括二进制文件和容器镜像 2 种格式，通过集成 SLSA 官方的 GitHub 构建项目 slsa-github-generator 来实现 SLSA L3 等级。

在 KubeEdge 版本发布的流程（.github/workflows/release.yml）中，集成了 slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml 和 slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml，可保障构建和发布产物（包括二进制文件和容器镜像）的流程满足 SLSA L3 等级的要求。

更多关于 slsa-github-generator 的详细说明请见https://github.com/slsa-framework/slsa-github-generator

关于 Provenance​

Provenance 是构建的元数据包括构建过程、构建源和依赖关系，是软件构建和发布执行流程的一种证明，并且是可以被验证的，包括构建的源码仓库、代码分支、配置文件等信息。在 SLSA L3 级别，Provenance 内容是真实的、防篡改的，并且不会被项目维护者更改。二进制发布产物的 Provenance 文件随发布软件包一起发布，名称为 multiple.intoto.jsonl，容器镜像的 Provenance 文件随镜像文件一起上传到 KubeEdge dockerhub 公开仓库中。具体的 Provenance 格式说明，请参考https://github.com/slsa-framework/slsa-github-generator/blob/main/internal/builders/generic/README.md#provenance-format。

如何校验 KubeEdge 发布产物是否满足 SLSA L3 等级​

详细步骤描述请见https://github.com/kubeedge/kubeedge/pull/4285

校验示例如下：

$ COSIGN_EXPERIMENTAL=1 cosign verify-attestation --type slsaprovenance --policy policy.cue kubeedge/cloudcore:v1.13.0

{
    "_type": "https://in-toto.io/Statement/v0.1",
    "predicateType": "https://slsa.dev/provenance/v0.2",
    "subject": [{
            "name": "index.docker.io/kubeedge/cloudcore",
            "digest": {
                "sha256": "825642e63ab5b924e2fa0661cd14d544d0be151c4bdba6f3f42796c977fbe211"
            }
        }
    ],
    "predicate": {
        "builder": {
            "id": "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@refs/tags/v1.4.0"
        },
        "buildType": "https://github.com/slsa-framework/slsa-github-generator/container@v1",
        "invocation": {
            "configSource": {
                "uri": "git+https://github.com/kubeedge/kubeedge@refs/tags/v1.13.0",
                "digest": {
                    "sha1": "ee357a0d5341241143e88d45df99fde865c987de"
                },
                "entryPoint": ".github/workflows/release.yml"
            },
...

SLSA GitHub generator 签名和验证原理​

使用 OpenID Connect (OIDC) 向外部服务 (Sigstore) 证明工作流的身份。OpenID Connect (OIDC) 是身份提供商在网络上使用的标准，用于为第三方证明用户的身份。 GitHub 现在在其工作流程中支持 OIDC。每次运行工作流程时，运行者都可以从 GitHub 的 OIDC 提供商处创建一个唯一的 JWT 令牌。令牌包含工作流身份的可验证信息，包括调用者存储库、提交哈希、触发器以及当前（可重用）工作流路径和引用。

使用 OIDC，工作流向 Sigstore 的 Fulcio 根证书颁发机构证明其身份，后者充当外部验证服务。 Fulcio 签署了一份短期证书，证明运行器中生成的临时签名密钥并将其与工作负载身份相关联。签署出处的记录保存在 Sigstore 的透明日志 Rekor 中。用户可以使用签名证书作为信任方来验证来源是否经过身份验证且不可伪造；它必须是在受信任的构建器中创建的。流程图如下所示。

值得一提的是，SLSA GitHub generator 获得 sigstore 社区 2022 年度徽章 Best User Adopter。

总结​

SLSA 在 KubeEdge 项目软件供应链安全中发挥着重要作用。基于 sigstore 社区提供的能力，从源码到发布产物，对软件供应链端到端的整个流程进行签名和校验，确保 KubeEdge 软件供应链安全。

相关参考：

https://slsa.dev/

https://www.sigstore.dev/

https://github.com/slsa-framework/slsa-github-generator

https://slsa.dev/blog/2022/08/slsa-github-workflows-generic-ga

https://security.googleblog.com/2022/04/improving-software-supply-chain.html

https://blog.sigstore.dev/sigstore-november-roundup-8a852cec10fc/

Abstract​

The population of KubeEdge brings in community interests in the scalability and scale of KubeEdge. Now, Kubernetes clusters powered by KubeEdge, as fully tested, can stably support 100,000 concurrent edge nodes and manage more than one million pods. This report introduces the metrics used in the test, the test procedure, and the method to connect to an ocean of edge nodes.

Background​

Fast growing technologies, such as 5G networks, industrial Internet, and AI, are giving edge computing an important role in driving digital transformation. Cities, transportation, healthcare, manufacturing, and many other fields are becoming smart thanks to edge computing. According to Gartner, by 2023, the number of intelligent edge devices may be more than 20 times that of traditional IT devices. By 2028, the embedding of sensors, storage, computing, and advanced AI functions in edge devices will grow steadily. IoT devices are of various types and in large quantities. The increasing connected IoT devices are challenging management and O&M.

At the same time, users in the KubeEdge community are expecting large-scale edge deployment. There are already some successful use cases for KubeEdge. In unmanned toll stations across China, there are nearly 100,000 edge nodes and more than 500,000 edge applications in this project, and the numbers keep growing. Another case is a vehicle-cloud collaboration platform, the industry-first cloud-edge-device system. It enables fast software upgrade and iteration for software-defined vehicles. On this platform, each vehicle is connected as an edge node, and the number of edge nodes will reach millions.

Introduction to KubeEdge​

KubeEdge is the industry's first cloud native edge computing framework designed for edge-cloud collaboration. Complementing Kubernetes for container orchestration and scheduling, KubeEdge allows applications, resources, data, and devices to collaborate between edges and the cloud. Devices, edges, and the cloud are now fully connected in edge computing.

In the KubeEdge architecture, the cloud is a unified control plane, which includes native Kubernetes management components and KubeEdge-developed CloudCore components. It listens to cloud resource changes and provides reliable, efficient cloud-edge messaging. At the edge side lie the EdgeCore components, including Edged, MetaManager, and EdgeHub. They receive messages from the cloud and manage the lifecycle of containers. The device mapper and event bus are responsible for device access.

Based on the Kubernetes control plane, KubeEdge allows nodes to be deployed more remotely and thereby extends edge-cloud collaboration. Kubernetes supports 5,000 nodes and 150,000 pods, which are far from enough for edge computing in Internet of Everything (IoE). The access of a large number of edge devices demands a scalable, centralized edge computing platform. To help users cost less and manage more in an easier way, KubeEdge, fully compatible with Kubernetes, optimizes the cloud-edge messaging and provides access support for mass edge nodes.

SLIs/SLOs​

Scalability and performance are important features of Kubernetes clusters. Before performing the large-scale performance test, we need to define the measurement metrics. The Kubernetes community defines the following SLIs (Service Level Indicators) and SLOs (Service Level Objectives) to measure the cluster service quality.

1. API Call Latency

2. Pod Startup Latency

The community also defines indicators such as in-cluster network programming latency (latency for Service updates or changes in ready pods to be reflected to iptables/IPVS rules), in-cluster network latency, DNS programming latency (latency for Service updates or changes in ready pods to be reflected to the DNS server), and DNS latency. These indicators have not yet been quantified. This test was conducted to satisfy all SLIs/SLOs in the official state.

Kubernetes Scalability Dimensions and Thresholds​

Kubernetes scalability does not just mean the number of nodes (Scalability != #Nodes). Other dimensions include the number of namespaces, pods, Services, secrets, and ConfigMaps. Configurations that Kubernetes supports create the Scalability Envelope (which keeps evolving):

Obviously, it is impossible for a Kubernetes cluster to expand resource objects without limitation while satisfying SLIs/SLOs. Therefore, the industry defines the upper limits of Kubernetes resource objects.

1. Pods/node 30
2. Backends <= 50k & Services <= 10k & Backends/service <= 250
3. Pod churn 20/s
4. Secret & configmap/node 30
5. Namespaces <= 10k & Pods <= 150k & Pods/namespace <= 3k
6. ​    …..

Dimensions are sometimes not independent. As you move farther along one dimension, your cross-section wrt other dimensions gets smaller. For example, if 5000 nodes are expanded to 10,000 nodes, the specifications of other dimensions will be affected. A heavy workload is required if all scenarios are tested. In this test, we focus on the typical scenarios. We manage to host 100k edge nodes and 1000k pods in a single cluster while satisfying the SLIs/SLOs.

Test Tools​

ClusterLoader2​

ClusterLoader2 is an open source Kubernetes cluster performance test tool. It can test the Kubernetes SLIs/SLOs to check whether the cluster meets the service quality standards. It also visualizes data for locating cluster problems and optimizing cluster performance. After the test, users get a performance report with detailed test results.

Clusterloader2 performance metrics:

• APIResponsivenessPrometheusSimple
• APIResponsivenessPrometheus
• CPUProfile
• EtcdMetrics
• MemoryProfile
• MetricsForE2E
• PodStartupLatency
• ResourceUsageSummary
• SchedulingMetrics
• SchedulingThroughput
• WaitForControlledPodsRunning
• WaitForRunningPods

Edgemark​

Edgemark is a performance test tool similar to Kubemark. It simulates deploying KubeEdge edge nodes in the KubeEdge cluster scalability test to build ultra-large Kubernetes clusters, powered by KubeEdge, with limited resources. The objective is to expose the cluster control plane downsides that occur only in large-scale deployments. The following figure illustrates the Edgemark deployment:

• K8s master: the master node of the Kubernetes cluster
• Edgemark master: the master node of the simulated Kubernetes cluster
• CloudCore: the KubeEdge cloud management component, which is responsible for edge node access
• hollow pod: a pod started in the actual cluster. It registers with the Edgemark master as a virtual edge node by starting Edgemark in it. The Edgemark master can schedule pods to this virtual edge node.
• hollow edgeNode: a virtual node in the simulated cluster, registered from a hollow pod

Cluster Deployment Scheme for the Test​

The Kubernetes control plane is deployed with one master node. The etcd, kube-apiserver, kube-scheduler, and kube-controller are deployed as single-instance. The KubeEdge control plane is deployed with five CloudCore instances and connects to the kube-apiserver through the IP address of the master node. Hollow EdgeNodes are exposed by a load balancer and randomly connect to a CloudCore instance based on the round-robin policy of the load balancer.

Test Environment Information​

Control Plane OS Version

CentOS 7.9 64bit 3.10.0-1160.15.2.el7.x86_64

Kubernetes Version

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"

KubeEdge Version

KubeEdge v1.11.0-alpha.0

Master Node Configurations

• 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

CloudCore Node Configurations

• 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

Component Parameter Configurations​

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/v1alpha1
kind: CloudCore
kubeAPIConfig:
  kubeConfig: ""
  master: ""
  qps: 60000
  burst: 80000
modules:
  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 Test​

Test Execution​

Before using ClusterLoader2 to perform the performance test, we defined the test policy using the configuration file. In this test, we used the official Kubernetes density case. The configuration file we used can be obtained here:

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

The following table describes the detailed Kubernetes resource configurations:

For details about the test method and procedure, see the following links:

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

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

Test Results​

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：

Note: Theoretically, the latency should always be greater than 0. Because kube-apiserver does not support RFC339NANO, the timestamp precision can only be seconds. Therefore, when the latency is low, some values collected by ClusterLoader2 are 0 due to precision loss.

Conclusion and Analysis​

From the preceding test results, the API call latency and pod startup latency meet the SLIs/SLOs defined by the Kubernetes community. Therefore, the KubeEdge-powered Kubernetes clusters can stably support 100,000 concurrent edge nodes and more than one million pods. In production, the network between edge nodes and the cloud is connected according to O&M requirements due to reasons such as network security and partition management. Therefore, the number of edge nodes that can be managed by a single cluster can increase proportionally based on the proportion of offline edge nodes to online ones. In addition, data fragmentation is used on the Kubernetes control plane to store different resources to the corresponding etcd space, which allows for a larger service deployment scale.

KubeEdge's Support for Large-Scale Edge Node Access​

1. Efficient Cloud-Edge Messaging​

List-watch is a unified mechanism for asynchronous messaging of Kubernetes components. The list operation calls the list API of a resource to obtain full resource data through non-persistent HTTP connections. The watch operation calls the watch API of a resource to monitor resource change events and obtain incremental change data through persistent HTTP connections and block-based transmission encoding. In Kubernetes, in addition to the list-watch of a node, pods allocated to the node, and full service metadata, kubelet must also watch (by default) the running pods mounted with secrets and ConfigMaps as data volumes. The number of list-watch operations could explode with increasing nodes and pods, which heavily burdens kube-apiserver.

KubeEdge uses the two-way multiplexing edge-cloud message channel and supports the WebSocket (default) and QUIC protocols. EdgeCore at the edge initiates a connection request to CloudCore on the cloud. CloudCore list-watches Kubernetes resource changes, and delivers metadata to the edge through this two-way channel. EdgeCore uploads the metadata, such as edge node status and application status, to CloudCore through this channel. CloudCore reports the received metadata to kube-apiserver.

CloudCore aggregates the upstream and downstream data. kube-apiserver processes only several list-watch requests from CloudCore. It can be effectively unburdened and the cluster performance gets improved.

Memory usage when the native Kubernetes kube-apiserver is used under the same node and pod scales:

Memory usage when kube-apiserver is used in a KubeEdge-powered Kubernetes cluster:

2. Reliable Incremental Cloud-Edge Data Transmission​

In the case of complex edge network topology or poor networking quality, cloud-edge communication may be compromised by high network latency, intermittent/frequent disconnection, and other issues. When the network recovers and edge nodes want to reconnect to the cloud, a large number of full list requests will be generated, pressuring kube-apiserver. Large-scale deployments may amplify this challenge to system stability. To solve it, KubeEdge records the version of the metadata successfully sent to the edge. When the cloud-edge network is reconnected, the cloud sends incremental metadata starting from the recorded metadata version.

3. Lightweight Edge + Edge-Cloud Messaging Optimization​

EdgeCore removes native kubelet features that are not used in edge deployments, such as in-tree volume and cloud-provider, trims the status information reported by nodes, and optimizes resource usage of edge agent software. EdgeCore can run with a minimum of 70 MB memory on edge devices whose memory is as minimum as 100 MB. The WebSocket channel, edge-cloud message combination, and data trim greatly reduces the communication pressure on the edge and cloud and the access pressure on the control plane. They ensure that the system can work properly even in the case of high latency and jitter.

When 100,000 edge nodes are connected, the number of ELB connections is 100,000.

When 100,000 edge nodes and more than 1,000,000 pods are deployed, the inbound rate of the ELB network is about 3 MB/s, and the average uplink bandwidth to each edge node is about 0.25 kbit/s.

Next Steps​

Targeted tests will be performed on edge devices, edge-cloud messaging, and edge service mesh. In addition, for some edge scenarios, such as large-scale node network disconnection and reconnection, high latency of edge networks, and intermittent disconnection, new SLIs/SLOs need to be introduced to measure the cluster service quality and perform large-scale tests.

As the first cloud-native edge computing community, KubeEdge provides solutions for cloud-edge synergy and has been widely adopted in industries including Transportation, Energy, Internet, CDN, Manufacturing, Smart campus, etc. With the accelerated deployment of KubeEdge in this area based on cloud-edge synergy, the community will improve the security of KubeEdge continuously in cloud-native edge computing scenarios.

The KubeEdge community attaches great importance to security and has set up Sig Security and Security Team to design KubeEdge system security and quickly respond to and handle security vulnerabilities. To conduct a more comprehensive security assessment of the KubeEdge project, the KubeEdge community cooperates with Ada Logics Ltd. and The Open Source Technology Improvement Fund performed a holistic security audit of KubeEdge and output a security auditing report, including the security threat model and security issues related to the KubeEdge project. Thank you to experts Adam Korczynski and David Korczynski of Ada Logics for their professional and comprehensive evaluation of the KubeEdge project, which has important guiding significance for the security protection of the KubeEdge project. Thank you Amir Montazery and Derek Zimmer of OSTIF and Cloud Native Computing Foundation (CNCF) who helped with this engagement.

The discovered security issues have been fixed and patched to the latest three minor release versions (v1.11.1, v1.10.2, v1.9.4) by KubeEdge maintainers according to the kubeedge security policy. Security advisories have been published here.

For more details of the threat model and the mitigations, Please check KubeEdge Threat Model And Security Protection Analysis: https://github.com/kubeedge/community/tree/master/sig-security/sig-security-audit/KubeEdge-threat-model-and-security-protection-analysis.md.

References:​

Audit report: https://github.com/kubeedge/community/tree/master/sig-security/sig-security-audit/KubeEdge-security-audit-2022.pdf

OSTIF Blogpost: https://ostif.org/our-audit-of-kubeedge-is-complete-multiple-security-issues-found-and-fixed

CNCF Blogpost:

KubeEdge Threat Model And Security Protection Analysis: https://github.com/kubeedge/community/tree/master/sig-security/sig-security-audit/KubeEdge-threat-model-and-security-protection-analysis.md