华为云云原生视窗（2023Q1）
华为云云原生视窗（2023Q1）目录
一、华为云云原生Q1大事记
- 华为云海外首发CCI Serverless容器服务
- KubeEdge 社区13.0 版本发布，稳定性、安全性大幅提升
- CNCF持续重视软件供应链安全，KubeEdge成为首个达到SLSA L3等级的项目
Karmada v1.5 新增多调度组助力成本优化
-
Volcano 社区 v1.7.0 版本正式发布，提升云原生调度能力，强化AI、大数据场景适用度
-
ING国际银行基于Volcano开展大数据分析作业，获得Kubernetes更高调度性能
-
Kurator v0.2.0 发布！助力企业分布式云原生应用升级能
- Istio宣布2023年指导委员会席位，华为占两席
二、华为云云原生技术精选
- 当Serverless遇到Regionless：现状与挑战——华为云云原生团队 张嘉伟
- KubeEdge在边缘计算领域的安全防护及洞察——华为云云原生团队 林国辉
- 华为云云原生团队：Istio数据面新模式 Ambient Mesh技术解析——华为云云原生团队 姚增增
- Karmada百倍集群规模多云基础设施体系揭秘——华为云云原生团队 沈铁成
华为云云原生Q1大事记
华为云海外首发CCI Serverless容器服务，释放数字生产力
在MWC23 巴展期间，华为新产品解决方案发布会在2月27日下午成功举行。在发布会上，华为云全球Marketing与销售服务总裁石冀琳表示：我们希望通过“一切皆服务”的战略，为客户、伙伴和开发者提供稳定、可靠、安全、可持续的云服务。
在本次发布会上，华为云海外首发CCI Serverless容器服务正式上线。基于serverless容器架构CCI，客户无需创建和管理服务器节点，即可直接运行容器应用，按需获取、智能运维，让客户只需专注应用开发，无需关注底层资源。具备业务领先的弹性能力，助力客户轻松应对超10倍的突发流量浪涌。
CCI Serverless容器具备优势如下：
• 聚焦应用免运维
1. Serverless无服务器容器使用全新体验
2. 客户无需管理服务器或集群
• 极致计算性能
1. 瑶光统一资源池，提供多种X86、AXD、鲲鹏等类型算力资源
2. 全面升级资源拓扑管理能力，保障容器极致算力性能
• 智能统筹弹性
1. 30秒发放1000容器，满足极速弹性要求
2. 支持跨云、跨集群、跨IDC对接的灵活弹性，全场景助力客户业务应对峰值流量
Serverless容器构筑极致性能、高效运维、丰富算力等差异化竞争力，打造大规模高性能云原生Serverless容器资源底座。
Source : 华为官网新闻报道
KubeEdge 社区 v1.13.0 版本发布，稳定性、安全性大幅提升
KubeEdge社区v.1.13.0版本发布。作为2023年最新版本，v.1.13.0性能在稳定性、安全性等方面进大幅提升，其中重大更新如下：
• 运行性能提升：对CloudCore 内存使用减少 40%，优化List-watch dynamicController处理，增加云端和边缘之间的list-watch同步机制，增加dynamicController watch gc机制。
• 安全性能提升：成为CNCF首个达到软件供应链SLSA L3等级的项目；同时删除边缘节点配置文件 edgecore.yaml 中的 token 字段，消除边缘信息泄露的风险
• 对Kuberbetes支持升级至v.1.23.15: 将vendered kubernetes版本升级到v1.23.15，用户现在可以在云端和边缘使用新版本的特性。
• 基于 DMI 的 Modbus 映射器：提供基于DMI的Modbus Device Mapper，用于接入Modbus协议设备。
• EdgeMesh：向边缘隧道模块添加了可配置字段 TunnelLimitConfig
edge-tunnel模块的隧道流用于管理隧道的数据流状态。用户可以获得稳定、可配置的隧道流，保证用户应用流量转发的可靠性。
KubeEdge云原生边缘计算社区于2022年完成多项关键突破，相继发布《KubeEdge单集群10万边缘节点报告》，《云原生边缘计算威胁模型及安全防护技术白皮书》，并于KubeEdge Summit 2022正式开源分布式协同AI基准测试平台Ianvs。目前项目已完成EdgeMesh高可用架构，KubeEdge on openEuler支持，KubeEdge on openHarmony支持，下一代云原生边缘设备管理框架DMI也将带来更全面的的性能支持与更优的用户体验。
欢迎大家测试体验。
https://github.com/kubeedge/kubeedge/releases/tag/v1.13.0
CNCF持续重视软件供应链安全， KubeEdge成为首个达到SLSA L3等级的项目
软件供应链安全持续受到高度关注，CNCF 和OSTIF （Open Source Technology Improvement Fund，开放源码技术改进基金）在过去几年中一直合作，为CNCF 的毕业和孵化项目进行安全审计，保障开源生态系统具有更好的安全性。
最新的 OSTIF 报告公布了 2022 年下半年至 2023 年初开展的独立安全审计结果。获得审计通过的项目包含KubeEdge、Argo、Istio、Envoy、CloudEvents等12个项目：
审计工作通过创建良好的指导性政策和项目成熟度模型，以及可重复的审计执行流程，以确定风险、威胁媒介并实施工具来改善项目的安全状况。提升项包含：
在本次公布的社区中，KubeEdge社区早在2022年7月份，通过完成整个KubeEdge项目的第三方安全审计[2] ，发布《云原生边缘计算安全威胁分析和防护白皮书》，并根据安全威胁模型和安全审计的建议，对KubeEdge软件供应链进行持续安全加固，为本次SLSA L3等级的达成做了充分的准备。在2023年1月18日，社区发布v1.13.0版本，该版本达到SLSA[1] L3等级标准（包括二进制和容器镜像构件），KubeEdge 成为CNCF社区首个达到SLSA L3等级的项目。
以下表格展示了KubeEdge在Source、Build、Provenance、Common中的达标情况（Y表示KubeEdge已达标，空格表示SLSA在该等级下未要求）：
Requirement |
L1 |
L2 |
L3 |
L4 |
Source |
||||
Version controlled |
Y |
Y |
Y |
|
Verified history |
Y |
Y |
||
Retained indefinitely |
Y |
Y |
||
Two-person reviewed |
Y |
|||
Build |
||||
Scripted build |
Y |
Y |
Y |
Y |
Build service |
Y |
Y |
Y |
|
Build as code |
Y |
Y |
||
Ephemeral environment |
Y |
Y |
||
Isolated |
Y |
Y |
||
Parameterless |
Y |
|||
Hermetic |
Y |
|||
Provenance |
||||
Available |
Y |
Y |
Y |
To-do |
Authenticated |
Y |
Y |
To-do |
|
Service generated |
Y |
Y |
To-do |
|
Non-falsifiable |
Y |
To-do |
||
Dependencies complete |
To-do |
|||
Common |
||||
Security |
Y |
|||
Access |
Y |
|||
Superusers |
Y |
为什么达到SLSA L3等级对开源项目至关重要
软件供应链完整性攻击（对软件包的未经授权的修改）在过去三年中呈上升趋势。SLSA在KubeEdge项目软件供应链安全中发挥着重要作用，基于sigstore社区提供的能力，从源码到发布产物，对软件供应链端到端的整个流程进行签名和校验，确保KubeEdge软件供应链安全。
自v1.13.0版本开始， KubeEdge 可以端到端的从源码构建到发布流程进行安全加固，保障用户获取到的二进制或容器镜像产物不被恶意篡改。基于SLSA安全框架，可以潜在地加强软件构件的完整性。SLSA提供端到端的指导原则，可以作为软件的一组防御措施，并防止对组成软件产品的软件包的篡改或任何类型的未经授权的修改。采用SLSA框架可以保护项目软件免受常见的供应链攻击。
参考资料
[1] SLSA官网：https://slsa.dev/
[2] KubeEdge项目第三方安全审计：
Karmada v1.5 新增多调度组助力成本优化
Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。在最新发布的1.5版本中，Karmada 提供了多调度组的能力，利用该能力，用户可以实现将业务优先调度到成本更低的集群，或者在主集群故障时，优先迁移业务到指定的备份集群。本版本其他新增特性：
• 提供了多调度器支持能力，默认调度器可以与第三方自定义调度器协同工作，提供更强的定制能力。
• 集群差异化配置策略（OverridePolicy/ClusterOverridePolicy）将按照隐式的优先级进行应用。
• 内置资源解释器支持聚合StatefulSet/CronJob 状态。
Karmada v1.5版本API兼容v1.4版本API，v1.4版本的用户仍然可以平滑升级到v1.5版本。
Volcano 社区 v1.7.0 版本正式发布，提升云原生调度能力，强化AI、大数据场景适用度
北京时间2023年1月9日，Volcano社区v1.7.0版本正式发布。Volcano是业界首个云原生批量计算项目，项目于2019年6月在上海的KubeCon大会上正式宣布开源，并于2020年4月成为CNCF官方项目。2022年4月，Volcano正式晋级为CNCF孵化项目。Volcano社区开源以来，受到众多开发者、合作伙伴和用户的认可和支持。截止目前，累计有490+全球开发者向项目贡献了代码。
Volcano v1.7.0版本在主流计算框架支持、通用服务调度能力、队列资源可观测性等方面进行了增强，新增特性列表如下：
• Pytorch Job插件功能强化
• Ray on Volcano
• 增强Volcano对Kubernetes通用服务的调度能力
• 支持Volcano的多架构镜像
• 优化队列状态信息等
本次版本发布后，Volcano可以更好的适用AI、大数据场景，为使用者提供更简洁易用的Ray、Pytorch等工作负载的云原生调度能力。
Volcano云原生批量计算项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。社区已吸引2.6万+全球开发者，并获得2.8k Star和670+ Fork，参与贡献企业包括华为、AWS、百度、腾讯、京东、小红书等。目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到快速应用，已完成对Spark、Flink、Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、mxnet、KubeGene、Ray等众多主流计算框架的支持，并构建起完善的上下游生态。
ING国际银行基于Volcano开展大数据分析作业，获得Kubernetes更高调度性能
在 KubeCon North America 2022， ING荷兰国际集团（International Netherlands Groups）发表了《Efficient Scheduling Of High Performance Batch Computing For Analytics Workloads With Volcano - Krzysztof Adamski & Tinco Boekestijn, ING》主题演讲，重点介绍了云原生批量计算项目Volcano如何在数据管理平台中为大数据分析作业提供高性能调度工作。
ING荷兰国际集团（International Netherlands Groups）是一个国际金融服务私营企业，成立于1991年，由荷兰最大的保险公司Nationale-Nederlanden，与荷兰的第三大银行NMB PostBank Group合并而成。
ING集团的服务遍及全球40多个国家，核心业务是银行、保险及资产管理等。ING集团的全球职员大约56,000人，顾客5320万人，包括自然人、家庭，企业、政府及其他等，例如基金组织。
在银行行业有许多法规和限制，ING布局符合自身产业的DAP平台（Data Analytics Platform），为全球50%的ING员工提供安全的、自助的端到端分析能力，帮助员工在数据平台之上构建并解决业务问题。在本次以Volcano为案例的演讲中，ING 重点指出Volcano对批处理任务调度做了很好的抽象，使其在Kubernetes平台能够获得更高的调度性能，后面ING也会将开发的功能逐步回合社区，比如：DRF Dashboard、在每个节点添加空闲空间、自动队列管理、更多的Prometheus监控指标、Grafana仪表盘更新、kube-state-metrics更新和集群角色限制等。
Volcano 2019年由华为云捐献给云原生计算基金会（CNCF），也是 CNCF 首个和唯一的容器批量计算项目，帮助用户将 AI、大数据、HPC等计算密集型的业务从传统的系统快速迁移到云原生平台，加速整个云原生落地的进程。
Kurator v0.2.0 发布！助力企业分布式云原生应用升级
Kurator是华为云开源的分布式云原生平台，帮助用户构建属于自己的分布式云原生基础设施，助力企业数字化转型。Kurator v0.1 版本通过一键集成 Karmada，Volcano，Istio，Prometheus 等主流开源项目，提供了分布式云原生的统一多集群管理，统一的调度，统一的流量治理以及统一的应用监控能力。在最新发布的 v0.2.0 中，Kurator 新增两大类关键特性，增强了可观测性并新增了集群生命周期管理，具体包括以下重大更新。
• 基于Thanos的多集群监控及指标持久化存储
• 基于Pixie实时的K8s应用监控
• 支持本地数据中心集群生命周期管理
• 支持AWS云上自建集群生命周期管理
Kurator由此开始提供分布式云原生基础设施的管理。这意味着，从此Kurator可以依托基础设施、Kubernetes集群，更好的管理各种云原生中间件，为用户提供开箱即用的分布式云原生能力。Kurator，一键构建分布式云原
Kurator于2022年6月在华为伙伴暨开发者大会上开源，是业界首个开源分布式云原生平台。通过集成业界主流开源技术栈以及良好云原生舰队管理性能，Kurator为用户提供一站式、开箱即用的分布式云原生能力，打造分布式云原生技术底座,助力企业业务跨云跨边、分布式化升级。
Istio宣布2023年指导委员会席位，华为占两席
2月6日，Istio社区宣布2023年指导委员会（Steering Committee）席位。Istio 指导委员会[1]，由 9 个贡献席位（根据企业对项目的贡献按比例分配）和 4 个选举产生的社区席位组成。每年 2 月，社区都会根据年度商定的指标[4]，查看哪些公司对 Istio 的贡献最大并进行公布。
华为云已连续三年获得Istio委员会席位(Steering Committee成员2名,全球仅8家公司13人）；Maintainer 2名，Member 10+名。过去几年，华为云Pull Request 位于全球TOP 3，Contributions TOP 3(1.9w+）。由华为云技术团队撰写并出版的《云原生服务网络Istio：原理、实践、架构与源码解析》一书，是业内最有影响力的服务网络书籍之一。
目前，华为云应用服务网格（ASM）也已服务于互联网、汽车、制造、物流、政府等多个行业的近千家客户，满足不同行业客户的业务诉求。华为云将在此过程中积累的丰富经验，转化为代码贡献给Istio社区，极大地推动了Istio技术的成熟和社区的快速发展。同时，华为云还大力投入服务网格的技术布道，通过社区论坛、技术会议、视频直播、专业书籍等各种方式，推动服务网格技术传播和普及。
华为云云原生技术精选
当Serverless遇到Regionless：现状与挑战
华为云云原生团队 张嘉伟
近年来，Serverless服务崛起的趋势是有目共睹的：从Berkeley将Serverless认定为云计算向用户呈现的新默认形态[1]，到AWS、Google等头部厂商纷纷推出Serverless产品并成为爆款。这个趋势对于云计算平台是个必然，因为Serverless解放了用户管理和使用复杂云计算资源的双手，犹如第二次工业革命中内燃机汽车的出现解决了马车夫养马的麻烦，也推动高效、稳定的交通工具走进寻常百姓家。如同汽车由内燃机和转向机构等组件构成，Serverless平台可大致分为资源管理和任务编排[2]，分别致力于提供高效且灵活的算力以及提供方便的用户程序执行方式。在Serverless如火如荼的同时，Regionless也是不可忽视的一个方向。Regionless实际上是华为云提出的概念，即为屏蔽掉云平台Region的差异，使得云服务的租户能像“用水和用电”一样随时随地使用云服务。Regionless的内涵实际上是丰富的，囊括了多个学术研究方向：可以是geo-distributed cloud，也可以是multi-cloud，还可以是cloud-edge computing、 hybrid cloud等，分别对应不同的能力。恰好，以上都涵盖在华为云分布式云原生服务提供的offerings中。
既然Serverless和Regionless都是当前云原生发展的重要方向，也都基于同一个云平台资源底座构建，那么两者的发展必然不会是平行的：Serverless对基础设施进行了标准化，为应用Regionless化减少了管理和适配的成本；反过来，Regionless也是Serverless的重要组成，因其可以避免用户感知Region间的差异。事实上，早在2018年，就有学者关注到Serverless对底层差异的屏蔽以及平台提供商数量的快速增长，用户必然会有将Serverless业务部署至Regionless平台的诉求[3]。在此场景下，用户和平台设计者首当其中考虑到的就是如何充分利用分布在各个区域的计算资源以提升如并发度、时延等性能；同时，使用成本也是用户核心关注点，所以如何充分利用各个厂商的定价差异消减成本，同时也避免与厂商绑定（vendor lock-in）带来潜在的成本问题也需要充分考虑。因此，本文尝试基于分析现有的学术文章，剖析Serverless与Regionless并存时，在性能提升和成本控制两个方向的现状与挑战，以期抛砖引玉。
性能提升
早在2019年，来自华盛顿大学的研究者[4]已经注意到Serverless工作流中的计算任务会涉及存储在不同区位的数据，并且这些数据在对应区位会存在隐私性等问题，因此需要将任务分布到对应数据所在的云平台Region进行计算。为此，作者设计了跨Region的调度器GlobalFlow，其核心思想是将工作流中的任务根据对Region的依赖关系进行分组，形成子工作流调度到对应Region，并且在子工作流之间设计Connector以便于数据交换。
同样考虑到数据分布的问题，即数据可能分布在不同的区域，而且由于数据隐私性、传输开销等问题，并不能方便地集中在一个区域内处理，[5]中的作者设计了FaDO系统用以编排Serverless计算任务和数据。如图1所示，FaDO通过Backend Server记录每个区域存储的数据，这些信息则被提供给Load Balancer用于将用户请求的计算任务匹配并发送到对应的区域。并且在规则允许范围内，Backend Server还会将数据备份在不同的区域间进行复制，以配合计算任务的并发度。
图1 FaDO系统执行流程
除了数据的分布会促使Serverless必须接受Regionless，[6]的作者还观察到：一个云厂商的每个Region、每个厂商都有不同的并发度限制，并且之间的数据传输时延、存储的数据、每种任务执行的速度等能力均不一致。简单的将应用分发到多云/多Region上并不一定能充分提升并发度和整体完成时间。例如图2左侧所示（每种颜色标记的云上并发度限制为1000，整体应用由f1-f4任务构成，也需要运行1000次），如果f1在蓝色标识的云资源上运行地快，而f4则在橙色上快时，均匀分布则不能利用这个性能差异，而且在橙色云上，f2和f3并不能充分并行（完全并行需要1200并发度），进一步影响整体执行时间。在此情况下，如何合理选择任务所使用的云资源（如图2右侧所示），以有效地提升并发度是[6]所研究的重点。为此，[6]中提出了基于三层数学抽象构建的调度器算法FaaSt。FaaSt能够合理地将各个任务调度和合适的云厂商/Region上，使得整体的任务完成时间最短。经过在AWS和IBM云上4个Region的实验对比，FaaSt调度后的任务完成时间比单云提升2.82倍。
图2 Serverless并发度示意图
成本控制
为了协助用户选择合适的平台以执行Serverless任务，[3]中提出了MPSC框架，其核心思想是通过实时监控Serverless任务在不同平台上执行的性能，进而选择最具性价比的平台。MPSC的架构如图3所示，其中Monitoring Controller为核心组件，用于协调监控指标采集分析和任务调度。Function Executor则负责将任务分发至各个平台执行，并采集对应指标。除此之外，还有三个存储模块分别用于储存用户配置、监控指标、用户定义的调度逻辑。
图3 MPSC系统架构
在Serverless任务能够合理分发的基础之上，来自CMU和UBC的学者提出了虚拟Serverless提供商（virtual Serverless provider, VSP）[7]的概念。VSP作为第三方的平台，聚合了各个厂商的Offerings，为用户提供统一的使用接口，为用户动态选择最具性价比的Offering。VSP整体架构如图4所示，其中核心组件包括：Scheduler用以根据性能指标和花费计算最合适的云平台；Controller则负责将应用请求映射到Scheduler选择的云平台上；Bridge用于不同云平台之间任务的交互；Monitor用以记录调度到不同平台上任务的执行性能；Pre-Load用于初始化新接入的云平台；而Cache则记录了平台执行情况用于后续分析优化。通过在AWS和Google云平台上的测试，VSP将Serverless任务的吞吐量提升了1.2-4.2倍，同时降低了54%的云资源使用成本。
图4 VSP系统架构
进一步地，一个面向多云Serverless的开源library在[8]中提出了。此library主要包括两部分内容（如图5所示）：1）统一的API和SDK，用于让用户不需要感知底层差异即可将不同人物部署在不同的云平台上，并且为了降低用户的学习门槛，还提供了基于某一家云平台提供商的API和SDK（如AWS）拓展出来的、可以将任务部署在其他云平台的API和SDK；2）分析系统（EAS），用于分析每个任务最适合的云平台，包含用于将任务分发至不同平台的adaptor、各个平台log的收集器Cloud Logging Query、各个云厂商的计费模型Cost Model、接入各个云平台的鉴权组件Authentication、任务执行的记录Local Logging以及性能分析器Analysis。
图5 面向多云的Serverless开源library
挑战
从上述现有工作可以看出，当前学术界对于Regionless和Serverless结合的研究主要面向geo-distributed cloud和multi-cloud这两个场景下的任务编排系统架构和算法。然而这还远远不足以构建高效、易用的Regionless化的Serverless平台。类似于Berkeley将Serverless分成Backend-as-a-Service (BaaS)和Function-as-a-Service (FaaS)两个层级[1]，我们也可以将当前所面临的挑战拆分成底层资源供给以及上层应用管理在Regionless场景的Serverless化：
• 底层资源上，我们需要考虑：
1) 通盘考虑每个区域计算资源池的异构性、资源余量、成本等因素的情况下，提供足够的资源同时又不因为Serverless极强的弹性而造成过多浪费[9]；
2) 从网络角度，在规避部分地理区位间带宽、时间等限制的同时，提供支持动态创删的低性能损失、免配置的网络；
3) 存储上，提供用户无感知的跨Region数据预存取与缓存。
• 应用管理层面上看，需要达到如下：
%2) 任务编排上，需要对计算、网络、存储联合进行调度以避免其中某项瓶颈对整体应用的影响；
%2) 编程框架上，需要在最小甚至没有侵入式修改的前提下，将用户应用构建或迁移至该平台；
%2) 从监控运维角度，需要实现非侵入式、高精度地采集Serverless实例的指标，并基于分布在各个区域的监控数据进行智能异常检测、根因分析。
以上也将云厂商和学术界共同打造高效且易用的Regionless下Serverless平台，共同面临的挑战。
参考文献
[1] J. Schleier-Smith, et. al. "What serverless computing is and should become: The next phase of cloud computing," Communications of the ACM, vol. 64, no.5, pp. 76-84, 2021.
[2] Li, Zijun, et. al. "The serverless computing survey: A technical primer for design architecture." ACM Computing Surveys (CSUR), vol. 54, no.10s, pp. 1-34, 2022.
[3] A. Aske, et. al. "Supporting multi-provider serverless computing on the edge," in Proc. Int. Conf. Parallel Processing Companion, 2018.
[4] G. Zheng, et. al. "GlobalFlow: a cross-region orchestration service for serverless computing services," in Proc. IEEE Int. Conf. Cloud Comput. (CLOUD), 2019.
[5] C. Smith, et. al. "Fado: Faas functions and data orchestrator for multiple serverless edge-cloud clusters," in Proc. IEEE Int. Conf. Fog and Edge Comput. (ICFEC), 2022.
[6] S. Ristov, et. al, "FaaSt: Optimize makespan of serverless workflows in federated commercial FaaS," in Proc. IEEE Int. Conf. Cluster Comput. (CLUSTER), 2022.
[7] A. Baarzi, et. al. "On merits and viability of multi-cloud Serverless," in Proc. ACM Symp. Cloud Comput., 2021.
[8] H. Zhao, et al. "Supporting Multi-Cloud in Serverless Computing," arXiv preprint arXiv:2209.09367, 2022.
[9] A. Mampage, et. al. "A holistic view on resource management in serverless computing environments: Taxonomy and future directions," ACM Computing Surveys (CSUR), vol. 54, no. 11s, pp. 1-36, 2022.
添加小助手微信k8s2222，进入云原生交流群
KubeEdge云原生边缘计算安全防护的实践与洞察
作者：华为云云原生团队 林国辉
随着开源软件安全漏洞持续引起世界各地政府和企业的关注，越来越多的组织、开发人员、研究人员和安全专家投入到开源安全工作中，在各方力量的推动下，开源安全目前已初步形成体系化的生态大网，覆盖了国际化的软件工程行业标准、安全评估体系、安全工具链与整体解决方案等，并逐步撬动整个业界开源软件安全行业的生态产业链。在2020年Linux基金会与多家硬件和软件厂商合作创立了开源软件安全基金会OpenSSF（Open Source Security Foundation），这是一个跨行业的合作组织，汇集了行业领军企业与机构，涵盖世界上最重要的软件供应链安全计划、开源开放的工具链、安全指南、培训等，旨在提高开源软件（OSS）的安全性。
作为业界首个云原生边缘计算项目，KubeEdge社区致力于提升KubeEdge在云原生边缘计算场景下的安全性，将安全视为社区发展的重要指导原则。社区充分结合了业界的开源安全经验，于2022年7月完成了对KubeEdge项目的安全威胁模型分析。尽管云原生边缘计算的安全问题备受用户关注，但业界目前缺乏相关的安全威胁模型分析，这使得用户难以有效地加固其边缘系统。因此，KubeEdge社区发布了安全威胁模型及分析白皮书，为用户和厂商提供了重要的安全实践指导。下文将着重介绍Kubeedge在安全防护方面的实践，并介绍OpenSSF在开源软件安全方面的计划与目标。
KubeEdge安全防护
安全防护背景
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）。
安全加固建议列表
Recommendation ID |
描述 |
1 |
使用安全长度的私钥加密，并加密保存私钥。建议用户生成至少为2048位私钥，且在本地加密存储私钥，存储私钥的文件设置最小化的访问权限，仅属主可读。 |
2 |
使用可信来源的CA证书。从可信的CA获取数字证书，不使用自签名证书。 |
3 |
严格限制边缘节点的本机权限，限制外部用户的用户登录权限，减少非必要的授权。 |
4 |
严格限制边缘节点应用部署的权限，只有系统服务和管理员才能拥有部署特权容器的权限。 |
5 |
在边缘节点部署应用时，严格校验应用镜像的合法性，防止部署恶意应用。 |
6 |
对于接入边缘节点的Device设备进行严格审核，避免非必要设备接入。 |
7 |
严格审查CRI插件的配置，使用CRI对应插件的官方推荐配置。 |
8 |
严格划分系统中各个角色权限，通过RBAC、OPA等方式实现系统角色权限的细粒度控制。 |
9 |
社区发现漏洞后将在最近的3个minor release版本中合入解决，用户可以关注社区security advisory 获取漏洞披露信息，及时跟进并更新KubeEdge版本。 |
10 |
用户使用社区发布的二进制文件前，应该根据社区发布的校验文件进行严格校验，防止二进制被仿冒和篡改。社区release软件包发布地址https://github.com/kubeedge/kubeedge/releases。 |
11 |
用户或vendors在使用源代码构建过程中，应该参考SLSA软件供应链安全评估框架，对源代码、构建流程、依赖库等进行安全加固。 |
开源安全洞察
本章节通过对OpenSSF社区的战略规划、OpenSSF工作组内容及开放源代码软件安全动员10个TOP计划进行介绍，为相关从业人员、开源生态产业提供参考。
1) OpenSSF介绍
社区工作组
为了更好的提升开源软件安全，OpenSSF目前已成立了8个工作组，主要负责开源软件开发最佳实践、软件代码安全、用户、安全工具链、开源项目安全威胁识别、软件供应链完整性、保护关键开源项目、漏洞披露。
相关项目
1. OpenSSF最佳实践徽章（OpenSSF Best Practices Badge Program）
开源软件开发的最佳实践目的是提供开源开发者安全相关行业标准、框架、安全指导、课程、开源安全评估体系、包括工具支持开发人员日常开发过程的软件安全检测。开源项目可以通过OpenSSF最佳实践徽章项目进行最佳实践评估，该项目是自由/开源软件（FLOSS）项目展示其遵循最佳实践的一种方式。可以通过使用这个网站来解释他们如何遵循每个最佳实践，从而自愿地进行自我认证，认证分为通过、银、金三个级别，不需要任何费用。该项目是基于核心基础设施倡议（CII）项目发展而来。
2. 积分卡（Scorecards）
通过Scorecards积分卡项目可以实现自动化地对开源项目相关安全指标进行评估，以加强项目的安全状况，根据项目的评估结果给出0-10分数，帮助项目maintainer改进项目安全。
3. 安全知识框架（Security Knowledge Framework）
SKF是一个完全开源的Python-Flask / Angular网络应用程序，它使用许多其他的开源项目来训练你和你的团队通过设计来构建安全的应用程序。其涵盖了整个软件开发生命周期如构建、测试、需求、设计、代码开发、度量、培训等环节。
4. 安全开发指南
提供安全开发、安全评估的详细指导步骤，以开发者使用视角将上面的项目全部串接起来，已完整覆盖了OpenChain Security Assurance Specification、SLSA、工具如 GitHub's dependabot、GitLab dependency scanning、Scorecards check等。
5. 教育与培训课程
提供开发人员免费的安全开发课程，完成学习后可以发放证书有效期2年。
6. 软件构建供应链级别（SLSA）
软件构建的供应链级别SLSA由Google贡献给OpenSSF，是软件供应链完整性的安全标准准则，以帮助企业和开源生态确保软件开发生命周期的安全，ScoreCards是SLSA度量的工具组成部分。
7. 令牌分发项目
Great Multi-Factor Authentication (MFA) 分发项目。致力于将硬件 MFA 令牌分发给关键的 100+开源软件项目，目标是防止开源软件开发凭据薄弱或受损的供应链攻击。
8. 包管理最佳实践
提供业界主流的构建框架、包管理器的最佳实践如 maven、gradle、npm、pip、RubyGems，重点介绍其依赖管理、可重复构建、发布、基于包管理的漏洞披露等。
当前文档还不完善，只重点介绍了npm，其它的包管理器待建设中。
9. C/C++编译选项
制定 C/C++场景的编译选项规则，避免潜在的安全风险和被攻击的风险。当前在孵化阶段。
10. 开源社区安全教育SIG
当前在孵化阶段，主要致力于提供行业标准的安全软件开发相关的培训材料，提供网络和应用程序安全方面的最佳实践辅导开发人员安全地创建、编写、部署和维护软件。
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工作组是相辅相成的，其动员计划的能力会融入到工作组中。
投资方向 |
描述 |
安全培训 |
向所有人提供基础安全软件开发培训和认证。 |
风险评估 |
为前 10,000 个（或更多）OSS 组件建立一个公开的、供应商中立的、客观的、基于指标的风险评估仪表板。 |
数字签名 |
加快在软件版本上采用数字签名。 |
内存安全 |
通过替换非内存安全语言来消除大多数漏洞的根本原因。 |
事件响应 |
建立一个由安全专家组成的 OpenSSF 事件响应团队，以协助开源项目加快对新发现漏洞的响应速度。 |
安全扫描 |
通过高级安全工具和专家指导，加快维护人员和专家发现新漏洞的速度。 |
代码审计 |
每年对200+个最关键的OSS组件进行一次第三方代码审查（以及任何必要的补救工作）。 |
数据共享 |
协调全行业的数据共享，以改善研究，帮助确定最关键的开放源码软件组件。 |
SBOMs |
改进SBOM工具和培训，以推动采用。 |
提升软件供应链安全 |
用更好的供应链安全工具和最佳实践来增强10个关键的开放源码软件构建系统、软件包管理器和分发系统。 |
总结
本文通过从外部攻击面、内部攻击面及软件供应链三个维度对KubeEdge项目进行安全威胁建模，实现对KubeEdge项目的系统性安全评估，帮助社区maintainer及时发现和修复安全风险。同时，对业界OpenSSF社区开源安全策略及相关项目进行洞察，通过洞察分析可以看出，越来越多的组织、开发人员、研究人员和安全专家将加大投入资源来加强开源安全，并已逐步形成业界开源安全行业的生态产业链，在开源安全上占据标准高地可以为后续的商业扩展提供有力地位。KubeEdge社区结合业界安全理念，将能够推动社区持续巩固和演进项目的安全。
附录
相关链接
• 社区漏洞处理机制: https://github.com/kubeedge/kubeedge/security/policy
• 社区security advisory链接: https://github.com/kubeedge/kubeedge/security/advisories
• KubeEdge威胁模型及安全防护分析（本文档）: https://github.com/kubeedge/community/tree/master/sig-security/sig-security-audit/KubeEdge-threat-model-and-security-protection-analysis.md
• 社区用户文档链接: https://kubeedge.io/en/docs
• SLSA软件供应链安全框架: https://slsa.dev/spec/v0.1/#supply-chain-threats
• KubeEdge实现SLSA L3分析: https://kubeedge.io/en/blog/reach-slsa-l3/
• Release版本发布链接: https://github.com/kubeedge/kubeedge/releases
• 开源软件安全动员计划：https://cta-redirect.hubspot.com/cta/redirect/8112310/3b79d59d-e8d3-4c69-a67b-6b87b325313c
• OpenSSF最佳时间徽章：https ://bestpractices.coreinfrastructure.org/en
• 最佳实践项目：https://github.com/ossf/wg-best-practices-os-developers
添加小助手微信k8s2222，进入云原生交流群
为云云原生团队：Istio数据面新模式 Ambient Mesh技术解析
作者：华为云云原生团队 姚增增
如果说在以Kubernetes为基础构建起的云原生世界里，哪种设计模式最为经典，Sidecar模式无疑是其中最有力的竞争者。当需要为应用提供与自身逻辑无关的辅助功能时，在应用Pod内注入对应功能的Sidecar显然是最Kubernetes Native的方式，而Istio则是这种模式的代表。
Istio项目的愿景是以尽量透明的方式，解决微服务场景下，服务间的连接、安全以及可观测性问题。主要实现手段则是通过在应用旁部署一个Proxy，在Kubernetes场景下则为应用Pod注入Sidecar，拦截应用流量至Sidecar。Sidecar根据从Istio控制面获取的用户配置对应用流量进行处理，以一种对应用代码几乎无侵入的方式实现了服务治理。
图1
虽然Istio并不局限于仅支持Kubernetes平台，但是Istio的设计理念与Kubernetes的Sidecar模式有着天然的亲和性。基于Sidecar模式，Istio能够实现在Kubernetes平台上的快速开发、部署、验证。同时，在功能层面，Isito将服务治理功能从应用代码中剥离，作为基础设施下沉至Sidecar，抽象出了事实上的云原生应用网络层，极大地减轻了应用开发者的心智负担，这部分能力刚好也是Kubernetes生态一直以来缺失的。基于Istio对于Kubernetes生态的完美补充，随着Kubernetes的大规模普及，Istio也实现了对用户心智以及市场的快速抢占。
虽然以Sidecar模式部署Istio数据面似乎是一个理所应当，让人无法拒绝的选择，但是需要强调的是，Istio完整功能的实现并不与Sidecar模式强绑定，我们还有各种各样其他的选择。另外，随着对于Istio使用程度不断加深，落地规模不断扩大，可以发现以Sidecar模式部署Istio数据面诸多挑战：
1. 侵入性：Istio基本实现了对应用代码的零侵入，但是由于Sidecar的注入需要更改Pod Spec并且对应用流量进行重定向，因此应用接入网格时需要重启Pod，而应用容器与Sidecar容器的启动顺序不确定造成的冲突也可能导致应用中断；
2. 生命周期绑定： Sidecar本质上是基础设施，它和应用的生命周期往往不一致，因此升级Sidecar时也需要对应用Pod进行重启，同样可能导致应用中断，而对于Job类应用，Sidecar的存在则会导致Pod无法被及时清理；
3. 资源利用率低：Sidecar为单个应用Pod独占，应用的流量存在波峰波谷，而一般情况下Sidecar的内存占用与集群规模（Service数目，Pod数目）强相关，因此需要按照极端情况预留资源，导致集群整体的资源利用率低。同时由于需要为每个Pod注入Sidecar，随着集群规模的不断扩大，Sidecar占用的资源总量也会线性上涨。
针对Sidecar部署模式的缺陷，Google和Solo.io联合推出了一种新的Sidecar-less部署模式 --- Ambient Mesh。
架构介绍
图2
Ambient Mesh架构如上图所示，从设计的角度来看，它主要有以下两个特点：
1. Sidecar-less：为了避免上述Sidecar模式的种种缺陷，Ambient Mesh不再为任何Pod注入Sidecar，将网格功能的实现进一步下沉到Istio自有组件中。
2. L4/L7处理分层：Ambient Mesh引入了ztunnel和waypoint两个组件用于代替原来的Sidecar实现相关功能，与Sidecar既能处理L4，又能处理L7流量的实现方式不同，Ambient Mesh对两者进行了区分，ztunnel只负责L4流量的处理，L7的流量则按需交由waypoint处理。
Ambient Mesh的控制面与原先Sidecar模式的Istio相比基本没有变化，数据面的组件构成以及各个组件的作用如下：
1. istio-cni：必装组件，以DaemonSet的形式部署。其实istio-cni并不是Ambient Mesh的新增组件，在原先的Sidecar模式中就已经存在，当时主要用于替代istio-init这个Init Container配置流量拦截规则，同时规避istio-init引发的安全问题。Ambient Mesh对它进行了扩展，以必装组件的形式部署，负责配置流量转发规则，劫持本节点中已加入Ambient Mesh的Pods的应用流量，转发至本节点的ztunnel；
2. ztunnel: 必装组件，以DaemonSet的形式部署。ztunnel对所在节点Pods的流量进行代理，主要负责L4流量的处理、L4的遥测以及服务间mTLS（双向认证）的管理。最初ztunnel基于Envoy实现，但是考虑到对ztunnel功能的有意约束以及对安全性、资源占用率的要求，社区已经用rust从零构建该组件；
3. waypoint：按需配置，以Deployment的形式部署。waypoint负责处理HTTP，故障注入等L7功能。以负载或者Namespace粒度进行部署，在Kubernetes中，即一个Service Account或者一个Namespace对应生成一个waypoint的Deployment，用于处理发往对应负载的七层流量，同时waypoint实例数可以根据流量动态伸缩。
图3
下面以Ambient Mesh数据面实际的处理过程来展示上述各个组件在其中扮演的具体角色：
1. 与Sidecar模式类似，Ambient Mesh也能以网格、Namespace以及Pod的粒度将服务加入网格；不同的是，新加入的Pod无需重启，更不需要注入Sidecar；
2. istio-cni监听本节点内Pods的增删以及进出网格的情况，动态调整转发规则，网格内Pods发出的流量会被透明地转发至本节点的ztunnel，直接跳过kube-proxy的处理；
3. ztunnel同样需要对本节点Pods的增删以及进出网格的情况进行监听，从控制面获取位于本节点且被网格接管的Pods的证书并进行管理；
4. 源端ztunnel对拦截的流量进行处理，根据流量的源IP找到对应Pod的证书，由此和对端建立mTLS；
5. 如果要访问的目标服务没有配置waypoint或者没有配置L7相关的处理策略，则源端ztunnel直接和目的端ztunnel建立连接（如上图黄线标注），对端的ztunnel终止mTLS，执行L4安全策略，将流量转发到目标Pod；
6. 如果目标服务配置了waypoint（利用特殊配置的Gateway对象）以及L7的处理策略，则源端ztunnel会和对应的waypoint建立mTLS，waypoint终止mTLS后，进行L7的逻辑处理，之后再与目标Pod所在节点的ztunnel建立mTLS，最终同样由目的端的ztunnel终止mTLS并将流量发往目标Pod。
价值分析
虽然从底层实现来看，Ambient Mesh和原有的Sidecar模式的差别巨大，但是从用户面看，两者在核心Istio API（VirtualService, DestinationRules等）的使用方式、实现效果都是一致的，能够确保基本相同的用户体验。Ambient Mesh是Istio社区除Sidecar模式外，支持的第二种数据面模式，所以网格技术本身能为用户带来的价值，Ambient Mesh与先前的Sidecar模式并不二致。因此这里只对Ambient Mesh相对于原生Sidecar模式的价值进行分析，对于网格本身的价值不再赘述。
Ambient Mesh主要是针对Istio的数据面架构进行调整，用于克服既有Sidecar模式的不足，因此它的价值产生必然是基于其架构特点。前文已经提到过Ambient Mesh的架构特点主要有“Sidecar-less”和“L4/L7处理分层”这两点，下面就从这两点出发进行价值分析：
1. Sidecar-less的优势，其实可以看作Sidecar模式缺陷的对立面：
a) 透明：网格功能下沉至基础设施，不仅对应用代码零侵入，和应用的生命周期也完全解耦，做到真正对应用透明，允许应用与网格独立演进；
b) 优化资源占用：数据面占用的CPU、内存等资源不再随着实例数线性增长，随着数据面的实例数减少，与控制面的连接数也相应减少，极大地减轻控制面的资源与处理压力。
2. 对于为什么要对L4/L7进行分层处理，首先要区分两者之间的区别。与L4相比，L7的处理更为复杂，需要占用更多的CPU/内存等资源，不同类型的操作之间资源占用也存在较大差别；同时操作越复杂暴露的攻击面越大。另外Envoy当前并不支持对不同租户的流量进行强隔离，“Noisy Neighbor”的问题不可避免。因此Ambient Mesh分层处理架构的优势如下：
a) 资源利用率高：ztunnel仅负责L4的处理，L4处理较为简单且资源占用较为固定，所以更易对ztunnel进行资源规划，无需过量预留资源，能够将更多的节点资源供用户使用；waypoint更可以根据L7负载动态扩缩容，充分利用集群中的资源碎片；
b) 租户隔离：处理复杂、安全风险高的L7处理由租户（Service Account）各自的waypoint处理，既避免了租户间的资源抢占，又限制了安全问题的爆炸半径；
c) 平滑落地：允许用户逐步接入网格，当仅需网格的L4处理能力时，完全无需考虑L7的资源占用以及可能造成的潜在负面影响（例如：因为错误配置导致进入L7处理而应用并未完全遵守L7协议，导致服务中断），之后在适当时刻按需开启相关功能即可。
当然Ambient Mesh作为Istio全新的数据面架构，在社区中依然以实验特性的形式存在，仍然有许多问题亟待解决，例如：
1. 性能：尤其是针对L7的处理，Ambient Mesh需要经过两个ztunnel以及一个waypoint，肉眼可见地又额外增加了一跳，因此完整的L7处理需要额外经过三跳。虽然社区声称这对性能的影响很小，但是仍需待其特性稳定后进一步观察对比；
2. 容器网络适配：虽然Ambient Mesh与应用基本实现了完全解耦，但是反过来也增加了网格与底层基础设施的耦合，Sidecar模式仅需在Pod的net ns实现流量的拦截处理，但是Ambient Mesh在主机网络进行流量拦截，显然需要更多考虑与底层容器网络的适配；
3. 配置复杂：原本Envoy复杂的配置就被广为诟病而Ambient Mesh更需要实现一个ztunnel对节点所有Pods的代理，配置复杂度更是上升一个数量级，同时配置的复杂意味着处理流程的增加，也会对数据面的排错以及整体性能造成影响；
4. 其他：ztunnel的高可用？waypoint事实上将原本双端的L7处理变为了单端，对L7监控指标正确性的影响？…
未来展望
从版本发布的角度，自从2022年9月份发布以来，Ambient Mesh一直作为实验特性存在于独立的分支之中。因此对于Ambient Mesh下一步的计划就是合入主干分支（已于2023年2月实现）并作为Alpha特性发布，最终在2023年底到达Stable，实现生产可用。
从API的角度，最理想的是能在两种架构下共用同一套API。当然这是不现实的，因为已有的一部分Istio API是以Sidecar模式部署为前提条件设计的。最典型的就是Sidecar这个CRD，它用于定制化下发至不同Sidecar的配置，从而减少Sidecar不必要的资源占用。这些Sidecar-Only的API显然在Ambient Mesh下毫无意义。同时，Ambient Mesh自身也引入了ztunnel和waypoint两个独有组件，因此Ambient Mesh也需要创建新的API，用于管理这些独有组件以及实现一些Ambient Mesh Only的功能。最终Ambient Mesh会实现已有的核心Istio API（VirtualService, DestinationRules等）并创建一些其独有的API，重要的是做到三类API（Sidecar模式独有、Ambient Mesh独有、两者共有）统一的使用与交互。
那么Ambient Mesh是否做到了对Sidecar模式使用场景的全覆盖，从而让Sidecar模式彻底退出历史舞台了呢？答案自然是否定的，类似于业界各种独占模式和共享模式之争，Sidecar模式本质上是应用Pod对Proxy的独占。专属的Proxy往往能保证更好的资源可用性，尽量避免其他应用的影响，确保高优先级应用的正常运行。可以预见，最终两种模式的混合部署，应用按需选择代理模式是更为理想的方式。所以构建混合部署模式，保证该模式下两种模式的良好兼容性和统一的体验也将是后续工作的重点。
总结
Sidecar模式对于Istio就像一场原型验证，以一种最Kubernetes Native的方式快速展示网格技术的价值，抢占用户认知和市场。不过随着Istio的落地逐渐进入深水区，开始在生产环境大规模部署，Sidecar模式就显得力不从心了。此时Ambient Mesh以一种更符合大规模落地要求的形态出现，克服了大多数Sidecar模式的固有缺陷，让用户无需再感知网格相关组件，真正将网格下沉为基础设施。
但是显然Ambient Mesh并不是网格数据面架构演进的终点。当前还没有一种网格数据面方案能在侵入性、性能、资源占用等各个考量维度做到完美。Ambient Mesh基本做到了对应用的零侵入，但是L7的三跳处理引发的性能问题，ztunnel等常驻进程的资源占用令人无法忽视；gRPC等RPC库通过内置实现xDS，直连Istio控制面，将网格杂糅进SDK，确实能实现很好的性能和资源占用表现，只是不可避免地需要付出与应用强耦合、多语言支持复杂度高等固有代价；基于eBPF直接将全套网格数据面功能像TCP/IP协议栈一样下沉到内核貌似是理想的终局方案，只是考虑到内核安全以及与内核交互的复杂性，eBPF的执行环境其实是非常受限的，例如eBPF程序加载到内核前必须经过verifier的校验，执行路径必须完全已知，无法执行任意的循环。因此对于HTTP/2，gRPC等复杂的L7处理，基于eBPF的开发和维护都会比较困难。
考虑到基础设施对性能、资源损耗的极致要求以及过往相关技术的演进规律，例如对于基础网络，绝大多数应用共享使用内核协议栈即可，部分特殊应用利用DPDK，RDMA等专用技术进行加速。同样，对于网格数据面，多种技术结合，分别优化相应场景的解决方案，可能是更具可行性的。可以预见，这类方案基本上是以类Ambient Mesh的节点级代理作为主体，随着网格以及eBPF技术的发展，将尽量多的网格数据面功能下沉至eBPF（Fast Path）实现；少部分高级功能交由用户态的Proxy（Slow Path）实现；那些对性能、隔离性等有较高要求的应用，则为其部署专属的Sidecar。这样一来，就能满足绝大多数场景下，对侵入性、性能、资源占用等各个维度的要求。
综上 ，最终是一套数据面方案一统天下，还是各种方案混合部署，取各家所长，仍有待对相关技术不断探索演进，再用实践检验，最后让时间告诉我们答案。
参考文献
[1] Istio Ambient Mesh Explained: https://lp.solo.io/istio-ambient-mesh-explained
[2] What to expect for ambient mesh in 2023: https://www.solo.io/blog/ambient-mesh-2023
[3] Introducing Ambient Mesh: https://istio.io/latest/blog/2022/introducing-ambient-mesh
[4] Get Started with Istio Ambient Mesh: https://istio.io/latest/blog/2022/get-started-ambient
Karmada百倍集群规模多云基础设施体系揭秘
作者：华为云云原生团队 沈铁成
随着云原生技术在越来越多的企业和组织中的大规模落地，如何高效、可靠地管理大规模资源池以应对不断增长的业务挑战成为了当下云原生技术的关键挑战。
在过去的很长一段时间内，不同厂商尝试通过扩展单集群的规模来扩展资源池。然而，Kubernetes社区很早就发布了大规模集群的最佳实践，其中包括几项关键数据：节点数不超过5k，Pod数不超过150k，单个节点的Pod数量不超过110 k等。这侧面说明了支持超大规模的集群不是Kubernetes社区主要努力的方向。同时，以单集群的方式扩展资源池通常需要定制Kubernetes的原生组件，这在增加了架构复杂度的同时也带来了不少弊端：
（1）集群运维复杂度急剧增加。
（2）与社区演进方向相左，后续的维护成本上升，升级路径不清晰。
（3）单集群本质上属于单个故障域，集群故障时将导致无法控制爆炸半径。
而多集群技术能在不侵入修改Kubernetes单集群的基础上横向扩展资源池的规模，在扩展资源池的同时降低了企业的运维管理等成本。此外，多集群系统天然支持多故障域，符合多数业务场景，如多地数据中心、CDN就近提供服务等。
Karmada作为CNCF首个多云容器编排项目，提供了包括Kubernetes原生API支持、多层级高可用部署、多集群故障迁移、多集群应用自动伸缩、多集群服务发现等关键特性，致力于让用户轻松管理无限可伸缩的资源池，为企业提供从单集群到多云架构的平滑演进方案。
随着以Karmada为代表的多集群架构在企业的逐步落地，大规模场景下多集群系统的性能问题往往是用户的核心关注点之一。本文将围绕以下几个问题，结合Karmada社区对大规模场景的思考，揭示Karmada稳定支持100个大规模集群、管理超过50万个节点和200万个Pod背后的原理。
（1） 如何衡量一个多集群系统资源池的维度与阈值？
（2） 对多集群系统进行大规模环境的压测时，我们需要观测哪些指标？
（3） Karmada是如何支撑100个大规模K8s集群并纳管海量应用的？
（4） 在Karmada的生产落地过程中，有哪些最佳实践和参数优化手段可以参考？
多集群系统资源池的维度与阈值
当前，业界对于多云资源池的Scalability尚未达成统一标准，为此，Karmada社区结合企业用户的实践，率先对这一问题进行了深入探索。一个多集群系统资源池规模不单指集群数量，实际上它包含很多维度的测量标准，在不考虑其他维度的情况下只考虑集群数量是毫无意义的。在若干因素中，社区按照优先级将其描述为以下三个维度：
（1） 集群数量。集群数量是衡量一个多集群系统资源池规模和承载能力最直接且最重要的维度。
（2） 资源（API对象）数量。对于多集群系统的控制面来说，存储并不是无限的，在控制面创建的资源对象的数量和总体大小受限于系统控制面的存储，也是制约多集群系统资源池规模的重要维度。这里的资源对象不仅指下发到成员集群的资源模板，而且还包括集群的调度策略、多集群服务等资源。
（3） 集群规模。集群规模是衡量一个多集群系统资源池规模不可忽视的维度。一方面，集群数量相等的情况下，单个集群的规模越大，整个多集群系统的资源池越大。另一方面，多集群系统的上层能力依赖系统对集群的资源画像，例如在多集群应用的调度过程中，集群资源是不可或缺的一个因素。综上所述，单集群的规模与整个多集群系统息息相关，但单集群的规模同样不是制约多集群系统的限制因素。用户可以通过优化原生的Kubernetes组件的方式来提升单集群的集群规模，达到扩大整个多集群系统的资源池的目的，但这不是衡量多集群系统性能的关注点。在集群的标准配置中，Node与Pod毫无疑问是其中最重要的两个资源，Node是计算、存储等资源的最小载体，而Pod数量则代表着一个集群的应用承载能力。
大规模场景下多集群系统的性能指标
在多集群系统的大规模落地进程中，如何衡量多集群联邦的服务质量是一个不可避免的问题。在参考了Kubernetes社区的SLI(Service Level Indicator)/SLO(Service Level Objectives)和多集群系统的落地应用后，Karmada社区定义了以下SLI/SLO来衡量大规模场景下多集群联邦的服务质量。
API Call Latency
Status |
SLI |
SLO |
Official |
最近5min的单个Object Mutating API P99 时延 |
除聚合API和CRD外，P99 <= 1s |
Official |
最近5min的non-streaming read-only P99 API时延 |
除聚合API和CRD外 P99 :(a) <= 1s if scope=resource (b) <= 30s otherwise (if scope=namespace or scope=cluster) |
注：API调用时延仍然是衡量基于Kubernetes的多集群系统服务质量的关键指标。Karmada兼容Kubernetes原生API，用户除了使用原生API创建K8s的资源模板外，也可以使用Karmada自有API来创建多集群策略和访问跨集群的资源。
Resource Distribution Latency
Status |
SLI |
SLO |
Official |
用户在联邦控制面提交资源模板和下发策略后到资源在成员集群上被创建的P99时延，不考虑控制面与成员集群之间的网络波动 |
P99 <= 2s |
Cluster Registration Latency
Status |
SLI |
SLO |
WIP |
集群从接入联邦控制面到状态能被控制面正常收集的P99时延，不考虑控制面与成员集群之间的网络波动 |
TBD |
注：集群注册时延是从集群注册到控制面到集群在联邦侧可用的时延，它反映了控制面接入集群以及管理集群的生命周期的性能。但它在某种程度上取决于控制面如何收集成员集群的状态。因此，我们不会对这个指标进行强制的限制。
Resource Usage
Status |
SLI |
SLO |
WIP |
在接入一定数量的集群后集群联邦维持其正常工作所必需的资源使用量 |
TBD |
注：资源使用量是多集群系统中非常重要的指标，我们希望在纳管海量的集群和资源的同时消耗尽量少的系统资源。但由于不同的多集群系统提供的上层服务不同，因此对于不同的系统，其对资源的要求也会不同。因此，我们不会对这个指标进行强制的限制。
Karmada百倍集群规模基础设施揭秘
Karmada社区在结合对上述两个问题的思考以及用户在落地过程中的反馈后，测试了Karmada同时管理100个5K节点和2w Pod的Kubernetes集群的场景。本文不详细描述具体的测试环境信息与测试过程，而是侧重于对测试结果进行分析
在整个测试过程中，API调用时延均符合上述定义的SLI/SLO。
图一：只读API（cluster-scope）调用时延
图二：只读API(namespace-scope)调用时延
图三：只读API(resource-scope)调用时延
图四：Mutating API调用时延
Karmada在百倍集群规模下，仍能做到快速的API响应，这取决于Karmada独特的多云控制面架构。事实上，Karmada在架构设计之初就采用了关注点分离的设计理念，使用Kubernetes原生API来表达集群联邦资源模板，使用可复用的策略API来表达多集群的管理策略，同时控制面的资源模板作为应用的模板，不会在控制面生成具体的Pod。不同集群的应用在控制面的映射（Work对象）通过命名空间来进行安全隔离。完整的API工作流如下图所示。如此设计，不仅可以让Karmada能够轻松集成Kubernetes的生态, 同时也大大减少了控制面的资源数量和承载压力。基于此，控制面的资源数量不取决于集群的数量，而是取决于多集群应用的数量。
此外，Karmada的架构极具简洁性和扩展性。karmada-apiserver作为控制面的入口与kube-apiserver类似，即使是在百倍集群规模下，Karmada仍能保持快速API响应。
Karmada支持通过命令行快速接入集群，以及集群的全生命周期管理。Karmada会实时采集集群心跳和状态，其中集群状态包括集群版本、支持的API列表、集群健康状态以及集群资源使用量等。其中，Karmada会基于集群资源使用量对成员集群进行建模，这样调度器可以更好地为应用选择资源足够的目标集群。在这种情况下，集群注册时延与集群的规模息息相关。下表展示了加入一个5,000节点的集群直至它可用所需的时延。你可以通过关闭集群资源建模来使集群注册时延与集群的大小无关，在这种情况下，集群注册时延这个指标将小于2s。
Cluster Registration Latency:
metric |
P50(ms) |
P90(ms) |
P99(ms) |
SLO |
cluster_register |
5356 |
6125 |
6904 |
N/A |
Karmada支持多模式的集群统一接入，在Push模式下，Karmada控制面直连成员集群的kube-apiserver，而在Pull模式下，Karmada将在成员集群中安装agent组件，并委托任务给它。因此Push模式多用于公有云的K8s集群，需要暴露APIServer在公网中，而Pull模式多用于私有云的K8s集群。下表展示了Karmada在不同模式下下发一个应用到成员集群所需的时延。
Resource Distribution Latency:
Metric |
P50(ms) |
P90(ms) |
P99(ms) |
SLO |
cluster_schedule |
12 |
15 |
32 |
N/A |
resource_distribution(Push) |
706 |
899 |
1298 |
2000 |
resource_distribution(Pull) |
612 |
881 |
989 |
2000 |
结论：我们容易得出，不论是Push模式还是Pull模式，Karmada都能高效地将资源下发到成员集群中。
在Karmada演进的数个版本中，大规模场景下使用Karmada管理多云应用的资源消耗一直是用户比较关注的问题。Karmada社区做了许多工作来减少Karmada管理大型集群的资源使用量，比如我们优化了Informer的缓存，剔除了资源无关的节点、Pod元数据；减少了控制器内不必要的类型转换等等。相较于1.2版本，当前Karmada在大规模集群场景下减少了85%的内存消耗和32%的CPU消耗。下图展示了不同模式下Karmada控制面的资源消耗情况。
Push模式：
Pull模式：
总的来说，系统消耗的资源在一个可控制面的范围，其中Pull模式在内存使用上有明显的优势，而在其他资源上相差的不大。
Karmada大规模环境下的最佳实践
Karmada支持性能参数的可配置化，用户可以通过调整组件的参数来调整同一时间段内并发处理Karmada内部对象的数量、系统的吞吐量等以优化性能。同时Karmada在不同模式下的性能瓶颈并不相同，以下着重对此进行分析。
在Push模式中，控制面的资源消耗主要集中在karmada-controller-manager（约70%），而Karmada控制面基座（etcd/karmada-apiserver）的压力不大。
结合karmada-apiserver的qps以及karmada-etcd的请求时延我们可以看出karmada-apiserver的请求量保持在一个较低的水平。在Push模式中，绝大多数的请求来自karmada-controller-manager。因此我们可以通过调整karmada-controller-manager的--concurrent-work-syncs来调整同一时间段并发work的数量来提升应用下发的速度，也可以配置--kube-api-qps和--kube-api-burst这两个参数来控制Karmada控制面的整体流控。
在Pull模式中，控制面的资源消耗主要集中在karmada-apiserver，而不是karmada-controller-manager。
结合karmada-apiserver的qps以及karmada-etcd的请求时延我们可以看出karmada-apiserver的请求量保持在一个较高的水平。在Pull模式中，每个成员集群的karmada-agent需要维持一条与karmada-apiserver通信的长连接。我们很容易得出：在下发应用至所有集群的过程中请求总量是karmada-agent中配置的N倍(N=#Num of clusters)。因此，在大规模Pull模式集群的场景下，Pull模式在资源下发/状态收集方面有更好的性能，但同时需要考虑控制面的抗压能力以及各个karmada-agent和控制面的整体流控。
当前，Karmada提供了集群资源模型的能力来基于集群空闲资源做调度决策。在资源建模的过程中，它会收集所有集群的节点与Pod的信息。这在大规模场景下会有一定的内存消耗。如果用户不使用这个能力，用户可以关闭集群资源建模来进一步减少资源消耗。
总结
根据上述测试结果分析，Karmada可以稳定支持100个大规模集群，管理超过50万个节点和200万个Pod。在Karmada落地进程中，用户可以根据使用场景选择不同的部署模式，通过参数调优等手段来提升整个多集群系统的性能。
受限于测试环境和测试工具，上述测试尚未测试到Karmada多集群系统的上限，同时多集群系统的分析理论以及测试方法仍处于方兴未艾的阶段，下一步我们将继续优化多集群系统的测试工具，系统性地整理测试方法，以覆盖更大的规模和更多的典型场景。
添加小助手微信k8s2222，进入云原生交流群
- 点赞
- 收藏
- 关注作者
评论（0）