作者：华为云云原生团队Gateway API是一个开源的API标准，源自Kubernetes SIG-NETWORK兴趣组。从出身角度讲，可谓根正苗红，自从开源以来备受关注，被寄予厚望。Gateway API旨在通过声明式、可扩展性和面向角色的接口来发展Kubernetes服务网络，并且希望成为供应商的网关API标准并获得广泛行业支持。简而言之，Gateway API希望取代Ingress API。Gateway API 项目自2019年开源，但是经历了缓慢的发展，直到2022年7月才发布Beta版本，同时发起了GAMMA（Gateway API for Mesh Management and Administration）。笔者认为这里主要有两方面的原因：- Ingress存在已久，并且是几乎所有的Ingress Controller的默认实现，Kubernetes的用户早已习惯Ingress，尽管Ingress在易用性和功能丰富度上面存在很大的差距。- 服务网格或者API网关项目，例如Istio、Linkerd、Kong、Contour、Ambassador等都有自己的API标准，Gateway API用户接受度还不够高。- 由于Gateway API并没有强大的用户基础，因而缺少功能、体验上的反馈，因而迭代比较缓慢。▍ 什么是GAMMAGAMMA (Gateway API for Mesh Management and Administration)是Gateway API项目的一个工作组。该小组的目标是调查、设计和跟踪网关API资源、语义，并负责其他与服务网格技术和用户使用场景相关的工件。此外，GAMMA倡导服务网格项目的网关API实现之间的一致性，无论Istio还是Linkerd，大家最好都来遵守这里定义的API规范和标准。GAMMA的Lead团队由来自Google的John Howard（Istio），来自微软的Keith Mattix（Open Service Mesh）和来自HashiCorp的Mike Morris（Consul）组成，在不同组织和服务网格项目的推动下，Gateway API有望统一服务网格API。▍ 推波助澜KubeCon EU 2022上，Envoy Gateway的指导组，包括Envoy创始人Matt Klein，以及来自Ambassador、Fidelity 、Tetrate和VMware的代表共同宣布将开源Envoy Gateway项目，将Envoy用作“开箱即用”的基本API网关和Kubernetes Ingress控制器。通过实现Kubernetes Gateway API， EG将会使Envoy扩展更加容易。Envoy上游开源一个网关项目，并且EG是站在Ambassador以及Contour等项目的肩膀上前进，给普通开发者带来无限的遐想。最重要的是，EG是第一个主要实现Gateway API的项目，这一操作也为Gateway API带来新的活力，直接推动Gateway API在7月份发布了Beta版本。  Gateway API 生态 前面提到Envoy Gateway项目宣布以Gateway API为唯一的网关标准，并且EG也是唯一一个只遵守Gateway API标准的Ingress网关项目。其他实现者，都是在自身API的基础上，额外支持Gateway API。并且对Gateway API的支持普遍比较初级：项目名称                    主流支持 Gateway API支持程度Apache APISIXNalphaCiliumNWIPContour NalphaEmissary-Ingress (Ambassador API Gateway)NalphaGloo Edge 2.0NWIPGKE   N公开预览HAProxy IngressNalphaConsul  NalphaIstio NalphaKong  NalphaKuma   NalphaNGINX Kubernetes GatewayNpre-alphaTraefik Nalpha**Envoy Gateway****Y**pre-alphaGateway API绝不仅仅关注南北向流量治理策略的标准，东西向流量也是它所重点覆盖的方向。南北向主要是一些网关项目的领地，东西向是服务网格的领地。当然服务网格如Istio都有自己的Ingress Gateway, 能够对北向流量进行管理。东西向流量从特征上要比南北向流量更多，因为客户端在集群中，可以通过Labels标签表示客户端的属性，通过ServiceAccount标识身份。网格在东西向流量治理时能够充分利用K8s工作负载的标签、身份进行更多的路由、安全策略控制。Gateway API标准在东西向流量这一块目前并没有对等服务网格现有的能力，具体在最后一章再来进行对比。前期Gateway API主要关注的还是南北向的流量治理标准，这与它 “取代Ingress” 的设计初衷相符。  Gatewy AP设计    Gateway API设计 Gateway API基于可移植、可扩展、表达性强以及面向不同角色四个原则设计。- 可移植：相对Ingress来说这一点并不是改进，而是保持与Ingress一致，通过通用的规范，能让更多的网关轻松实现。而Gateway API所追求的领域绝不仅限于南北向网关，而且它还要覆盖服务网格。- 表达性强：Gateway API支持核心功能，如基于Header匹配、流量权重分隔以及其他功能，这些功能只有在Ingress中通过自定义注释Annotation才能实现。- 可扩展：Gateway API允许引用其他的自定义资源对象，这使得在API结构中的适当位置进行个性化定制成为可能。- 面向角色：从上图可见Gateway 由不同的API资源构成，分别为不同的角色设计。其中应用开发者定义HTTPRoute，集群维护者定义Gateway对象，基础设施提供者定义GatewayClass。本章选取面向角色和可扩展性两个最具代表性的设计原则，详细解释Gateway API的设计。▍ 面向角色的API设计无论是道路、电力、数据中心还是Kubernetes集群，基础设施都是为共享而构建的。然而，共享基础架构提出了一个共同的挑战--如何为基础架构的用户提供足够的灵活性，同时保持基础架构所有者的独立控制？Gateway API通过面向角色的设计为K8s服务网络提供灵活的控制，该设计在分布式灵活性和集中控制之间取得了平衡。它允许许多不同的团队使用共享网络基础架构（硬件负载平衡器、云网络、网关等），所有这些团队都受集群维护者设置的策略限制和约束。如下是Gateway API官网的实例，集群维护者通过Gateway定义流量入口，以及TLS Terminate。集群中有两个租户，其中存储开发者在Store命名空间部署了自己的微服务，站点开发者在Site命名空间也部署了自己的微服务。他们在集群网关上共用同一域名，同一端口，因此网关只能通过匹配不同的HTTP Authority来路由客户端的请求。路由策略的设置则是由应用开发者们（Store、Site开发者）自己定义，然后绑定到同一个Gateway上。下面通过一个官方示例，为大家展示不同的角色如何根据自己的权限来定义服务的治理策略。集群维护者通过Gateway定义Listener以及允许绑定的路由策略。如下 *shared-gateway*表示在443端口监听连接，通过 *foo-example-com*证书在网关处做TLS终结。```yaml apiVersion: gateway.networking.k8s.io/v1beta1 kind: Gateway metadata: name: shared-gateway namespace: infra-ns spec: gatewayClassName: shared-gateway-class listeners: - name: https hostname: "foo.example.com" protocol: HTTPS port: 443 allowedRoutes: namespaces: from: Selector selector: matchLabels: shared-gateway-access: "true" tls: certificateRefs: - name: foo-example-com ```集群维护者定义只允许以下命名空间的路由策略能够绑定网关，因为它们有shared-gateway-access: "true"标签。```yaml apiVersion: v1 kind: Namespace metadata: name: infra-ns labels: shared-gateway-access: "true" --- apiVersion: v1 kind: Namespace metadata: name: site-ns labels: shared-gateway-access: "true" --- apiVersion: v1 kind: Namespace metadata: name: store-ns labels: shared-gateway-access: "true" ```这里可以看出，不同角色权限控制比较严格，只有集群维护者允许的路由策略才能绑定到网关上。应用开发者，只能对所拥有的服务具有控制权。▍ 可扩展性-Policy挂载策略挂载提供了高扩展性，虽然超时，重试，以及个性化的健康检查在一些网关实现中很常见，但是大多数网关的实现方式是不同的，没有统一的API标准。保持这类API的一致性变得艰难，所以Gateway API特意设计了Policy挂载，允许在网关、路由中插入个性化的策略控制。  Ingress策略挂载Mesh策略挂载从上图可以看到，无论是Gateway还是HTTPRoute都允许任意引用其他的策略，此设计大大提高了Gateway API的扩展能力。  Gateway API还有多远 Gateway API与其他主流API对比从上述功能丰富度对比来看，Istio API > Gateway API > Ingress, 然而Gateway API通过Reference其他自定义对象提供的扩展能力明显强于Istio。尽管当前Gateway API没有提供故障注入，超时、重试，限流等策略，但是通过它超强的扩展能力能够很容易做到。阅读本文，大家对Gateway API一定充满了好奇，Gateway API距离成熟、大规模商用还有多远？首先从目前的生态分析，Gateway API被Kubernetes圈普遍认可，包括开源项目、甚至商业服务GKE的支持。归根到底，Gateway API由Kubernetes网络组发起、维护，并且吸引了大量开源网络项目的维护者参与。当然实际背后控制者是Google，Google在开源技术的领导力毋庸置疑。但是不得不认识到，目前所有Gateway API的支持都处于初级阶段。其次，从兼容性的角度看，一些成熟的项目，比如Istio，用户长期以来习惯了Istio的API标准，Istio社区也不会贸然的废弃原有的API，转而只支持Gateway API。因此这种多种API并存的局面将会持续很久，即使在未来Gateway API成熟了。最后，前面讲到Gateway API对超时、重试、故障注入等能力预留了扩展能力，但是这种基本的网络能力，Gateway API应该提供标准的API，而不是让用户自己去定义私有的标准。这也违背了Gateway API想要统一服务网络标准的初衷。除此之外，灵活的扩展性如果违背了易用性，显然用户是不会买账的。综上所述，笔者认为至少在一两年之内，Gateway API将会持续迭代，短时间内很难形成成熟的标准。或许可以期待，2024年以后服务网格和API网关的标准将会统一。参考文献1. Kubernetes gateway API官网：https://gateway-api.sigs.k8s.io/2. https://blog.envoyproxy.io/introducing-envoy-gateway-ad385cc595323. Istio官网：https://istio.io/3. Nginx Ingress Controller: https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/技术干货 | 活动报名 | 大咖交流，添加小助手微信k8s2222

作者：华为云云原生团队如果说在以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。架构介绍图2Ambient 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

作者：华为云云原生团队▎边缘计算安全防护的实践与洞察随着开源软件安全漏洞持续引起世界各地政府和企业的关注，越来越多的组织、开发人员、研究人员和安全专家投入到开源安全工作中，在各方力量的推动下，开源安全目前已初步形成体系化的生态大网，覆盖了国际化的软件工程行业标准、安全评估体系、安全工具链与整体解决方案等，并逐步撬动整个业界开源软件安全行业的生态产业链。在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，漏洞公告已发布在cid:link_4。接下来将通过解读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软件包发布地址cid:link_6。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社区结合业界安全理念，将能够推动社区持续巩固和演进项目的安全。▎附录相关链接• 社区漏洞处理机制: cid:link_5• 安全审计报告: cid:link_1• 社区security advisory链接: cid:link_4• KubeEdge威胁模型及安全防护分析（本文档）: cid:link_0• 社区用户文档链接: 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版本发布链接: cid:link_6• 开源软件安全动员计划：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，进入云原生交流群

张嘉伟近年来，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，进入云原生交流群

华为云海外首发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协议设备。• EdgeMes​​h：向边缘隧道模块添加了可配置字段 TunnelLimitConfigedge-tunnel模块的隧道流用于管理隧道的数据流状态。用户可以获得稳定、可配置的隧道流，保证用户应用流量转发的可靠性。KubeEdge云原生边缘计算社区于2022年完成多项关键突破，相继发布《KubeEdge单集群10万边缘节点报告》，《云原生边缘计算威胁模型及安全防护技术白皮书》，并于KubeEdge Summit 2022正式开源分布式协同AI基准测试平台Ianvs。目前项目已完成EdgeMesh高可用架构，KubeEdge on openEuler支持，KubeEdge on openHarmony支持，下一代云原生边缘设备管理框架DMI也将带来更全面的的性能支持与更优的用户体验。欢迎大家测试体验。cid:link_1CNCF持续重视软件供应链安全， 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在该等级下未要求）：RequirementL1L2L3L4SourceVersion controlledYYYVerified historyYYRetained indefinitelyYYTwo-person reviewedYBuildScripted buildYYYYBuild serviceYYYBuild as codeYYEphemeral environmentYYIsolatedYYParameterlessYHermeticYProvenanceAvailableYYYTo-doAuthenticatedYYTo-doService generatedYYTo-doNon-falsifiableYTo-doDependencies completeTo-doCommonSecurityYAccessYSuperusersY为什么达到SLSA L3等级对开源项目至关重要软件供应链完整性攻击（对软件包的未经授权的修改）在过去三年中呈上升趋势。SLSA在KubeEdge项目软件供应链安全中发挥着重要作用，基于sigstore社区提供的能力，从源码到发布产物，对软件供应链端到端的整个流程进行签名和校验，确保KubeEdge软件供应链安全。自v1.13.0版本开始， KubeEdge 可以端到端的从源码构建到发布流程进行安全加固，保障用户获取到的二进制或容器镜像产物不被恶意篡改。基于SLSA安全框架，可以潜在地加强软件构件的完整性。SLSA提供端到端的指导原则，可以作为软件的一组防御措施，并防止对组成软件产品的软件包的篡改或任何类型的未经授权的修改。采用SLSA框架可以保护项目软件免受常见的供应链攻击。参考资料[1]  SLSA官网：https://slsa.dev/[2]   KubeEdge项目第三方安全审计：cid:link_0Karmada 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技术的成熟和社区的快速发展。同时，华为云还大力投入服务网格的技术布道，通过社区论坛、技术会议、视频直播、专业书籍等各种方式，推动服务网格技术传播和普及。添加小助手微信k8s2222，进入云原生交流群

▎直播简介💡【直播主题】Kmesh: 架构创新为服务网格带来全新性能体验🕔【直播时间】2023年11月22日 17:00-18:30👨🏻‍💻【直播专家】吴长冶 华为云云原生DTSE技术布道师、华为云云原生技术专家 Kmesh项目负责人👉【直播简介】传统服务网格代理架构带来数据面的时延开销，无法满足应用SLA诉求，Kmesh为服务网格开启架构创新全新体验！通过将 L4、L7流量治理能力卸载到内核， Kmesh实现内核级云原生流量治理框架，使得服务转发性能分别提升 50%、60%，底噪开销降低 70%，为用户构建服务网格架构高性能方案！🌟【直播精彩看点】Kmesh：流量治理下沉OS，构建sidecarless服务网格高性能：OS原生支持L4~L7的流量编排低底噪：Pod中无需部署代理组件，网格数据面资源开销降低70%平滑兼容：管控面自动对接，与已有数据面协同治理加速全栈可视化：流量治理全栈可视化🔗 直播链接：cid:link_0▎活动介绍🙋🏻‍♂️【互动方式】直播前您可以在本帖留下您疑惑的问题，专家会在直播时为您解答。直播后您可以继续在本帖留言，与专家互动交流。我们会在全部活动结束后对参与互动的用户进行评选。🕔【活动时间】即日起—2023年11月23日📑【奖励说明】🌟 福利1：专家坐堂有奖即日起-11月23日，在指定论坛贴提问，评选优质问题送华为云定制颈枕。🌟 福利2：互动有礼官网直播间发口令“华为云 DTSE”抽华为云定制飞盘、填写问卷抽华为云定制保温杯等好礼。🌟 福利3：有奖提问直播过程中提问，评选优质问题送华为云定制长袖卫衣。🌟 更多福利：加入微信交流群直播期间扫码入群，解锁更多隐藏福利哦~

​63个云原生课程视频，基本上包含了整个云原生学习周期里这些都是你得花心思掌握的。内容比较细，基本上满足实操需求，涉及到容器技术、K8s、监控、运维、存储，以及比较前沿的 istio 等等……适用人群：高校学生、企业中的个人开发者以及互联网从业人员。>>>戳我查看云原生开发者学习路径 在线课程添加小助手微信k8s2222，进入云原生技术交流群 

沙箱隔离技术是一种将进程有效隔离到独立环境中运行的技术。随着容器技术的兴起，沙箱隔离技术也在云原生领域中得到了广泛的应用。iSulad率先通过 Sandbox API 支持 Kuasar，提供高效和稳定的沙箱管理能力。然而，由于容器技术的历史原因，沙箱的概念在容器引擎和容器运行时中没有得到足够的支持。OCI 标准[1]未定义沙箱管理，导致容器引擎和容器运行时只能采用容器管理的方式管理沙箱，引发性能和稳定性问题，具体可参见Kuasar 系列文章[2]。事实上，容器领域一直在深入研究和探索引入沙箱管理接口的问题。举例来说，Containerd 社区于 2022 年 4 月将 Sandbox API 相关功能整合到主线[3]，这一举措对 Containerd 内部沙箱管理逻辑进行了优化。然而，令人遗憾的是，它依然使用 OCI 标准接口来调用容器运行时以管理沙箱。2023 年 4 月 21 日，华为在 Kubecon+CloudNativeCon Europe 2023 云原生峰会上发布了多沙箱运行时 Kuasar[4]，将沙箱管理逻辑引入了容器运行时。至此，Kuasar 成为第一个支持 Sandbox API 的容器运行时。容器引擎使用 Sandbox API 直接管理沙箱成为了可能。iSulad[5]也率先通过 Sandbox API 支持 Kuasar，提供高效和稳定的沙箱管理能力。openEuler 23.09 完成对 iSulad+Kuasar+StratoVirt 的集成，为用户提供了一个极速轻量的安全容器解决方案，具体可参见第二篇 Kuasar 系列文章[6]。Sandbox API 简介service Controller { rpc Create(ControllerCreateRequest) returns (ControllerCreateResponse); rpc Start(ControllerStartRequest) returns (ControllerStartResponse); rpc Platform(ControllerPlatformRequest) returns (ControllerPlatformResponse); rpc Prepare(PrepareRequest) returns (PrepareResponse); rpc Purge(PurgeRequest) returns (PurgeResponse); rpc UpdateResources(UpdateResourcesRequest) returns (UpdateResourcesResponse); rpc Stop(ControllerStopRequest) returns (ControllerStopResponse); rpc Wait(ControllerWaitRequest) returns (ControllerWaitResponse); rpc Status(ControllerStatusRequest) returns (ControllerStatusResponse); rpc Shutdown(ControllerShutdownRequest) returns (ControllerShutdownResponse); }Sandbox API 的引入解决了容器引擎和容器运行时之间由来已久的痛点问题[2]：引入 Sandbox 语义，增强了云原生架构上的连贯性削减 shim 进程的冗余，减小资源开销，加快启动速度缩短调用链，可靠性倍增消除 Pause 容器冗余统一沙箱接口使容器运行时支持多沙箱生命周期与管理 Sandbox API[7] 定义了容器引擎如何与容器运行时交互，其中 Controller Service 定义了沙箱的生命周期管理接口，包括创建 (Create) 、启动 (Start) 、停止 (Stop) 、等待退出 (Wait) 、状态查询 (Status) 、销毁 (Shutdown) 、平台信息查询 (Platform) 等。通过 Sandbox API，容器引擎能够直接对沙箱进行管理，无需通过 OCI 标准接口间接管理沙箱，提高了容器引擎的性能和稳定性。资源管理 Sandbox API 还定义了沙箱的资源管理接口，包括资源准备 (Prepare) 、资源清理 (Purge) 、资源更新 (UpdateResources) 等。容器引擎可以通过这些接口管理容器资源，例如在创建容器前准备资源，运行过程中更新资源，容器退出后清理资源。iSulad 新架构图1. iSulad 架构对比图在 Kuasar 发布以后，iSulad 第一时间采用了新的架构以支持 Sandbox API ，使得它能够通过 Kuasar 来直接管理沙箱。为保持已有版本的兼容性与稳定性，iSulad 只对 CRI V1 版本进行了重构升级，支持用户使用 Sandbox API 管理沙箱。CRI V1alpha 版本继续沿用 OCI 标准来处理沙箱管理请求。沙箱与容器的解耦 在新的架构中，iSulad 引入了 Sandbox 的语义，新增核心模块 Sandbox ，使其成为容器引擎的一等公民，实现了容器管理与沙箱管理的解耦。从云原生整体架构的角度看，容器编排组件、容器引擎和容器运行时之间的沙箱管理变得更加流畅和高效，形成了一个完整的沙箱管理链路。以 iSulad+Kuasar+StratoVirt 极速轻量的安全容器解决方案为例，iSulad 在北向接收来自 Kubernetes 的 CRI 请求，并创建 Sandbox 对象来处理 PodSandbox 相关调用，同时使用 Executor 模块来处理 CRI 的 Container 请求。在南向，使用 Controller 模块通过 Sandbox API 调用 Kuasar 的 Sandboxer 进程来管理沙箱，同时使用 Runtime 中的 Shim V2 模块来调用 Kuasar 的 Task 进程，实现了对 StratoVirt 虚拟机中容器的管理。沙箱控制器 图2. 沙箱控制器类图Sandbox API 的实现使 iSulad 能够直接通过 Controller 来管理沙箱，因此 Kuasar 容器运行时也无需创建 Pause 容器以兼容 OCI 标准，避免了 Pause 容器的冗余。在新架构中，Controller 模块的设计充分考虑了对原有沙箱管理功能的兼容性，即支持用户通过Sandbox 和 Controller 模块创建普通容器(Pause 容器)作为沙箱。如上图所示，Controller 模块对 Sandbox 提供了统一 Controller 接口，以及两种不同的实现：Sandboxer Controller 和 Shim Controller 。Sandboxer Controller 是对 Sandbox API 的封装，将用户对沙箱的管理请求通过 gRPC 接口转发给 Kuasar 的 Sandboxer 进程，从而使 Sandboxer 执行底层的沙箱管理逻辑。Shim Controller 兼容原有的基于容器管理的接口，将对 Sandbox 的管理请求转发给 Executor 模块，以便创建和管理基于 Pause 容器的沙箱。Shim Controller 的实现使用户能够在新的架构下继续使用 OCI 标准接口来管理沙箱，以兼容原有已部署的业务，确保功能的连续性。Sandbox 和 Controller 的详细设计可以参见 iSulad 社区的设计文档[8]。简化容器调用链 图3. 容器启动流程图在支持了 Sandbox API 以后，iSulad 的容器管理流程也发生了一些变化。上图以 iSulad+Kuasar+StratoVirt 解决方案为例，展示了 iSulad 从启动沙箱到启动容器的简化流程。在图中，Kuasar Task 充当虚拟机中的 init 进程，同时也是虚拟机沙箱内容器的管理进程。它向 iSulad 提供容器管理接口 Task API ，当前解决方案中的 Task API 接口的实现与 Shim V2 类似但又不完全相同。根据 Shim V2 规范，容器引擎会调用一个 Shim V2 的二进制，创建 Shim 进程并返回 Shim 地址，用于管理沙箱、容器和资源。然而，通过调用 Sandbox API，iSulad 不再需要通过 Shim 进程来管理沙箱。相反，Sandbox API 的 Start 接口会在启动沙箱后返回一个 Task 地址，使 iSulad 能够与虚拟机中的 Kuasar Task 进程直接通信，以管理容器的生命周期。这种设计消除 Shim 进程以减少了管理面的内存开销并缩短调用链，从而提高了整个解决方案的性能和稳定性。总结 Sandbox API 是 iSulad、Kuasar 和 StratoVirt 这三个组件构成的极速轻量的安全容器解决方案的核心纽带。通过 Sandbox API，容器引擎能够直接对沙箱进行管理，无需通过 OCI 标准接口间接管理沙箱，从而显著提高了容器引擎的性能和稳定性。Sandbox API 的引入，也为容器引擎和容器运行时之间的沙箱管理提供了一个标准化的接口，为容器领域的发展提供了新的可能性。当前 Sandbox API 的实现已经合入了 iSulad 社区的主线，用户可以通过 openEuler 23.09 体验这一全栈自研的极速轻量安全容器解决方案，具体可参见 Kuasar 系列文章[6]。openEuler 社区一直秉承开放、协作、共赢的理念，欢迎更多的开发者参与到 iSulad、Kuasar 和 StratoVirt 的建设中来，共同推动容器领域的繁荣发展。参考[1] OCI Runtime Spec: cid:link_3[2] iSulad+Kuasar：管理面资源消耗锐减 99% 的新一代统一容器运行时解决方案 ：cid:link_5[3] Sandbox API : cid:link_4[4] 多沙箱容器运行时 Kuasar 技术揭晓！100% 启动速度提升，99% 内存开销优化 ：cid:link_6[5] iSulad: cid:link_9[6] openEuler 23.09 一键部署基于 Kuasar 的极速轻量安全容器：cid:link_7[7] sandbox.proto: cid:link_1[8] iSulad Sandbox 设计文档：cid:link_2本文转载自openEuler，原文链接Kuasar社区技术交流地址Kuasar官网：https://kuasar.io项目地址：cid:link_8Twitter: https://twitter.com/Kuasar_io添加社区小助手回复“Kuasar”进入技术交流群

Kurator 是由华为云推出的开源分布式云原生套件。面向分布式云原生场景，Kurator 旨在为用户提供一站式的解决方案，帮助用户快速构建自己的分布式云原生平台。在最新发布的 v0.5.0 版本中，Kurator 强化了其在多集群环境中的应用备份与恢复，以及存储管理的功能，以满足用户对于复杂部署的需求。本次更新主要包括以下两项新特性：统一集群备份恢复与迁移：Kurator 现在支持一键定制化的备份与恢复多个集群中的应用和资源，并通过统一视图实时监控各集群的进度；同时，还支持跨集群资源的一键迁移功能。统一分布式存储：Kurator 实现了一致性的分布式存储解决方案，其一站式部署让用户在多集群环境下轻松实现块存储、文件存储和对象存储的应用。 统一集群备份恢复与迁移在多云和分布式环境的持续演变中，数据的安全性与可恢复性已经成为用户高度关注的问题。对于企业来说，数据丢失往往是一个难以承受的打击，可能导致严重的业务中断和信誉损失。在以 Kubernetes 为行业标准的环境中，伴随着服务数量和集群规模的增长，数据管理的复杂度也随之增加，这使得实施高效而灵活的备份策略变得尤为重要。面对这种需求的不断扩大和挑战的增加，传统的备份工具往往在多环境下展现出局限性，难以提供一个无缝的统一解决方案。因此，Kurator 的统一备份方案应运而生，旨在提供这一领域的备份解决方案。基于 Velero (https://velero.io/) ，Kurator 为用户提供了一键式的操作体验，可以自定义备份并恢复横跨多个集群的应用与资源。通过 Kurator 提供的统一视图功能，用户能够实时监控各个集群备份的状态和进度。其覆盖范围涵盖了从 Pod、Deployment、Service 等 Kubernetes 原生资源，到 PersistentVolumes（PVs）等持久化存储的备份和恢复，以满足现代企业多元化的数据保护需求。统一备份Kurator 在备份解决方案上提供了多样化的选择，以适应不同场景下的数据保护需求。其灵活性确保了不同业务场景下都能找到合适的备份策略。即时备份: 面对数据频繁变动的情形，“即时备份”能够迅速地提供保护，确保关键数据在关键时间点的完整性得以保持。定期备份:对于那些不太频繁变动，但同样需要确保持久性的数据，“定期备份”可以根据预设的时间周期性的自动执行备份，以满足合规性要求和保障数据安全。此外，Kurator 还提供了一系列高度定制化的备份选项。例如，“特定集群备份”允许运维团队基于策略或特定需求有选择性地备份特定集群。“资源过滤”功能则提供了细粒度的控制，使管理员能够根据资源的名称、命名空间或标签等属性来精确定义备份的范围。这些备份策略的多样性和自动化能力为用户在不断变化的业务需求中，提供了稳定和可靠的数据保护。接下来是一个统一备份的实际操作示例：apiVersion: backup.kurator.dev/v1alpha1 kind: Backup metadata:   ...   name: select-labels   namespace: default spec:   destination:     fleet: quickstart   policy:     resourceFilter:       labelSelector:         matchLabels:           app: busybox     ttl: 720h status:   backupDetails:   - backupNameInCluster: kurator-member1-backup-default-select-labels     backupStatusInCluster:       completionTimestamp: "2023-10-28T03:37:13Z"       expiration: "2023-11-27T03:37:07Z"       formatVersion: 1.1.0       phase: Completed       progress:         itemsBackedUp: 1         totalItems: 1       startTimestamp: "2023-10-28T03:37:07Z"       version: 1     clusterKind: AttachedCluster     clusterName: kurator-member1   - backupNameInCluster: kurator-member2-backup-default-select-labels     backupStatusInCluster:       completionTimestamp: "2023-10-28T03:37:13Z"       expiration: "2023-11-27T03:37:07Z"       formatVersion: 1.1.0       phase: Completed       progress: {}       startTimestamp: "2023-10-28T03:37:07Z"       version: 1     clusterKind: AttachedCluster     clusterName: kurator-member2   ...观察 spec 配置，可以看到备份的目标是位于 Fleet 中各集群内所有标有 app:busybox 标签的资源。通过在 spec 中配置策略的方式，可以确保相关的资源得到备份。在 status 中，可以实时追踪到备份任务在每个集群，如 kurator-member1 和 kurator-member2，的执行状况，保持了操作的透明度。🔗 更多的示例和细节，请参考: cid:link_5统一恢复基于统一备份产生的备份数据，Kurator 通过统一恢复功能支持跨集群的应用和资源恢复。针对即时备份恢复:依据“即时备份”创建的备份数据，可以快速恢复至指定关键时刻的状态。针对定期备份恢复: 针对“定期备份”，Kurator 支持将备份数据恢复到最近一次成功执行备份的时间点。类似备份功能，Kurator 在恢复方面也提供了多样化和定制化的选项。例如，“特定集群恢复”使得用户能够只将数据恢复到指定集群，而不必覆盖所有备份中包含的集群。“资源过滤”功能则允许用户对备份数据进行进一步筛选，只选择性地恢复需要的数据项。用户可以根据备份名称、命名空间或标签等属性来定义恢复的范围，这不仅提升了恢复过程的灵活性，也确保了高度的精确性。参阅以下操作示例，了解如何使用 Kurator 进行统一恢复：apiVersion: backup.kurator.dev/v1alpha1 kind: Restore metadata:   ...   name: minimal   namespace: default spec:   backupName: select-labels status:   restoreDetails:   - clusterKind: AttachedCluster     clusterName: kurator-member1     restoreNameInCluster: kurator-member1-restore-default-minimal     restoreStatusInCluster:       completionTimestamp: "2023-10-28T09:24:07Z"       phase: Completed       progress:         itemsRestored: 2         totalItems: 2       startTimestamp: "2023-10-28T09:24:05Z"   - clusterKind: AttachedCluster     clusterName: kurator-member2     restoreNameInCluster: kurator-member2-restore-default-minimal     restoreStatusInCluster:       completionTimestamp: "2023-10-28T09:24:07Z"       phase: Completed       progress:         itemsRestored: 2         totalItems: 2       startTimestamp: "2023-10-28T09:24:05Z"   ...通过检查恢复任务的 spec 配置，我们可以确定本次恢复操作是针对前文提到的、标记为 select-labels 的备份数据。这里使用了最低配置，不进行恢复的筛选，直接根据备份的配置进行恢复。在 status 中，同样可以实时追踪到恢复任务在每个集群的执行状况。🔗 更多的示例和细节，请参考: cid:link_3统一迁移统一迁移旨在简化将应用程序及其资源从一个集群迁移到其他多个集群的过程。用户需要定义一种 migrate 类型的资源配置，并指定源集群、目标集群及相关策略。此外，类似于 Kurator 的统一备份和恢复功能，用户同样可以进行丰富的定制化配置。配置完成之后，Kurator 相应的控制器便会自动启动迁移任务。这一系列任务包括将资源从源集群上传到对象存储，以及最终迁移到指定的目标集群。具体的迁移过程可参考以下示意图：Kurator 统一迁移流程图相较于使用 Velero，Kurator 提供了一个更为集成和清晰的迁移流程描述。所有必要的配置细节都集中在单一的 migrate 对象中，从而减少了随着目标集群数量增加而产生的配置负担。同时，Kurator自动管理从创建备份到完成迁移的全过程，简化了操作流程，降低了手动操作错误的风险。此外，用户还可以通过这一个对象来实时监控多个集群中的迁移进度，随时了解迁移的最新状态，确保整个流程按预期执行。接下来是一个统一迁移的实际操作示例：apiVersion: backup.kurator.dev/v1alpha1 kind: Migrate metadata:   ...   name: select-labels   namespace: default spec:   policy:     resourceFilter:       labelSelector:         matchLabels:           app: busybox   sourceCluster:     clusters:     - kind: AttachedCluster       name: kurator-member1     fleet: quickstart   targetCluster:     clusters:     - kind: AttachedCluster       name: kurator-member2     fleet: quickstart status:   conditions:   - lastTransitionTime: "2023-10-28T15:55:23Z"     status: "True"     type: sourceReady   phase: Completed   sourceClusterStatus:     backupNameInCluster: kurator-member1-migrate-default-select-labels     backupStatusInCluster:       completionTimestamp: "2023-10-28T15:55:18Z"       expiration: "2023-11-27T15:55:13Z"       formatVersion: 1.1.0       phase: Completed       progress: {}       startTimestamp: "2023-10-28T15:55:13Z"       version: 1     clusterKind: AttachedCluster     clusterName: kurator-member1   targetClusterStatus:   - clusterKind: AttachedCluster     clusterName: kurator-member2     restoreNameInCluster: kurator-member2-migrate-default-select-labels     restoreStatusInCluster:       completionTimestamp: "2023-10-28T15:56:00Z"       phase: Completed       startTimestamp: "2023-10-28T15:55:58Z"   ...在 spec 配置中，源集群设置为 kurator-member1，目标集群为 kurator-member2，迁移过程仅针对包含标签 app:busybox 的资源。在 status 中，迁移阶段 Phase 显示为 Completed，表明迁移操作已完成。sourceClusterStatus 和 targetClusterStatus 分别提供源集群资源的备份细节和目标集群资源的恢复情况。🔗 更多的细节，请参考: cid:link_4统一分布式存储分布式存储作为现代云原生架构中不可或缺的一部分，提供了数据的可扩展性和可靠性。然而，在不同集群间实现一个一致的分布式存储解决方案，往往涉及到复杂的配置和管理工作。Kurator 致力于简化分布式存储的部署与管理。基于领先的开源项目 Rook（cid:link_9），Kurator 支持在多集群环境中轻松自动化管理分布式存储。这包括块存储、文件系统存储和对象存储等多种存储类型，以适应各种应用场景的需求。利用 Fleet 插件，Kurator 提供了一种一键跨集群部署分布式存储的解决方案，既简化了配置步骤也显著降低了配置错误的可能性。架构如下图所示：Kurator统一分布式存储架构图接下来是一个通过 Fleet 插件部署多集群分布式存储的例子：apiVersion: fleet.kurator.dev/v1alpha1 kind: Fleet metadata:   name: quickstart   namespace: default spec:   clusters:     - name: kurator-member1       kind: AttachedCluster     - name: kurator-member2       kind: AttachedCluster   plugin:     distributedStorage:       storage:         dataDirHostPath: /var/lib/rook         monitor:           count: 3           labels:             role: MonitorNodeLabel         manager:           count: 2           labels:             role: ManagerNodeLabel在 spec 中，clusters 指明了存储将部署在哪些集群上。在 status 中，plugin 配置下的 distributedStorage 标识此为一个分布式存储插件的安装。此外，dataDirHostPath 定义了存储的路径，而 monitor 和 manager 配置项则指定了 Ceph 组件的参数。🔗 更多的示例和细节，请参考: cid:link_1参考链接统一备份恢复迁移特性介绍: cid:link_6Fleet备份插件安装: cid:link_2统一备份操作指南: cid:link_5统一恢复操作指南: cid:link_3统一迁移操作指南: cid:link_4统一分布式存储操作指南: cid:link_1附：Kurator社区交流地址GitHub地址：cid:link_7Kurator主页：cid:link_8Slack地址: cid:link_0添加社区小助手k8s2222回复Kurator进入技术交流群

在云原生时代浪潮的推动下，Kubernetes的发展日新月异，更新的集群版本可以带来更新的功能，助力用户打造更强大的云原生应用环境。然而，一直以来，如何让用户积极地升级集群版本，是业界公认的一个难题。“我们想用K8s推出的新能力，也想保持整体集群的最新状态。但是我们那么多重要的应用跑在容器上，如何确保我的业务在集群升级过程不受任何影响呢？一旦出现问题，能快速修复吗？”，“我的集群版本比较老，想要升级到最新版本，升级过程可能会很长，担心可能对上层业务会有影响，且影响时长不可控”——这是CCE集群升级团队与用户交流过程中最常听到的几个问题。为此，CCE集群升级团队深入分析并总结了集群升级的痛点问题，主要有以下三个方面：在业务影响方面，传统升级中的替换升级或迁移升级均会导致业务Pod重建，从而影响到业务。在升级稳定性和效率方面，Kubernetes集群系统复杂，影响升级稳定性因素众多；集群版本跨度较大时需要执行多次升级操作，升级时间较久，尤其在大规模集群升级场景，用户感知更为明显。在交互体验方面，用户对升级流程缺乏全局掌控，尤其是升级流程中步骤较多，用户理解成本高。图1 集群升级痛点如何无损、快速、丝滑地升级集群是业界共同的难题。基于上述几个痛点，CCE产品团队从“过程业务无感”、“稳定高效升级”、“丝滑交互体验”等方面入手，打造焕然一新的集群升级体验。过程业务无感传统升级方式主要有节点替换升级和集群迁移升级，两种方式均会导致业务Pod重建，进而影响用户业务。华为云率先推出原地升级能力，只需更新CCE组件版本，节点无需任何变动，对集群中运行的Pod业务无任何影响，从而实现无损升级。同时，原地升级在速度上相比传统升级有大幅提升。图2 传统升级和原地升级对比同时，用户无需关注集群与插件版本的依赖关系，一键式升级将为您自动进行升级适配，省心省力。 此外，如果在升级过程中出现不可预期的情况，可以基于备份为用户实现快速恢复，使用户更容易掌控集群升级。稳定高效升级在升级稳定性提升方面，我们基于华为云上万次的升级经验沉淀，为用户提供了全方位的升级前检查项，检查项涵盖集群、节点、插件和应用、关键组件状态和配置、资源使用等方面，极大程度上为用户规避升级风险，实现稳定升级。同时，备份是业务连续性的重要保证，业界通用的Etcd备份方案存在无法备份集群组件和配置的问题，我们通过采用硬盘快照备份方案不仅为用户提供了完整的集群数据备份能力，且平均备份速度提升近10倍。在升级效率方面，一方面由于Kubernetes社区只兼容相邻小版本，当版本跨度较大时，需要通过多次升级至最新版。我们为用户提供跨版本升级能力，最多支持跨4个大版本进行升级，如v1.23升级至v1.27，有效缩短用户升级路径，节约升级成本；另一方面，升级时间随着在集群规模正增长，我们在保证集群升级安全的前提下，最多支持100节点并发升级，让用户在更短的时间内完成集群节点升级，提高升级效率。图3 简化集群升级路径图4 集群节点并发升级丝滑交互体验在升级引导方面，我们通过引导页面，给用户清晰直观呈现待升级集群的提示消息，让用户不会错过重要的升级通知。图5 集群管理页面集群升级通知为了降低用户理解成本，我们设计了升级小动画为用户阐述原地升级的概念和原理，帮助用户生动直观地了解集群升级流程和注意事项。图6 集群升级动画同时，我们推出了升级路径推荐功能，自动选择最佳的升级路径，并根据升级路径展示本次升级带来的特性更新和优化增强等。图7 升级路径在升级流程中，我们通过可视化的手段为用户详细呈现了升级的进度和异常情况，升级过程一目了然，使用户能掌控升级进度，降低焦虑。图8 升级进度可视化在升级检查异常时，我们基于不同资源汇聚了检查项信息，帮助用户快速查看异常项并提供修复建议，引导用户快速处理问题。图9 升级异常诊断分析在升级完成后，我们会帮助用户进行升级后自动验证，确保升级后的集群正常运行，节省用户时间和精力。图10 自动健康诊断未来愿景欢迎您使用CCE集群升级功能，我们会持续在“过程业务无感”、“稳定高效升级”、“丝滑交互体验”等方面进行持续优化，让集群升级过程更简单、高效和可靠。期待您宝贵的使用意见。服务体验请访问cid:link_4相关链接cid:link_3cid:link_5云容器引擎 CCE

在边缘计算的浪潮中，AI是边缘云乃至分布式云中最重要的应用。随着边缘设备的广泛使用和性能提升，将人工智能相关的部分任务部署到边缘设备已经成为必然趋势。KubeEdge-Ianvs 子项目，作为业界首个分布式协同AI基准测试平台，基于 KubeEdge-Sedna 为算法及服务开发者提供全场景可扩展的分布式协同AI基准测试，以研发、衡量和优化分布式协同AI系统。然而在边缘设备中部署静态的AI模型往往不足以应对复杂多变的真实世界环境，因此终身学习能力对于边缘AI模型来说变得越来越重要。为了方便边缘AI算法研究者开发及测试终身学习算法在真实世界环境中的效果，KubeEdge-Ianvs 在新版本的更新中发布了支持终身学习范式的相关算法的研发与测试功能。本篇文章为大家阐释相关背景和Ianvs终身学习架构，并以 Ianvs 云机器人终身学习测试为例对 Ianvs 终身学习的特性进行介绍。欢迎关注 Ianvs 项目，持续获得第一手独家公开数据集与完善基准测试配套。开源项目GitHub地址：cid:link_4  一、背景  ▍1.1 终身学习能力对边缘模型越来越重要边缘设备所处的环境通常是不稳定的，环境变化会导致数据分布的大幅变化，即数据漂移。数据漂移会显著降低模型准确性。为了解决数据漂移问题，边缘设备需要具备动态更新模型的能力，以适应环境变化。下图展示了一个典型的终身学习算法流程框架。在该框架中，终身学习任务被定义为：已处理 N 个任务，将陆续处理 M 个任务。如何维护知识库并利用其中的模型处理这些任务是关键。终身学习的流程分为四步，首先根据之前已处理的 N 个任务初始化云端的知识库中的已知任务处理模型；然后在遇到新的任务时，从云端知识库中选取合适的模型部署到边缘端处理任务，如果新任务是已知的任务则更新原来的模型，如果遇到了未知任务则重新训练新的模型用于处理该任务；在边缘端处理好该任务后，对云端知识库进行更新；最后遇到新任务时重复前两步操作。通过以上流程可以确保边缘部署的模型具备终身学习的能力，从而可以应对数据漂移等问题带来的影响。▍1.2 业界缺少合适的终身学习测试工具目前终身学习算法相关测试工具发展较慢，目前比较成熟的测试工具只有 ContinualAI 推出的 Avalanche。Avalanche 支持的特性如下：Avalanche 支持的特性非常丰富，但是对于终身学习算法开发者来说 Avalanche 还存在一些局限性：未能覆盖终身学习全生命周期算法：支持的场景主要局限于增量学习等场景，而终身学习中任务定义、分配以及未知任务识别等流程无法体现在该 benchmark中。缺乏配套真实世界数据集：配套的数据集主要包括 Split-MNIST、Cifar10 等学术界常用的玩具测试集，缺乏适用的真实世界数据集及配套算法。研发算法难以落地：Avalanche更多面向终身学习算法的测试实验，并没有考虑未来将算法落地部署的需求。因此目前业界亟需一个更好的终身学习测试 benchmarking 工具，Ianvs 发布的非结构化终身学习新特性可以很好的解决上述问题。  二、lanvs 终身学习架构  ▍2.1 Ianvs 终身学习优势终身学习近年来得到了越来越多的关注，越来越多的边缘智能从业者认识到了终身学习的重要性。但是终身学习相比其他 AI 算法来说有着更高的研究门槛，经过我们的调研发现终身学习研发存在模型训练流程复杂、算法效果难以衡量和算法落地应用困难三大挑战。第一个挑战是终身学习模型训练流程较为复杂，比如对于一个刚入门终身学习的同学来说，可能对终身学习算法流程中的未知任务识别模块比较感兴趣，但是要想完整实现终身学习还需要填补任务定义、任务分配等模块，而这对于刚入门的同学不太友好，想复现别人的工作还需要去额外完成其他终身学习模块。针对这一挑战，KubeEdge-Ianvs 中对终身学习全生命周期的各个模块都进行了设计，包括并不限于任务定义、任务分配、未知任务识别和未知任务处理等多个终身学习核心算法模块，各个模块之间是解耦合的，用户可以只研究自己感兴趣的模块，其他模块采用默认配置即可跑通终身学习实验。第二个挑战是终身学习算法效果衡量困难，不同论文中的终身学习算法由于其测试流程不一样难以比较其工作的优劣。同时大部分论文的工作都是在 MNIST、CIFAR10 这些非真实数据集上进行的实验，由于缺乏在真实世界数据集上的测试，算法在现实世界中的实际应用效果往往要大打折扣。针对这一挑战，KubeEdge-Ianvs 中对终身学习的测试流程进行了统一，提供 BWT、FWT 等公认的终身学习系统指标，方便衡量算法效果。同时 KubeEdge-Ianvs 开源了 Cloud-Robotics 等真实世界终身学习数据集，并配套了对应的运行样例，用户可以直接开箱使用该真实世界数据集测试自己提出的算法的效果。第三个挑战是终身学习算法落地较为困难，算法研发与实际部署之间存在一定鸿沟。用户训练好的模型需要进一步封装才能实际在生产环境上使用。针对这一挑战，KubeEdge-Ianvs 在开发时就考虑到了和其姊妹项目 KubeEdge-Sedna 开源服务平台是配套兼容关系，因此在 KubeEdge-Ianvs上研发的终身学习算法可以直接迁移到 KubeEdge-Sedna平台上实现落地部署，解决了从研发到落地最后一公里的问题。总而言之，Ianvs 终身学习优势包括：覆盖终身学习全生命周期，包括任务定义、任务分配、未知任务识别和未知任务处理等多个模块，各个模块是解耦合的；统一化的测试流程，系统内置权威的终身学习测试指标，并且支持测试结果的可视化；并提供真实世界数据集用于终身学习测试，能更好测试终身学习算法在真实环境的效果；和 KubeEdge-Sedna 终身学习相兼容，研发算法可以快捷迁移到 Sedna 上实现落地部署。▍ 2.2 Ianvs 终身学习新特性Ianvs 在去年发布的 0.1.0 版本中已具备支持单任务学习范式和增量学习范式的算法研发与测试，在新版的 Ianvs 中增加了支持对终身学习范式的相关算法的研发与测试的功能，同时也为终身学习算法测试提供了新的开源数据集。主要新特性如下：特性一：覆盖终身学习全生命周期Ianvs 终身学习具体架构如下图所示，主要包括任务定义、任务分配、未知任务识别和未知任务处理等模块，覆盖终身学习全生命周期。对于已处理任务，Ianvs 通过任务定义模块，将已知任务抽象成若干个模型存储进云端知识库中。在遇到新任务时，Ianvs 首先通过未知任务识别模块判断推理样本属于未知任务还是已知任务。若是已知任务，则从云端知识库中调度对应模型部署在边侧处理该任务，同时基于已知任务样本对模型进行增量更新。若是未知任务，则 Ianvs 通过未知任务处理模块处理该任务，利用外部系统标注并重新训练新的模型用于处理该任务。处理完成后，新的任务模型或是更新后的已知任务模型再重新整合至云端知识库中。为了方便初学者使用 Ianvs，在 Ianvs 仓库中的 examples/robot/ 文件夹下提供了一个可以直接运行的样例cid:link_1 ， 详细的教程在第三节。特性二：统一化的测试流程和真实世界数据集Ianvs 对终身学习测试流程进行了统一，主要参考了 NIPS2017 的论文 “Gradient Episodic Memory for Continual Learning”，复现了其中提出的 BWT 和 FWT 指标，用于评价终身学习算法的抗遗忘能力和未知任务泛化能力。Ianvs 还开源了 Cloud-Robotics 等真实世界数据集，并提供了配套的可以开箱即用的实验代码，帮助用户快速上手 Ianvs 终身学习。数据集官网链接：cid:link_5特性三：支持快捷落地部署如下图所示，Ianvs 中终身学习算法实现的组件与 Sedna 上终身学习算法实现的组件是相兼容的，因此在 Ianvs 上研发测试的算法可以无障碍迁移部署到 Sedna 上，方便相关从业人员实地部署算法。  三、lanvs 终身学习快速教程  在这章中我们通过运行 Ianvs 终身学习的 cloud-robotics 样例向大家讲解 Ianvs 终身学习的基本流程。Ianvs 安装流程以及终身学习更详细的介绍可以参考：Ianvs-lifelong-learning-tutorial相关链接：cid:link_31）首先我们需要配置好 Cloud-Robotics 的数据集，先创建数据集的文件夹，注意如果你把数据集放到别的位置，本教程中的部分路径配置也要一并修改。mkdir /datacd /datamkdir datasetscd datasetsCloud-Robotics 数据集可以根据该数据集专属网站的指示操作获得，链接：cid:link_22）下载完成后解压数据集：unzip cloud-robotics.zip3)配置好数据集后，我们可以准备运行示例代码了。Cloud-Robotics 示例运行的代码放在 /ianvs/project/ianvs/examples/robot/lifelong_learning_bench/ 下，我们首先要配置 python 路径（这里如果 Ianvs 安装位置不一样的话需要更改路径）：export PYTHONPATH=$PYTHONPATH:/ianvs/project/ianvs/examples/robot/lifelong_learning_bench/testalgorithms/rfnet/RFNet4）然后我们检查一下 yaml 文件的信息：5）上图 benchmarkjob.yaml 中 workplace 是存放模型训练输出的路径，可以改成你需要的路径。6）上图 testenv-robot.yaml 中 train_url 和 test_url 是数据集索引的路径，如果你的数据集存放位置和教程不一样，则需要修改 train_url 和 test_url 的路径。7）在上图 rfnet_algorithm.yaml 中可以根据你的需求添加测试的终身学习算法，比如任务定义、任务分配等算法。本样例中提供了一个简单的示例。8）其他的配置文件暂时没有需要调整的。接下来我们就可以运行示例代码了：cd /ianvs/project/ianvs ianvs -f examples/robot/lifelong_learning_bench/benchmarkingjob.yaml 在模型终身学习任务结束后你可以看到以下内容，包括 BWT、FWT 等终身学习系统衡量指标：9）出现以上显示结果，则成功跑通了一个 Ianvs 终身学习样例！如果读者对于本次版本发布的更多细节感兴趣，欢迎查阅 Ianvs v0.2 Release Note：cid:link_0后续 KubeEdge SIG AI 将发布系列文章，陆续具体介绍终身学习全面升级的特性，欢迎各位读者继续关注社区动态。▍相关链接[1] 开源项目GitHub地址：cid:link_4[2] 数据集官网链接：cid:link_5[3] Ianvs 安装流程以及终身学习更详细的介绍链接：cid:link_3[4] Cloud-Robotics 数据集：cid:link_2[5] Ianvs v0.2 Release Note：cid:link_0

云原生产品技术栈庞大，需要用户对容器、Kubernetes等核心技术都有扎实的理解和掌握；同时问题定位和排查也较为困难，需要用户对不同系统模块原理非常熟悉。这些因素导致云原生产品上手门槛高、配置和运维复杂。为此，华为云云容器引擎CCE产品团队在CCE文档方面进行了重点优化，以降低用户的使用难度：优化文档结构，以便用户更系统地获取所需信息。新增大量实操内容，提供了配置参考，丰富了最佳实践。对已有文档内容进行重构与升级，更新了关键操作指导，确保内容更加易用。新增高质量问答对，实现智能化问答。通过文档服务的全面提升，用户可以更轻松地上手和使用云原生产品，大幅降低难度。结构优化：知识体系完善,学习路径清晰为了帮助用户更直观地获取所需信息，在内容结构上，我们针对用户学习和检索行为对文档目录进行了优化，使用户能够更加清晰了解CCE的学习使用路径。用户可以轻松地跟随这条路径，从入门级别的基础操作指导开始，逐步深入到更高级的管理和运维实践。这种渐进式学习路径帮助用户建立坚实的基础，从而更好地理解和掌握云原生技术。图1 文档目录优化其次，我们加强了文档之间的关联性。每篇文档都与其他相关文档形成了链接，帮助用户在需要的时候能够轻松地跳转到相关主题。 确保用户可以更全面地了解整个云原生技术生态系统。图2 文档关联性增强内容上新：实操案例丰富,满足用户需求CCE文档的内容优化是为了让用户能够在使用CCE时轻松获取所需信息，配置系统并应对各种关键场景。首先，我们引入了一份详尽的CCE配置参考手册，其中列出了各类参数的详细说明，包括集群、节点等各项配置。用户可以在配置手册中找到所需的参数信息，从而更好地理解和掌握系统配置。图3 配置手册此外，我们还新增多篇CCE最佳实践，覆盖了一系列关键场景，如基于容器的CI/CD、应用上云、日志监控等，旨在帮助用户在实际应用中成功地配置和管理云原生环境。用户可以依照这些最佳实践，快速了解如何部署容器应用、将服务迁移到云端以及如何设置有效的日志监控系统。这些实际场景的指导有助于用户将理论知识转化为实际操作，提高技能水平，同时减少配置和部署的复杂性。图4 最佳实践内容重构升级：核心知识更可靠,操作更明确对文档内容进行了重构与升级，更新了关键操作指导，确保内容更加易用。例如我们对容器存储相关文档进行了全面的重构，容器存储是云原生环境中不可或缺的一部分，因为它涉及到应用程序数据的持久性和可靠性。我们重新审视并更新了存储文档，确保其内容涵盖了各种存储解决方案和最佳实践，并将内容从以K8s对象角度更新为存储类型角度组织，使得用户能够更加直观的从使用存储的角度查找并使用文档。图5 存储内容重构升级智能问答增强：用户体验更友好,问题快速解答在CCE文档的智能问答部分，我们新增了超过800条高质量问答对，旨在全面覆盖CCE的常见问题和疑虑。这意味着用户现在可以像与客服交互一样，通过智能问答系统获得即时反馈，无需漫长的搜索或等待。这项改进的好处不仅仅在于提供更快速的解答，还在于增强了文档的互动性和友好度。用户不再需要翻阅大量文档或手动搜索答案，而是可以直接向智能问答系统提问。这种自然语言查询的方式使文档更加与用户互动，打破了传统文档的单向性质。用户可以随时提出问题，获得立即的、个性化的答案，从而提高了文档的实用性和用户体验。图6 智能问答未来愿景华为云CCE致力于为用户提供配置更简单、管理更便捷、流程更透明的容器服务。未来我们将持续打磨CCE的文档使用体验，力争为用户带来更多价值。如果您有任何的建议或意见，可以通过页面下方的反馈意见告知我们，您的任何意见对我们来说都很重要。服务体验请访问https://www.huaweicloud.com/product/cce.html云容器引擎 CCE

在云原生容器化浪潮的当下，监控是确保业务稳定性最受关注的问题之一。那么，华为云CCE容器服务又是如何帮助用户提高运维效率呢？半年来，CCE容器服务的运维团队持续拜访用户，并总结用户在云原生运维场景下的痛点问题，主要有以下三大痛点问题：搭建云原生集群监控系统涉及的配置项多，包括集群自身的组件、资源的监控、业务组件的监控等，技术门槛较高。云原生场景下的监控指标涵盖五大类，近数十万项，同时不同类型指标之间相互关联，传统监控难以将这些信息可视化。Promtheus已成为业界云原生监控的事实标准。但开源方案在商用场景下仍存在一些非功能性问题，尤其是海量监控指标带来的高资源消耗，导致成本显著增加。图1 云原生运维的痛点问题基于上述几个痛点，CCE联合AOM服务团队从开箱即用：一键启用容器监控能力、全景观测：多维度全场景监控视图、开源增强：兼容开源Promtheus，全方位能力提升等维度共同打造新一代云原生监控平台，为用户提供更加方便快捷的运维手段。开箱即用：一键启用容器监控能力为了方便用户快速触达监控中心，我们对开启监控中心的步骤进行了极致的简化，并将AOM服务上的监控信息整合到CCE的监控中心。现在，只需前往监控中心一键开启，即可在集群监控中心中查看容器基础资源、Kubernetes资源对象和Kubernetes服务组件的监控指标。图2 创建集群时开通监控中心图3 监控中心一键开通全景观测：多维度全场景监控视图CCE监控中心提供集群内涵盖基础资源、K8s资源对象、K8s服务组件、K8s集群Node、云原生上层业务等五大类，总计近数十万项指标的全景可观测能力，致力打造一站式运维的极致体验。集群健康总览：监控中心首页会呈现整个集群中关键的控制面组件信息、资源占用最高的组件等，能让您对集群的健康情况一目了然。图4 集群健康总览资源健康总览：监控中心提供了节点、工作负载、POD等Kubernetes资源的独立监控页面。资源监控页面中提供资源的基本监控信息，并且能够纵览对应的资源概况，快速发现异常对象。图5 资源健康总览关联资源一屏可见：在监控中心中，在资源监控详情页中能看到关联资源的监控详情，并且可以方便的进行跳转查看（如在看节点监控时可以下钻至节点上的Pod，查看Pod的监控）。图6 资源监控详情页监控大盘：监控中心中提供了丰富的监控大盘，从集群、Node、控制组件等不同的视角呈现集群的健康状态。图7 监控中心仪表盘开源增强：兼容开源Promtheus，全方位能力提升Prometheus是CNCF社区推荐的云原生监控方案，也是业界云原生监控的事实标准，它的服务发现、时序数据等能力能够很好地解决云原生场景下多变、海量数据的问题。同时，Prometheus也是用户使用最多的监控工具。为了更好地符合用户的使用习惯，降低学习成本，CCE提供基于Prometheus开源生态能力的监控组件，兼容Prometheus的开源配置，同时在开源能力基础上对安全、性能、安装部署等方面做了商用增强。在安全上，使用防护能力更强的华为自研的加密算法，对Prometheus使用的敏感信息进行加密；在性能上，一方面对监控指标进行分层管理，满足不同类型用户的监控诉求，另一方面，降低本地存储数据的时效，有效地降低了用户的资源消耗；在安装部署上，需要用户配置的参数由30+优化至0配置一键安装。除此之外，针对Prometheus在海量数据下资源消耗巨大的问题，我们还提供了托管Prometheus+轻量化采集Agent的解决方案，用户侧仅需要负担轻量化采集Agent的资源即可支持海量指标监控，同时大大降低了用户的运维复杂度。我们非常期待本期带来的监控中心能力能够有效地提升您的运维体验，同时我们也会对监控中心进行持续的优化。期待您的使用以及宝贵的改进意见。后续我们还会有其他运维特性的介绍，如告警中心，健康诊断、日志中心等，敬请期待。服务体验请访问cid:link_4相关链接cid:link_3cid:link_5云容器引擎 CCE

云原生已经成为企业应用现代化数字转型的潮流。云原生架构让企业的应用具备了更快的迭代速度、更低的开发复杂度和更好的可扩展性，但是应用应用部署位置不可控 、数量等不断变化的场景让运维复杂度和运维人员的工作量大大增加。相较于传统运维，云原生架构下的运维更加关注监控、日志、事件、告警等数据的自动化采集、可视化呈现和智能化决策。为了提升云原生场景下的运维体验，华为云CCE容器服务带来了新一代的云原生可观测平台，聚焦以下四大能力：监控中心为了解决云原生用户使用监控系统困难的问题，CCE针对多服务组合的复杂场景进行优化，支持一键启用监控中心能力，并提供从容器视角的一站式可视化监控新体验，支持集群、节点、工作负载、Pod等多种维度的监控视图。图1 监控中心告警中心为了解决Prometheus告警语句复杂、不同类别告警源存在多配置入口、基础告警项多导致配置效率低等问题，CCE集群中增加告警中心能力，提供容器告警基于模板的一键配置能力。默认告警规则可有效覆盖集群和容器常见故障场景。图2 告警中心日志中心传统的日志管理系统在云原生场景下存在使用体验割裂、采集配置复杂、日志检索及查看不契合云原生概念模型等问题，为解决上述问题，CCE服务深度集成LTS日志服务能力，推出云原生日志中心，简化了日志采集配置，并提供基于云原生视角的日志管理视图。图3 日志中心健康中心云原生场景下丰富的监控指标、事件、日志能够让用户更加方便定位问题，但是同样也无形中提高了运维人员的技术门槛。为了能够让更多的运维人员能够快速的定位问题，CCE服务提供了健康中心能力，基于华为云容器运维专家经验对集群健康状况进行全面检查，发现集群故障与潜在风险并给出修复建议。图4 健康中心以上就是新一代CCE云原生可观测平台所带来的四大能力。下一篇我们将深入探讨客户在云原生监控上面临的挑战，并着重介绍CCE监控中心如何应对此类挑战，敬请期待。服务体验请访问cid:link_1相关链接cid:link_0cid:link_2云容器引擎CCE

北京时间2023年10月13日，KubeEdge 发布 v1.15.0 版本。新版本新增多个增强功能，在边缘节点管理、边缘应用管理、边缘设备管理等方面均有大幅提升。KubeEdge v1.15.0 新增特性：支持 Windows 边缘节点基于物模型的新版本设备管理 API v1beta1发布承载 DMI 数据面的 Mapper 自定义开发框架 Mapper-Framework 发布支持边缘节点运行静态 Pod支持更多的 Kubernetes 原生插件运行在边缘节点 新特性概览 ▍支持 Windows 边缘节点随着边缘计算应用场景的不断拓展，涉及到的设备类型也越来越多，其中包括很多基于Windows 操作系统的传感器、摄像头和工控设备等，因此新版本的KubeEdge 支持在 Windows 上运行边缘节点，覆盖更多的使用场景。在 v1.15.0 版本中，KubeEdge 支持边缘节点运行在 Windows Server 2019，并且支持 Windows 容器运行在边缘节点上，将 KubeEdge 的使用场景成功拓展到 Windows 生态。Windows 版本的 EdgeCore 配置新增了 windowsPriorityClass 字段，默认为NORMAL_PRIORITY_CLASS。用户可以在 Windows 边缘主机上下载 Windows 版本的 EdgeCore 安装包[1]，解压后执行如下命令即可完成 Windows 边缘节点的注册与接入，用户可以通过在云端执行 kubectl get nodes 确认边缘节点的状态，并管理边缘 Windows 应用。edgecore.exe --defaultconfig > edgecore.yaml edgecore.exe --config edgecore.yaml更多信息可参考：cid:link_3cid:link_4▍基于物模型的新版本设备管理 API v1beta1 发布v1.15.0 版本中，基于物模型的设备管理 API，包括 Device Model 与 Device Instance，从 v1alpha2 升级到了 v1beta1，新增了边缘设备数据处理相关等的配置，北向设备 API 结合南向的 DMI 接口，实现设备数据处理，API 的主要更新包括：Device Model 中按物模型标准新增了设备属性描述、设备属性类型、设备属性取值范围、设备属性单位等字段。// ModelProperty describes an individual device property / attribute like temperature / humidity etc. type ModelProperty struct { // Required: The device property name. Name string `json:"name,omitempty"` // The device property description. // +optional Description string `json:"description,omitempty"` // Required: Type of device property, ENUM: INT,FLOAT,DOUBLE,STRING,BOOLEAN,BYTES Type PropertyType `json:"type,omitempty"` // Required: Access mode of property, ReadWrite or ReadOnly. AccessMode PropertyAccessMode `json:"accessMode,omitempty"` // +optional Minimum string `json:"minimum,omitempty"` // +optional Maximum string `json:"maximum,omitempty"` // The unit of the property // +optional Unit string `json:"unit,omitempty"` }Device Instance 中内置的协议配置全部移除，包括 Modbus、Opc-UA、Bluetooth 等。用户可以通过可扩展的 Protocol 配置来设置自己的协议，以实现任何协议的设备接入。Modbus、Opc-UA、Bluetooth 等内置协议的 Mapper 不会从 mappers-go 仓库移除，并且会更新到对应的最新版本，且一直维护。type ProtocolConfig struct { // Unique protocol name // Required. ProtocolName string `json:"protocolName,omitempty"` // Any config data // +optional // +kubebuilder:validation:XPreserveUnknownFields ConfigData *CustomizedValue `json:"configData,omitempty"` } type CustomizedValue struct { Data map[string]interface{} `json:"-"` } 在 Device Instance 的设备属性中增加了数据处理的相关配置，包括设备上报频率、收集数据频率、属性是否上报云端、推送到边缘数据库等字段，数据的处理将在 Mapper 中进行。type DeviceProperty struct { ...... // Define how frequent mapper will report the value. // +optional ReportCycle int64 `json:"reportCycle,omitempty"` // Define how frequent mapper will collect from device. // +optional CollectCycle int64 `json:"collectCycle,omitempty"` // whether be reported to the cloud ReportToCloud bool `json:"reportToCloud,omitempty"` // PushMethod represents the protocol used to push data, // please ensure that the mapper can access the destination address. // +optional PushMethod *PushMethod `json:"pushMethod,omitempty"` }更多信息可参考：cid:link_5cid:link_6▍承载 DMI 数据面的 Mapper 自定义开发框架 Mapper-Framework 发布v1.15.0 版本中，对 DMI 数据面部分提供了支持，主要承载在南向的 Mapper 开发框架 Mapper-Framework中。Mapper-Framework 提供了全新的 Mapper 自动生成框架，框架中集成了 DMI 设备数据管理（数据面）能力，允许设备在边缘端或云端处理数据，提升了设备数据管理的灵活性。Mapper-Framework 能够自动生成用户的 Mapper 工程，简化用户设计实现 Mapper 的复杂度，提升 Mapper 的开发效率。DMI 设备数据面管理能力支持v1.15.0 版本 DMI 提供了数据面能力的支持，增强边缘端处理设备数据的能力。设备数据在边缘端可以按配置直接被推送至用户数据库或者用户应用，也可以通过云边通道上报至云端，用户也可以通过 API 主动拉取设备数据。设备数据管理方式更加多样化，解决了 Mapper 频繁向云端上报设备数据，易造成云边通信阻塞的问题，能够减轻云边通信的数据量，降低云边通信阻塞的风险。DMI 数据面系统架构如下图所示：Mapper 自动生成框架 Mapper-Frameworkv1.15.0 版本提出全新的 Mapper 自动生成框架 Mapper-Framework。框架中已经集成 Mapper 向云端注册、云端向 Mapper 下发 Device Model 与 Device Instance 配置信息、设备数据传输上报等功能，大大简化用户设计实现 Mapper 的开发工作，便于用户体验 KubeEdge 边缘计算平台带来的云原生设备管理体验。更多信息可参考：cid:link_7▍支持边缘节点运行 Kubernetes 静态 Pod新版本的 KubeEdge 支持了 Kubernetes 原生静态 Pod 能力，与 Kubernetes 中操作方式一致，用户可以在边缘主机的指定目录中，以 JSON 或者 YAML 的形式写入 Pod 的 Manifests 文件，Edged 会监控这个目录下的文件来创建/删除边缘静态 Pod，并在集群中创建镜像 Pod。静态 Pod 默认目录是 /etc/kubeedge/manifests，您也可以通过修改 EdgeCore 配置的 staticPodPath 字段来指定目录。更多信息可参考：cid:link_8▍支持更多的 Kubernetes 原生插件运行在边缘节点v1.15.0 版本的 KubeEdge 支持更多原生插件在边缘节点上运行。KubeEdge 提供了高扩展性的 Kubernetes 原生非资源类 API 透传框架，满足了原生插件对此类 API 的依赖。插件可以从边缘节点的 MetaServer 中获取集群 version 等信息，MetaServer 将对请求进行数据缓存，保证边缘节点网络中断时仍能正常服务。当前框架下，社区开发者将更容易的开放更多非资源类 API。开发者只需关注插件依赖的 API，而不需要考虑请求如何传递至边缘节点。更多信息可参考：cid:link_9▍升级 Kubernetes 依赖到 v1.26新版本将依赖的 Kubernetes 版本升级到 v1.26.7，您可以在云和边缘使用新版本的特性。更多信息可参考：cid:link_10 升级注意事项 新版本 v1beta1 的 Device API不兼容 v1alpha1 版本，如果您需要在 KubeEdge v1.15.0 中使用设备管理特性，您需要更新 Device API 的 yaml 配置。如果您使用 containerd 作为边缘容器运行时，您需要将 containerd 版本升级到 v1.6.0 或者更高版本，KubeEdge v1.15.0 不再支持 containerd 1.5 以及更早的版本。参考：https://kubernetes.io/blog/2022/11/18/upcoming-changes-in-kubernetes-1-26/#cri-api-removal在 KubeEdge v1.14 中，EdgeCore 已经移除了对 dockershim 的支持，边缘运行时仅支持 remote 类型，并且使用 containerd 作为默认运行时。如果您想要继续使用 docker 作为边缘运行时，您需要安装 cri-dockerd，并且在启动 EdgeCore 过程中，设置 runtimeType=remote 以及 remote-runtime-endpoint=unix:///var/run/cri-dockerd.sock。参考：cid:link_2▍致谢感谢 KubeEdge 社区技术指导委员会( TSC )、各 SIG 成员对 v1.15.0 版本开发的支持与贡献，未来 KubeEdge 将持续在新场景探索与支持、稳定性、安全性、可扩展性等方面持续发展与演进！▍相关链接[1] Windows 版本 EdgeCore 安装包:cid:link_0[2] Release Notes：cid:link_11/blob/master/CHANGELOG/CHANGELOG-1.15.md  加入KubeEdge社区 KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会内部唯一孵化级边缘计算开源项目,社区已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式，并在持续开拓创新中。KubeEdge网站 : https://kubeedge.ioGitHub地址 : cid:link_11Slack地址 : https://kubeedge.slack.com邮件列表 : https://groups.google.com/forum/#!forum/kubeedge每周社区例会 : https://zoom.us/j/4167237304Twitter : https://twitter.com/KubeEdge文档地址 : https://docs.kubeedge.io/en/latest/扫码回复“KubeEdge”进入技术交流群