KubeEdge在边缘计算领域的安全防护及洞察

Posted 2023-05-09 华为云开发者社区

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了KubeEdge在边缘计算领域的安全防护及洞察相关的知识，希望对你有一定的参考价值。

摘要：着重介绍Kubeedge在安全防护方面的实践，并介绍OpenSSF在开源软件安全方面的计划与目标。

本文分享自华为云社区《KubeEdge在边缘计算领域的安全防护及洞察》，作者：华为云云原生团队。

随着开源软件安全漏洞持续引起世界各地政府和企业的关注，越来越多的组织、开发人员、研究人员和安全专家投入到开源安全工作中，在各方力量的推动下，开源安全目前已初步形成体系化的生态大网，覆盖了国际化的软件工程行业标准、安全评估体系、安全工具链与整体解决方案等，并逐步撬动整个业界开源软件安全行业的生态产业链。

在2020年Linux基金会与多家硬件和软件厂商合作创立了开源软件安全基金会OpenSSF（Open Source Security Foundation），这是一个跨行业的合作组织，汇集了行业领军企业与机构，涵盖世界上最重要的软件供应链安全计划、开源开放的工具链、安全指南、培训等，旨在提高开源软件（OSS）的安全性。

作为业界首个云原生边缘计算项目，KubeEdge社区致力于提升KubeEdge在云原生边缘计算场景下的安全性，将安全视为社区发展的重要指导原则。社区充分结合了业界的开源安全经验，于2022年7月完成了对KubeEdge项目的安全威胁模型分析。尽管云原生边缘计算的安全问题备受用户关注，但业界目前缺乏相关的安全威胁模型分析，这使得用户难以有效地加固其边缘系统。因此，KubeEdge社区发布了安全威胁模型及分析白皮书，为用户和厂商提供了重要的安全实践指导。下文将着重介绍Kubeedge在安全防护方面的实践，并介绍OpenSSF在开源软件安全方面的计划与目标。

安全防护背景

KubeEdge在边端云协同领域正在加速布局，已在智慧交通、智慧城市、智慧园区、智慧能源、智慧工厂、智慧银行、智慧工地、CDN等行业提供一体化的边端云协同解决方案。随着越来越多的用户将KubeEdge项目用于生产环境中，KubeEdge社区把安全问题放在优先地位，并成立Sig- Security 和安全团队，负责KubeEdge的系统安全设计，并快速响应和处理安全漏洞。为了对KubeEdge项目进行更加全面的安全评估，KubeEdge社区联合ADA LOGICS公司、OSTIF及云原生计算基金会（CNCF）对KubeEdge项目进行安全评估并输出安全评估报告，分析和总结KubeEdge项目的安全威胁模型及相关安全问题。该评估对KubeEdge项目的安全防护有重要的指导意义，感谢ADA LOGICS公司的专家Adam Korczynski和David Korczynski在该项工作中的巨大贡献，同时，感谢OSTIF的Amir Montazery和Derek Zimmer以及CNCF基金会，他们对这次评估提供了很大帮助。

对于安全报告中发现的安全问题，KubeEdge社区已根据社区的漏洞处理策略第一时间完成修复，并针对v1.11、v1.10、v1.9三个版本发布了安全补丁，版本号分别为v1.11.1、v1.10.2和v1.9.4，漏洞公告已发布在https://github.com/kubeedge/kubeedge/security/advisories。

接下来将通过解读KubeEdge威胁模型，为边缘计算领域提供更多的安全防护经验，并在开源软件供应链安全加固工作上为更多的开源社区提供参考。

威胁模型分析

KubeEdge的安全审计报告指出，该系统可能受到外部攻击、内部操作人员的不当操作和供应链攻击等三种潜在攻击类型的影响。本章节使用STRIDE威胁建模方法，结合安全审计报告对KubeEdge进行了系统的安全分析，包括上述三个方面。目的是帮助开发者和用户了解系统中的潜在安全威胁、明确风险并列举出目前KubeEdge社区已有的消减机制和安全加固建议。

以下人群使用KubeEdge过程中，了解KubeEdge的威胁模型分析和可能的缓解措施将对他们的工作有所帮助：

• KubeEdge的贡献者：一个通用的威胁模型对KubeEdge贡献者很有用，他们可以从整体角度考虑并加固他们的系统。

• 部署KubeEdge的组织：对于在集群中使用KubeEdge的组织来说，了解常见的攻击和可能的弱点是很有用的，这样他们就可以检查和评估自己的配置。

• 安全评估员：负责评估KubeEdge及所属Kubernetes集群的安全性。通过了解该威胁模型，让安全评估员可以对系统的安全风险进行更加全面的评估。

• KubeEdge的用户及其开发人员：需要了解KubeEdge的更新和攻击，以主动避免未来可能发生的安全风险。

外部攻击分析

根据STRIDE威胁建模方法对KubeEdge潜在的外部攻击进行分析，对应的数据流图如下。

如数据流图所示，当数据流穿越不同的信任级别（区域）时，就存在信任边界，已在图中用红框标出。下面将详细分析KubeEdge系统架构中的信任边界（引用自KubeEdge第三方安全报告）、社区已有的消减措施并给出安全加固建议。

威胁一：云端CloudCore组件与EdgeCore组件之间的连接

描述：该威胁涉及边缘EdgeCore与云端CloudCore之间的连接。在这个数据流中，较低信任级别组件EdgeCore向较高信任级别组件CloudCore发起访问。由于EdgeCore在系统中拥有独立的权限级别，攻击者控制EdgeCore后，不应该能够对其他边缘节点造成负面影响，例如通过攻击和操控CloudCore来攻击其他节点（该漏洞描述引用自安全评估报告）。

影响：攻击者恶意修改CloudCore与EdgeCore组件之间的请求和应答报文，导致通信过程存在仿冒和篡改的威胁风险。

消减措施：

• CloudCore与EdgeCore之间的通信通过数字签名证书加密和服务端/客户端双向认证的方式保障信息交互的机密性和完整性，安全加密协议使用TLS 1.2，且指定加密算法套件白名单，防止客户端使用不在白名单中的不安全算法进行通信造成安全风险；

• 证书默认有效期为一年，过期后失效，防止证书被攻击者利用。用户基于KubeEdge项目已有的证书轮转机制，可以实现证书过期自动更换，保障业务连续性。

针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 1和2）。

威胁二：边缘组件ServiceBus在本机范围内提供HTTP服务

描述：边缘组件ServiceBus监听本地local host端口并在本机范围内提供HTTP服务。该数据流中，较低信任级别的用户应用进程向较高信任级别组件ServiceBus发起访问。如果发起攻击，不应该使攻击者能够将影响范围扩大到云端控制面（该漏洞描述引用自安全评估报告）。

影响：ServiceBus组件收到的数据往往是不受管理面控制的，攻击者能够对ServiceBus组件发起恶意报文攻击，导致通信过程存在仿冒和篡改的威胁风险。ServiceBus组件异常仅影响单个边缘节点服务故障，不会导致整个KubeEdge系统崩溃。

消减措施：

• ServiceBus组件仅监听本地local host端口，已限制服务范围，只允许本机进程访问，通过对本机用户访问权限的限制保障本组件安全；

• 服务端接收客户端连接时记录连接访问的日志，可作为审计日志，可以让管理员及时发现攻击的发生，并及时停止ServiceBus服务，阻止攻击继续进行；

• ServiceBus服务默认关闭，遵守默认安全的原则。在用户使用文档中已明确提示用户如果开启该服务，则存在上述风险。

针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 3、4和5）。

威胁三：边缘端Device通过MQTT Broker连接到EdgeCore

描述：边缘device设备通过MQTT Broker（集成在EventBus组件中）连接到EdgeCore。该数据流中，较低信任级别的用户device设备向较高信任级别组件EdgeCore发起访问（该漏洞描述引用自安全评估报告）。

影响：EdgeCore组件收到的数据往往是不受管理面控制的，攻击者能够对MQTT Broker发起恶意报文攻击，存在仿冒和篡改的威胁风险。如果发起攻击导致EventBus组件异常，异常仅影响单个边缘节点服务故障，不会导致整个KubeEdge系统崩溃。

消减措施：

• MQTT Broker仅监听在本机端口，已限制服务范围，只允许本机进程访问，通过对本机用户访问权限的限制保障本组件安全；同时，EventBus组件可作为客户端，对接外置第三方MQTT Broker，如果用户使用第三方MQTT Broker，详细的消减措施请参考对应第三方MQTT Broker服务提供厂商的安全文档。

• EventBus仅对MQTT Broker中的特定Topic进行处理，用户无法通过该通道对EdgeCore任意访问。

针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 3、4、5和6）。

威胁四：Edged管理和监控Pods及其他K8s资源

描述：Edged管理和监控Pods及其他K8s资源。该数据流中，较低信任级别的应用容器与较高信任级别组件EdgeCore之间进行数据交互。如果主动发起连接时，被恶意服务器攻击，不应该使攻击者能够将影响范围扩大到云端控制面（该漏洞描述引用自安全评估报告）。

影响：如果Edged访问的CRI插件被攻击者恶意伪造，则存在CRI插件仿冒和篡改的威胁风险，导致本地业务异常。

消减措施：

• Edged与CRI插件通信时，只在本地访问受信任路径，由管理员控制访问路径，最小化Unix domain sockets文件描述符的权限，避免被仿冒者恶意替换。

针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 3和7）。

威胁五：MetaServer在边缘节点提供HTTP服务

描述：MetaServer作为边缘“api-server”，对边缘插件提供HTTP服务。该数据流中，较低信任级别的用户应用插件向较高信任级别组件MetaServer发起访问（该漏洞描述引用自安全评估报告）。

影响：MetaServer组件收到的数据往往是不受管理面控制的，攻击者能够对MetaServer组件发起恶意报文攻击，导致通信过程存在仿冒和篡改的威胁风险。MetaServer组件异常仅影响单个边缘节点服务故障，不会导致整个KubeEdge系统崩溃。

消减措施：

• MetaServer组件仅监听本地local host端口，已限制服务范围，只允许本机进程访问，通过对本机用户访问权限的限制保障本组件安全；

• MetaServer服务默认关闭，遵守默认安全的原则。在用户使用文档中已明确提示用户如果开启该服务，则存在上述风险。

针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 3、4和5）。

内部攻击分析

对于内部管理员或操作人员，可能的风险主要包括管理员或操作人员错误操作将恶意软件部署至集群中、在高风险场景中执行高风险配置等。

消减措施：

• KubeEdge用户手册中已提供各个组件的详细功能描述及配置使用指导文档，指导系统管理员或操作人员正确操作，减少人为误操作或误配置导致的安全风险。由于KubeEdge的持续迭代，该文档也将持续更新并完善。

针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 3、4、8和9）。

供应链攻击分析

攻击可能发生在典型软件供应链的每一个环节，而且在当今环境中，这些类型的攻击越来越公开，破坏性和代价高昂。攻击方向包括源代码完整性、构建完整性和构建产物的可用性。

消减措施：

• 社区联合安全公司对KubeEdge软件供应链流程已进行SLSA等级评估，并引入SLSA软件供应链安全评估框架，包括对源代码、构建流程、依赖库等进行安全评估，防止针对软件供应链的攻击，从源头上保障软件供应链的安全。

值得一提的是，在2023年1月18日发布的v1.13.0版本中，KubeEdge项目已达到SLSA L3等级（包括二进制和容器镜像构件），成为CNCF社区首个达到SLSA L3等级的项目，并加入Sigstore生态系统，实现更高等级的安全标准。

• KubeEdge仓库CI/CD流水线中已开启dependence bot第三方依赖库检查功能，及时发现第三方依赖库的安全漏洞并在KubeEdge版本中同步更新，降低被攻击的风险；

• KubeEdge security team已具备完整漏洞处理机制，包括漏洞发现、漏洞上报、漏洞分析处理、漏洞披露和发布整个流程，可以及时处理和修复安全漏洞。详细漏洞处理及披露策略请见https://github.com/kubeedge/community/blob/master/security-team/SECURITY.md。

针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 10和11）。

安全加固建议列表

开源安全洞察

本章节通过对OpenSSF社区的战略规划、OpenSSF工作组内容及开放源代码软件安全动员10个TOP计划进行介绍，为相关从业人员、开源生态产业提供参考。

1) OpenSSF介绍

社区工作组

为了更好的提升开源软件安全，OpenSSF目前已成立了8个工作组，主要负责开源软件开发最佳实践、软件代码安全、用户、安全工具链、开源项目安全威胁识别、软件供应链完整性、保护关键开源项目、漏洞披露。

OpenSSF安全工具链

安全领域涉及面广，规则规范多，开发人员甚至从事资深安全工作的专家人工识别冗余遗漏。安全工具链用于快速识别安全风险，使开发人员专注于功能特性开发。

覆盖范围：涵盖整个DevSecOps的各环节工具链，并支撑开源软件开发的最佳实践章节，如：

linters(cleanCode), SAST, SCA, DAST, Fuzzers, Hard Coded Secrets Detectors, and SBOM generators。
提供方：部分来自公司捐赠，部分来自OpenSSF基金会自主规划，部分在规划阶段待建设。

2) 开源软件安全动员计划及目标

2022 年 1 月，美国政府专家、 OSS 基金会、相关企业在白宫举行会议讨论，制定如下三个动员计划的总体目标：

• 保护 OSS 生产：首先是专注于防止安全缺陷、代码和开源包漏洞

• 改进漏洞识别和修复：改进缺陷识别过程、漏洞修复

• 缩短补丁响应时间：缩短漏洞披露和修复时间

在2022年5月第二届开源软件安全峰会上，Linux基金会、OpenSSF及各行业安全专家，就提高开源软件安全性计划达成共识，将集中在以下10个方向进行投资和安全改善，项目投资1.5亿美元，分为两年规划。

备注：动员计划和OpenSSF工作组是相辅相成的，其动员计划的能力会融入到工作组中。

总结

本文通过从外部攻击面、内部攻击面及软件供应链三个维度对KubeEdge项目进行安全威胁建模，实现对KubeEdge项目的系统性安全评估，帮助社区maintainer及时发现和修复安全风险。同时，对业界OpenSSF社区开源安全策略及相关项目进行洞察，通过洞察分析可以看出，越来越多的组织、开发人员、研究人员和安全专家将加大投入资源来加强开源安全，并已逐步形成业界开源安全行业的生态产业链，在开源安全上占据标准高地可以为后续的商业扩展提供有力地位。KubeEdge社区结合业界安全理念，将能够推动社区持续巩固和演进项目的安全。

附录

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

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

近日，云原生边缘计算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多个维度资源上限。

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. …..

各个维度不是完全独立的，某个维度被拉伸相应的其他维度就要被压缩，可以根据使用场景进行调整。例如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/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测试

测试执行

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

perf-tests/config.yaml at master · kubernetes/perf-tests · GitHub

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

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

以上是关于KubeEdge在边缘计算领域的安全防护及洞察的主要内容，如果未能解决你的问题，请参考以下文章

将K8s延伸到边缘计算，华为云KubeEdge实践分享

KubeEdge海量边缘节点管理架构实战

在 Kubernetes 中部署并使用 KubeEdge

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

The New Stack：KubeEdge将Kubernetes的能力延伸至边缘

KubeEdge在边缘计算领域的安全防护及洞察

安全防护背景

威胁模型分析

外部攻击分析

威胁一：云端CloudCore组件与EdgeCore组件之间的连接

威胁二：边缘组件ServiceBus在本机范围内提供HTTP服务

威胁三：边缘端Device通过MQTT Broker连接到EdgeCore

威胁四：Edged管理和监控Pods及其他K8s资源

威胁五：MetaServer在边缘节点提供HTTP服务

内部攻击分析

供应链攻击分析

安全加固建议列表

开源安全洞察

社区工作组

相关项目

OpenSSF安全工具链

总结

附录

相关链接

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

摘要

背景介绍

KubeEdge简介

SLIs/SLOs

Kubernetes 可伸缩性维度和阈值

测试工具

ClusterLoader2

Edgemark

测试集群部署方案

测试环境信息

组件参数配置

Density测试

测试执行

测试结果

结论及分析

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

1）高效的云边消息通道

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

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

下一步计划