• [技术干货] 华为云 Kurator v0.3.0 版本发布!集群舰队助力分布式云统一管理
    2023年4月8日,Kurator正式发布v0.3.0版本。Kurator 是华为云推出的分布式云原生开源套件,通过集成业界主流开源技术栈,帮助用户一站式构建专属的分布式云原生基础设施,助力企业业务跨云跨边、分布式化升级。Kurator v0.2 版本已具备管理多云基础设施和异构基础设施的核心能力,通过引入Cluster Operator组件,支持“AWS自建集群”和“本地数据中心集群”包括集群创建、清理等在内的生命周期管理特性。在最新发布的v0.3.0版本中,Cluster Operator不仅分别对两类集群的生命周期管理能力进行了增强,也将v0.2.0版本中的多个API对象抽象成一个API对象cluster,方便用户使用。 同时,在 cluster 对象基础上,Kurator引入了舰队的概念。每个舰队代表一个物理集群组,方便Kurator未来进行统一的编排、调度,统一的流量治理以及统一的监控运维。目前,Kurator的舰队管理支持多个特性,包括舰队控制平面的生命周期管理,以及集群注册和注销到舰队等。至此,Kurator 通过集群舰队统一了集群视图。这意味着,Kurator开始具备了支持用户体验一致地管理分布在任何云上的集群的能力,从而进一步协助用户的分布式云原生架构的升级。Kurator v0.3.0关键特性介绍集群生命周期管理能力增强Kurator 通过 Cluster Operator组件对集群的生命周期进行管理。基于Cluster API,Cluster Operator 不仅可以管理集群生命周期,还统一并简化了创建集群所需的配置,为用户在不同云平台上管理集群提供了简单易用的API。目前Cluster Operator 支持“本地数据中心集群”和“AWS自建集群”。本地数据中心集群Kurator基于kubespray对本地数据中心集群的生命周期进行管理。与 kubespray不同的地方在于,Kurator采用了更易于理解和配置的云原生声明式的方法管理集群。相比较v0.2.0版本,v0.3.0版本的Kurator 带来了以下几个方面的增强特性:• 批量的工作节点扩缩容。 现在Kurator支持以声明式的方式,在原有集群上增加、删除或者替换多个工作节点。 用户只需要声明集群所需要的最终工作节点状态,Kurator即可在没有任何外部干预的情况下完成节点的批量扩缩容。• 集群版本升级。 用户可以在API对象上声明要升级到的Kubernetes版本,Kurator便会自动对目标集群的各节点进行升级。• 增强集群控制面高可用。Kurator为用户提供了一种基于VIP的增强集群控制面高可用的方案。在这种方案下,Kurator利用kube-vip的能力,使用VIP实现跨多个控制平面副本的入站流量负载均衡。图片来源:https://inductor.medium.com/say-good-bye-to-haproxy-and-keepalived-with-kube-vip-on-your-ha-k8s-control-plane-bb7237eca9fc用户手册:https://kurator.dev/docs/cluster-operator/vms-cluster-lifecycle/AWS自建集群Kurator 通过Cluster Operator对AWS自建集群进行生命周期管理管理。相较于Cluster API 对AWS 自建集群的支持, Kurator简化了Cluster API提供的部署模型,通过部署Kurator集群操作器组件即可获得全部的管理能力。v0.3.0在以下几个方面带来了特性增强:• 易用性提升。kurator新增了一系列提升用户体验的改进, 包括了在创建集群之前验证凭据是否有效,自动管理云平台运营商所需的IAM角色和策略,校验依赖资源是否存在以及集中展示错误信息等。一键关联IAM与K8s身份。通过将AWS IAM角色与Kubernetes Pod身份关联,可以让IAM验证和接受Kubernetes颁发的令牌,而不需要创建和分发AWS凭据。这种关联具有最小特权、凭证隔离和审计性等优点,但是需要通过多个步骤设置。Kurator现在可以通过Cluster.Spec.PodIdentityg一键启用该功能,简化配置。apiVersion: cluster.kurator.dev/v1alpha1 kind: Cluster metadata: name: pod-identity namespace: default spec: ... podIdentity: enabled: true用户手册:https://kurator.dev/docs/cluster-operator/kurator-cluster-api/https://kurator.dev/docs/cluster-operator/aws-irsa/云原生舰队管理Kurator引入了代表物理集群组的逻辑单元“舰队”,旨在一致地管理一组集群,舰队允许您轻松、一致地管理分布在任何云中的集群。Kurator通过Fleet Manager实现了对舰队控制平面生命周期管理,并且可以轻松的将集群添加到或从舰队中删除。 未来,Kurator将支持Fleet级的应用编排,并且在Fleet的所有集群中提供统一的命名空间、ServiceAccount、Service,以支持在多个集群之间实现服务发现和通信。此外,Kurator将汇总来自所有集群的监控指标。Kurator Fleet Manager作为一个Kubernetes Operator运行,负责Fleet控制平面生命周期管理,也负责集群的注册和注销。用户手册:https://kurator.dev/docs/fleet-manager/Kurator,一键构建分布式云原生平台访问Kurator Release(cid:link_0),体验、升级最新版Kurator v.0.3.0,构建您的专属分布式云原生平台。如您对Kurator新版本特性有更多兴趣或见解,也欢迎来到Kurator社区,参与社区讨论与开发。GitHub地址:cid:link_1Slack地址:https://join.slack.com/t/kurator-hq/shared_invite/zt-1sowqzfnl-Vu1AhxgAjSr1XnaFoogq0A
  • [行业前沿] 云原生多云容器编排引擎Karmada v1.5 – 多调度组助力成本优化
    作者:华为云云原生团队Karmada 是开放的多云多集群容器编排引擎,旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力,Karmada 可以平滑迁移单集群工作负载,并且仍可保持与 Kubernetes 周边生态工具链协同。在最新发布的1.5版本中,Karmada 提供了多调度组的能力,利用该能力,用户可以实现将业务优先调度到成本更低的集群,或者在主集群故障时,优先迁移业务到指定的备份集群。本版本其他新增特性:提供了多调度器支持能力,默认调度器可以与第三方自定义调度器协同工作,提供更强的定制能力。集群差异化配置策略(OverridePolicy/ClusterOverridePolicy)将按照隐式的优先级进行应用。内置资源解释器支持聚合StatefulSet/CronJob 状态。新特性概览多调度组根据 Flexera 发布的《2023 年云现状调查报告》,云成本的管理取代了安全性话题,成为当下云使用者面临的首要问题。Karmada 秉承这一趋势,同样关注云成本管理。从v1.5版本开始,用户可以在 PropagationPolicy/ClusterPropagationPolicy 中设置多个集群组,实现将业务优先调度到成本更低的集群组。下面我们给出一个针对成本优化进行调度的例子:apiVersion: policy.karmada.io/v1alpha1 kind: PropagationPolicy metadata: name: nginx spec: resourceSelectors: - apiVersion: apps/v1 kind: Deployment name: nginx placement: clusterAffinities: - affinityName: local-clusters clusterNames: - local-member1 - local-member2 - affinityName: cloud-clusters clusterNames: - huawei-member1 - huawei-member2上面的例子配置有本地集群组(local-clusters)和云上集群组(cloud-clusters),Karmada 在选择集群组进行资源分发时, 将按顺序对集群组逐一进行评估,直到找到满足调度约束的集群组。所以在调度Deployment/nginx时,会优先尝试调度到本地集群组的local-member1和local-member2,如果失败(如资源不足),则选择云上集群组,从而实现在本地集群资源足够时,优先选择成本更低的本地集群。基于此,系统管理员也可以定义主集群组和备份集群组,在主集群组故障时,将业务往备份集群组的集群迁移。下面我们给出一个针对容灾迁移的例子:apiVersion: policy.karmada.io/v1alpha1 kind: PropagationPolicy metadata: name: nginx spec: resourceSelectors: - apiVersion: apps/v1 kind: Deployment name: nginx placement: clusterAffinities: - affinityName: primary-cluster clusterNames: - member1 - affinityName: backup-cluster clusterNames: - member2上面的例子通过配置主群组(primary-cluster)和备份集群组(backup-cluster),在调度 Deployment/nginx 时,如果主集群组满足要求,会调度到主集群组的member1。在主集群组的集群故障时,调度器按顺序匹配新集群组,将业务迁移到备份集群组的member2。关于多调度组更多信息,请参考:cid:link_0自定义调度器Karmada 默认调度器内置多款可灵活配置的插件,可以满足大部分使用场景,用户还可以使用插件扩展机制来实现个性化调度诉求。Karmada 1.5版本提供了多调度器支持能力,Karmada 默认调度器可以与第三方自定义调度器协同工作,以提供更强的定制能力。用户可以参考默认调度器实现自定义调度器,当多个调度器共存时,需通过命令行启动参数指定调度器名称,如 --scheduler-name=my-scheduler 。如果自定义调度器与默认调度器部署在同一namespace中,建议同时配置 --leader-elect-resource-name 参数,以避免副本选主冲突。关键命令行启动参数如下所示:command: - /bin/karmada-scheduler - --kubeconfig=/etc/kubeconfig - --bind-address=0.0.0.0 - --secure-port=10351 - --enable-scheduler-estimator=true - --leader-elect-resource-name=my-scheduler # 你的自定义调度器名称 - --scheduler-name=my-scheduler # 你的自定义调度器名通过参数 --scheduler-name 将多个调度器进行区分,每个调度器将只负责调度特定的工作负载。通过 Karmada 分发工作负载时,可以在 PropagationPolicy/ClusterPropagationPolicy 的 schedulerName 字段指定调度器名字,如下所示:apiVersion: policy.karmada.io/v1alpha1 kind: PropagationPolicy metadata: name: nginx-propagation spec: schedulerName: my-scheduler resourceSelectors: - apiVersion: apps/v1 kind: Deployment name: nginx placement: clusterAffinity: clusterNames: - member1 - member2上例通过 schedulerName 指定此Deployment必须由名为 my-scheduler 的调度器进行调度,此时默认调度器将自动忽略该工作负载。schedulerName 如果没有指定,则默认值为 default-scheduler ,意味着由默认调度器进行调度,前面版本的用户升级到新版本时无需额外配置。关于如何扩展调度器插件和实现自定义调度器,请查看官方文档:cid:link_1版本升级Karmada v1.5版本API兼容v1.4版本API,v1.4版本的用户仍然可以平滑升级到v1.5版本。可参考升级文档:https://karmada.io/docs/administrator/upgrading/v1.4-v1.5致谢贡献者Karmada v1.5版本包含了来自25位贡献者的数百次代码提交,在此对各位贡献者表示由衷的感谢:贡献者GitHub ID:@a7i@calvin0327@carlory@chaunceyjiang@fengshunli@Fish-pro@Garrybest@helen-frank@ikaven1024@jwcesign@lonelyCZ@maoyangLiu@my-git9@Poor12@qingwave@RainbowMango@VedRatan@Wang-Kai@whitewindmills@wlp1153468871@wongearl@XiShanYongYe-Chang@yanfeng1992@yanggangtony@Zhuzhenghao参考链接Release Notes:cid:link_2多调度组:cid:link_02023 年云现状调查报告:cid:link_3扩展调度器插件和实现自定义调度器:cid:link_1附:Karmada社区技术交流地址项目地址:cid:link_4Slack地址:https://slack.cncf.io/(#karmada)
  • [云原生生态] 云原生2.0网关API标准发展趋势
    作者:华为云云原生团队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
  • [大咖交流] 华为云云原生团队: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。架构介绍图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
  • [技术干货] 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,漏洞公告已发布在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遇到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,进入云原生交流群
  • [行业前沿] 华为云云原生动态
    华为云海外首发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,进入云原生交流群
  • [热门活动] 【云原生专题直播有奖提问】DTSE Tech Talk 技术直播 NO.49:看直播提问题赢华为云定制长袖卫衣、华为云定制按摩枕等好礼!
    中奖结果公示感谢各位小伙伴参与本次活动,本次活动获奖名单如下:请获奖的伙伴在11月27日之前点击此处填写收货地址,如逾期未填写视为弃奖。再次感谢各位小伙伴参与本次活动,欢迎关注华为云DTSE Tech Talk 技术直播更多活动~直播简介【直播主题】Kmesh:架构创新为服务网格带来全新体验【直播时间】2023年11月22日 17:00-18:30【直播专家】吴长冶 华为云云原生DTSE技术布道师、华为云云原生技术专家 Kmesh项目负责人【直播简介】传统服务网格代理架构带来数据面的时延开销,无法满足应用SLA诉求,Kmesh为服务网格开启架构创新全新体验!通过将 L4、L7流量治理能力卸载到内核, Kmesh实现内核级云原生流量治理框架,使得服务转发性能分别提升 50%、60%,底噪开销降低 70%,为用户构建服务网格架构高性能方案!直播链接:cid:link_1活动介绍【互动方式】直播前您可以在本帖留下您疑惑的问题,专家会在直播时为您解答。直播后您可以继续在本帖留言,与专家互动交流。我们会在全部活动结束后对参与互动的用户进行评选。【活动时间】即日起—2023年11月23日【奖励说明】评奖规则:活动1:直播期间在直播间提出与直播内容相关的问题,对专家评选为优质问题的开发者进行奖励。奖品:华为云定制长袖卫衣活动2:在本帖提出与直播内容相关的问题,由专家在所有互动贴中选出最优问题贴的开发者进行奖励。奖品:华为云定制按摩枕更多直播活动直播互动有礼:官网直播间发口令“华为云 DTSE”抽华为云定制钢笔礼盒、填写问卷抽华为云定制鼠标等好礼【注意事项】1、所有参与活动的问题,如发现为复用他人内容或直播间中重复内容,则取消获奖资格。2、为保证您顺利领取活动奖品,请您在活动公示奖项后2个工作日内私信提前填写奖品收货信息,如您没有填写,视为自动放弃奖励。3、活动奖项公示时间截止2023年11月24日,如未反馈邮寄信息视为弃奖。本次活动奖品将于奖项公示后30个工作日内统一发出,请您耐心等待。4、活动期间同类子活动每个ID(同一姓名/电话/收货地址)只能获奖一次,若重复则中奖资格顺延至下一位合格开发者,仅一次顺延。5、如活动奖品出现没有库存的情况,华为云工作人员将会替换等价值的奖品,获奖者不同意此规则视为放弃奖品。6、其他事宜请参考【华为云社区常规活动规则】。
  • [热门活动] 【Kmesh专题直播有奖提问】DTSE Tech Talk 技术直播 NO.49:看直播提问题赢华为云定制保温杯、华为云定制颈枕等好礼!
    ▎直播简介💡【直播主题】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:有奖提问直播过程中提问,评选优质问题送华为云定制长袖卫衣。🌟 更多福利:加入微信交流群直播期间扫码入群,解锁更多隐藏福利哦~
  • [技术干货] 【云原生 免费课程】从0到1学云原生,云原生开发者养成路径!
    ​63个云原生课程视频,基本上包含了整个云原生学习周期里这些都是你得花心思掌握的。内容比较细,基本上满足实操需求,涉及到容器技术、K8s、监控、运维、存储,以及比较前沿的 istio 等等……适用人群:高校学生、企业中的个人开发者以及互联网从业人员。>>>戳我查看云原生开发者学习路径 在线课程添加小助手微信k8s2222,进入云原生技术交流群 
  • [问题求助] k8s集群性能测试
    k8s集群性能测试-求助k8s节点的极限怎样测试?k8s官方称最大节点5000个,查了之后很多人说最大500节点之后就会出现很多问题,那我想知道的是若我有一个集群,我怎样测试这个集群的极限? 怎样知道它是不是该加节点了?若我想测试一个集群的性能,可以从哪方面入手?有那些工具可以使用?若我想模拟一个超大集群测试,应该怎么做?
  • [问题求助] 如何保证在云原生环境下,应用的升级和扩展不会导致数据丢失或损坏?
    如何保证在云原生环境下,应用的升级和扩展不会导致数据丢失或损坏?
  • [问题求助] 云原生时代如何维护一个庞大、复杂且快速变化的分布式系统?
    云原生时代如何维护一个庞大、复杂且快速变化的分布式系统?
  • [技术干货] 率先支持Kuasar!iSulad Sandbox API 简化调用链,可靠性倍增
    沙箱隔离技术是一种将进程有效隔离到独立环境中运行的技术。随着容器技术的兴起,沙箱隔离技术也在云原生领域中得到了广泛的应用。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 v0.5.0: 打造统一的多集群备份与存储体验
    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进入技术交流群
总条数:356 到第
上滑加载中