12月12日，云原生计算基金会（CNCF）宣布，CNCF技术监督委员会（TOC）已投票通过 Karmada 为正式孵化项目。Karmada 是华为云捐赠的云计算开源技术，是业界首个多云多集群容器编排项目。正式晋升 CNCF 孵化级，也意味着 Karmada 的技术生态受到全球业界广泛认可，在分布式云原生技术领域领域进入了成熟新阶段。作为 CNCF 首个跨云跨集群容器编排引擎，Karmada 由华为云、工商银行、小红书、中国一汽等八家企业联合发起。项目于2021年4月正式开源，2021年9月加入CNCF 成为沙箱项目。Karmada 的贡献者来自世界各地，覆盖全球22个国家和地区的60多家组织，包括华为、DaoCloud、浙江大学、滴滴、腾讯、小红书、新浪、Intel、IBM、Red Hat、Comcast 等公司。截至目前，项目在开源软件项目托管平台 GitHub 已收获超过3600 Star。华为云 CTO 张宇昕表示：华为云长期致力于云原生技术、产业和生态的建设。Karmada源于社区和华为云在多云管理领域的深厚沉淀，为企业提供了从单集群到分布式云架构的平滑演进方案。“作为 Karmada 项目的发起者和主要贡献者之一，华为云将继续与 CNCF 和社区合作，释放无处不在的云原生价值。”“Karmada 开源以来受到了广泛的关注和支持，并帮助越来越多的最终用户在多云环境中高效管理 Kubernetes 集群和分布式应用。”Karmada 社区创始人兼维护者王泽锋表示：“我们很高兴 Karmada 已达到 CNCF 孵化状态，并将继续致力于将其发展成更为完善的国际化社区。”CNCF 技术监督委员会（TOC）委员Nikhita Raghunath 表示：Karmada 填补了Kubernetes 多云和多集群环境中的调度和编排方面的空白，可以为分布式组织提供更好的性能并降低成本。“自从加入 CNCF Sandbox 以来，项目团队一直不懈地努力添加新特性和功能，以融入更广阔的云原生生态。我们期待看到该项目的持续成长。”目前，项目已在华为云、兴业数金、中国移动云、中国联通、携程、vivo、飓风引擎、VIPKID、有赞、网易、快手、之江实验室等20多家企业和单位落地应用，以开源创新促进云原生产业发展，项目全球生态发展迅速。Karmada 的创新优势，也得到了企业用户的高度认可。“Karmada 使我们能够为 Zendesk 的内部工程团队提供多集群架构，同时保持身份验证、配置交付和服务管理的单点访问。”Zendesk 计算团队工程经理 Adam Minasian 说到，“随着 Karmada 项目进入 CNCF 孵化阶段，我们很高兴能够继续与该项目合作。”“Karmada 为企业落地多云战略提供了便捷的基础设施。它基于中立、厂商无关的设计，让用户在极小代价情况下，灵活接入和切换多云和混合云；同时它为客户在微服务跨集群编排、跨集群弹性伸缩，多云化的访问、容灾等场景带来了便利性。”DaoCloud 联合创始人兼首席架构师颜开表示。基于对可持续供应的考虑，以及对业务快速扩展的需求，混合云多云已成为携程集团的技术优选。“Karmada 以其标准的 K8s API 兼容性、关注点分离的原则、活跃的社区，帮助我们构建了混合多云的控制面，降低了架构迁移成本和异构环境的管理复杂性。”携程集团容器与混合云团队总监乐鸿辉表示，携程借助于Karmada 实现的故障隔离架构和多集群 HPA，也帮助公司成功应对旅游业的强劲复苏。“Karmada 简化了多集群环境中的集群与应用的交付和管理，实现跨集群的资源协调，以增强应用程序的可用性和弹性。它确保稳定、高效、可控的应用程序部署和更新。”Shopee 专家工程师李鹤表示。“Karmada 作为开源的多云容器编排平台，为云原生中间件提供了灵活性和可靠的跨平台、跨区域、跨云的资源管理，为中间件同城跨机房高可用提供了基石。”网易资深开发工程师孟祥勇表示。目前，Karmada 社区已累计更新67个版本。晋级 CNCF 孵化项目后，项目进一步规划了社区发展路标，并正在积极添加新功能和特性，如多集群安全、大规模场景应用、多集群可观测性、多集群应用分发、生态融合发展等。作为 CNCF 亚洲唯一创始成员、白金会员，华为云在CNCF贡献量、Kubernetes社区和 Istio 社区的代码贡献量持续多年稳居亚洲第一，已向 CNCF 贡献了业界首个云原生边缘计算项目 KubeEdge、首个云原生批量算力项目 Volcano 等多个重量级云原生开源项目，并持续开源 Kurator、Kappital、Kuasar 等创新项目，与全球云原生社区共同发展。华为云分布式云原生 UCS 基于 Karmada 项目构建全新的应用算力供给模式，解决资源供应，协同全局资源，提供领先的分布式云原生应用服务。Karmada 正式晋级 CNCF 孵化项目，进一步展现了华为云持续践行开源、拥抱开源，与全球开发者共创先进技术的理念，持续助力云上开源创新生态发展。未来，Karmada 将持续探索云原生多云多集群领域技术创新，让基于 Karmada 的多云方案融入更广泛的云原生技术生态。Karmada官网：https://karmada.io/项目地址：cid:link_0Slack地址：https://slack.cncf.io/

中奖结果公示感谢各位小伙伴参与本次活动，本次活动获奖名单如下：请获奖的伙伴在12月12日之前点击此处填写收货地址，如逾期未填写视为弃奖。再次感谢各位小伙伴参与本次活动，欢迎关注华为云DTSE Tech Talk 技术直播更多活动~直播简介【直播主题】从架构设计到开发实战，深入浅出了解Sermant【直播时间】2023年12月6日 16:30-18:00【直播专家】栾文飞 华为云云原生DTSE技术布道师【直播简介】云原生无代理服务网格太深奥？带你深入浅出了解Sermant，从架构设计到开发实战，步步为营。本期直播将聚焦于Sermant的架构解析及开发实战中，从开发者视角来看核心设计中的插件机制和类加载器架构，在实战中从基础能力开发，到进阶使用统一动态配置能力、统一日志能力等一步步完成插件开发。直播链接：cid:link_1活动介绍【互动方式】直播前您可以在本帖留下您疑惑的问题，专家会在直播时为您解答。直播后您可以继续在本帖留言，与专家互动交流。我们会在全部活动结束后对参与互动的用户进行评选。【活动时间】即日起—2023年12月7日【奖励说明】评奖规则：活动1：直播期间在直播间提出与直播内容相关的问题，对专家评选为优质问题的开发者进行奖励。奖品：华为云定制长袖卫衣活动2：在本帖提出与直播内容相关的问题，由专家在所有互动贴中选出最优问题贴的开发者进行奖励。奖品：书籍《微服务架构设计模式》更多直播活动直播互动有礼：官网直播间发口令“华为云 DTSE”抽华为云定制钢笔礼盒、填写问卷抽华为云定制鼠标等好礼【注意事项】1、所有参与活动的问题，如发现为复用他人内容或直播间中重复内容，则取消获奖资格。2、为保证您顺利领取活动奖品，请您在活动公示奖项后2个工作日内私信提前填写奖品收货信息，如您没有填写，视为自动放弃奖励。3、活动奖项公示时间截止2023年12月8日，如未反馈邮寄信息视为弃奖。本次活动奖品将于奖项公示后30个工作日内统一发出，请您耐心等待。4、活动期间同类子活动每个ID（同一姓名/电话/收货地址）只能获奖一次，若重复则中奖资格顺延至下一位合格开发者，仅一次顺延。5、如活动奖品出现没有库存的情况，华为云工作人员将会替换等价值的奖品，获奖者不同意此规则视为放弃奖品。6、其他事宜请参考【华为云社区常规活动规则】。

前面我们了解了位于服务网格内部的应用应如何访问网格外部的 HTTP 和 HTTPS 服务，知道如何通过 ServiceEntry 对象配置 Istio 以受控的方式访问外部服务，这种方式实际上是通过 Sidecar 直接调用的外部服务，但是有时候我们可能需要通过专用的 Egress Gateway 服务来调用外部服务，这种方式可以更好的控制对外部服务的访问。Istio 使用 Ingress 和 Egress Gateway 配置运行在服务网格边缘的负载均衡，Ingress Gateway 允许定义网格所有入站流量的入口。Egress Gateway 是一个与 Ingress Gateway 对称的概念，它定义了网格的出口。Egress Gateway 允许我们将 Istio 的功能（例如，监视和路由规则）应用于网格的出站流量。使用场景比如有一个对安全要求非常严格的团队，要求服务网格所有的出站流量必须经过一组专用节点。专用节点运行在专门的机器上，与集群中运行应用程序的其他节点隔离，这些专用节点用于实施 Egress 流量的策略，并且受到比其余节点更严密地监控。另一个使用场景是集群中的应用节点没有公有 IP，所以在该节点上运行的网格服务都无法访问互联网，那么我们就可以通过定义 Egress gateway，将公有 IP 分配给 Egress Gateway 节点，用它引导所有的出站流量，可以使应用节点以受控的方式访问外部服务。接下来我们就来学习下在 Istio 中如何配置使用 Egress Gateway。准备工作如果你使用的 demo 这个配置文件安装 Istio，那么 Egress Gateway 已经默认安装了，可以通过下面的命令来查看：$ kubectl get pod -l istio=egressgateway -n istio-system NAME READY STATUS RESTARTS AGE istio-egressgateway-556f6f58f4-hkzdd 1/1 Running 0 14d如果没有 Pod 返回，可以通过下面的步骤来部署 Istio Egress Gateway。如果你使用 IstioOperator 安装 Istio，请在配置中添加以下字段：spec: components: egressGateways: - name: istio-egressgateway enabled: true否则使用如下的 istioctl install 命令来安装：$ istioctl install <flags-you-used-to-install-Istio> \ --set components.egressGateways[0].name=istio-egressgateway \ --set components.egressGateways[0].enabled=true同样我们还是使用 sleep 示例做为发送请求的测试源，如果启用了自动 Sidecar 注入，运行以下命令部署示例应用程序：kubectl apply -f samples/sleep/sleep.yaml否则，在使用以下命令部署 sleep 应用程序之前，手动注入 Sidecar：kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml)为了发送请求，您需要创建 SOURCE_POD 环境变量来存储源 Pod 的名称：export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})用 Egress gateway 发起 HTTP 请求首先创建一个 ServiceEntry 对象来允许流量直接访问外部的 edition.cnn.com 服务。apiVersion: networking.istio.io/v1alpha3 kind: ServiceEntry metadata: name: cnn spec: hosts: - edition.cnn.com ports: - number: 80 name: http-port protocol: HTTP - number: 443 name: https protocol: HTTPS resolution: DNS发送 HTTPS 请求到 https://edition.cnn.com/politics 验证 ServiceEntry 是否已正确应用。$ kubectl exec "$SOURCE_POD" -c sleep -- curl -sSL -o /dev/null -D - http://edition.cnn.com/politics # 输出如下内 HTTP/1.1 301 Moved Permanently # ...... location: https://edition.cnn.com/politics # ...... HTTP/2 200 Content-Type: text/html; charset=utf-8 # ......然后为 edition.cnn.com 的 80 端口创建一个 egress Gateway，并为指向 Egress Gateway 的流量创建一个 DestinationRule 规则，如下所示：apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: istio-egressgateway spec: selector: istio: egressgateway # 匹配 Egress Gateway Pod 的标签 servers: - port: number: 80 name: http protocol: HTTP hosts: - edition.cnn.com # 也支持通配符 * 的形式 --- apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: egressgateway-for-cnn spec: host: istio-egressgateway.istio-system.svc.cluster.local # 目标规则为 Egress Gateway subsets: - name: cnn # 定义一个子集 cnn，没有指定 labels，则 subset 会包含所有符合 host 字段指定的服务的 Pod在上面的对象中我们首先定义了一个 Gateway 对象，不过这里我们定义的是一个 Egress Gateway，通过 istio: egressgateway 匹配 Egress Gateway Pod 的标签，并在 servers 中定义了 edition.cnn.com 服务的 80 端口。然后定义了一个 DestinationRule 对象，指定了目标规则为 istio-egressgateway.istio-system.svc.cluster.local，并定义了一个子集 cnn。这里的子集名称是 cnn，但没有指定 labels。这意味着，这个 subset 会涵盖所有属于 istio-egressgateway.istio-system.svc.cluster.local 服务的 Pod。这种情况下，subset 的作用主要是为了在其他 Istio 配置中提供一个方便的引用名称，而不是为了区分不同的 Pod 子集。如何再定义一个 VirtualService 对象将流量从 Sidecar 引导至 Egress Gateway，再从 Egress Gateway 引导至外部服务，如下所示：apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: direct-cnn-through-egress-gateway spec: hosts: - edition.cnn.com gateways: - istio-egressgateway # Egress Gateway - mesh # 网格内部的流量 http: - match: - gateways: - mesh # 这条规则适用于从服务网格内发出的流量 port: 80 route: - destination: host: istio-egressgateway.istio-system.svc.cluster.local # 流量将被路由到 egress gateway subset: cnn port: number: 80 weight: 100 - match: - gateways: - istio-egressgateway # 这条规则适用于通过 istio-egressgateway 的流量 port: 80 route: - destination: host: edition.cnn.com # 流量将被路由到外部服务 port: number: 80 weight: 100在上面的 VirtualService 对象中通过 hosts 指定 edition.cnn.com，表示该虚拟服务用于该服务的请求，gateways 字段中定义了 istio-egressgateway 和 mesh 两个值，istio-egressgateway 是上面我们定义的 Egress Gateway，mesh 表示该虚拟服务用于网格内部的流量，也就是说这个虚拟服务指定了如何处理来自服务网格内部以及通过 istio-egressgateway 的流量。mesh 是一个特殊的关键字，在 Istio 中表示服务网格内的所有 Sidecar 代理。当使用 mesh 作为网关时，这意味着 VirtualService 中定义的路由规则适用于服务网格内的所有服务，即所有装有 Istio sidecar 代理的服务。http 字段中定义了两个 match，第一个 match 用于匹配 mesh 网关，第二个 match 用于匹配 istio-egressgateway 网关，然后在 route 中定义了两个 destination，第一个 destination 用于将流量引导至 Egress Gateway 的 cnn 子集，第二个 destination 用于将流量引导至外部服务。总结来说，这个 VirtualService 的作用是控制服务网格内部到 edition.cnn.com 的流量。当流量起始于服务网格内时，它首先被路由到 istio-egressgateway，然后再路由到 edition.cnn.com，这种配置有助于统一和控制从服务网格内部到外部服务的流量，可以用于流量监控、安全控制或实施特定的流量策略。应用上面的资源对象后，我们再次向 edition.cnn.com 的 /politics 端点发出 curl 请求：$ kubectl exec "$SOURCE_POD" -c sleep -- curl -sSL -o /dev/null -D - http://edition.cnn.com/politics # ...... HTTP/1.1 301 Moved Permanently location: https://edition.cnn.com/politics # ...... HTTP/2 200 Content-Type: text/html; charset=utf-8 # ......正常和前面的一次测试输出结果是一致的，但是这次在请求是经过 istio-egressgateway Pod 发出的，我们可以查看日志来验证：kubectl logs -l istio=egressgateway -c istio-proxy -n istio-system | tail正常会看到一行类似于下面这样的内容：[2023-11-15T08:48:38.683Z] "GET /politics HTTP/2" 301 - via_upstream - "-" 0 0 204 203 "10.244.1.73" "curl/7.81.0-DEV" "6c2c4550-92d4-955c-b6cb-83bf2b0e06f4" "edition.cnn.com" "151.101.3.5:80" outbound|80||edition.cnn.com 10.244.2.184:46620 10.244.2.184:8080 10.244.1.73:49924 - -因为我们这里只是将 80 端口的流量重定向到 Egress Gateway 了，所以重定向后 443 端口的 HTTPS 流量将直接进入 edition.cnn.com，所以没有看到 443 端口的日志，但是我们可以通过 SOURCE_POD 的 Sidecar 代理的日志来查看到：$ kubectl logs "$SOURCE_POD" -c istio-proxy | tail # ...... [2023-11-15T08:55:55.513Z] "GET /politics HTTP/1.1" 301 - via_upstream - "-" 0 0 191 191 "-" "curl/7.81.0-DEV" "12ce15aa-1247-9b7e-8185-4224f96f5ea0" "edition.cnn.com" "10.244.2.184:8080" outbound|80|cnn|istio-egressgateway.istio-system.svc.cluster.local 10.244.1.73:49926 151.101.195.5:80 10.244.1.73:41576 - - [2023-11-15T08:55:55.753Z] "- - -" 0 - - - "-" 839 2487786 1750 - "-" "-" "-" "-" "151.101.195.5:443" outbound|443||edition.cnn.com 10.244.1.73:45246 151.101.67.5:443 10.244.1.73:42998 edition.cnn.com -用 Egress gateway 发起 HTTPS 请求上面我们已经学习了如何通过 Egress Gateway 发起 HTTP 请求，接下来我们再来学习下如何通过 Egress Gateway 发起 HTTPS 请求。原理都是一样的，只是我们需要在相应的 ServiceEntry、Egress Gateway 和 VirtualService 中指定 TLS 协议的端口 443。首先为 edition.cnn.com 定义 ServiceEntry 服务：apiVersion: networking.istio.io/v1alpha3 kind: ServiceEntry metadata: name: cnn spec: hosts: - edition.cnn.com ports: - number: 443 name: tls protocol: TLS resolution: DNS应用该资源对象后，发送 HTTPS 请求到 https://edition.cnn.com/politics，验证该 ServiceEntry 是否已正确生效。$ kubectl exec "$SOURCE_POD" -c sleep -- curl -sSL -o /dev/null -D - https://edition.cnn.com/politics ... HTTP/2 200 Content-Type: text/html; charset=utf-8 ...接下来同样的方式为 edition.cnn.com 创建一个 Egress Gateway。除此之外还需要创建一个目标规则和一个虚拟服务，用来引导流量通过 Egress Gateway，并通过 Egress Gateway 与外部服务通信。apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: istio-egressgateway spec: selector: istio: egressgateway servers: - port: number: 443 name: tls protocol: TLS hosts: - edition.cnn.com tls: mode: PASSTHROUGH # 透传 --- apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: egressgateway-for-cnn spec: host: istio-egressgateway.istio-system.svc.cluster.local subsets: - name: cnn --- apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: direct-cnn-through-egress-gateway spec: hosts: - edition.cnn.com gateways: - mesh - istio-egressgateway tls: - match: - gateways: - mesh port: 443 sniHosts: - edition.cnn.com route: - destination: host: istio-egressgateway.istio-system.svc.cluster.local subset: cnn port: number: 443 - match: - gateways: - istio-egressgateway port: 443 sniHosts: - edition.cnn.com route: - destination: host: edition.cnn.com port: number: 443 weight: 100上面对象中定义的 Gateway 对象和前面的一样，只是将端口改为了 443，然后在 tls 中指定了 mode: PASSTHROUGH，表示该 Gateway 对象用于 TLS 协议的请求。然后在后面的 VirtualService 对象中就是配置 spec.tls 属性，用于指定 TLS 协议的请求的路由规则，配置方法和前面 HTTP 方式类似，只是注意要将端口改为 443，并且在 match 中指定 sniHosts 为 edition.cnn.com，表示该虚拟服务用于处理 edition.cnn.com 的 TLS 请求。应用上面的资源对象后，我们现在发送 HTTPS 请求到 https://edition.cnn.com/politics，输出结果应该和之前一样。$ kubectl exec "$SOURCE_POD" -c sleep -- curl -sSL -o /dev/null -D - https://edition.cnn.com/politics ... HTTP/2 200 Content-Type: text/html; charset=utf-8 ...检查 Egress Gateway 代理的日志，则打印日志的命令是：kubectl logs -l istio=egressgateway -n istio-system应该会看到类似于下面的内容：[2023-11-15T08:59:55.513Z] "- - -" 0 - 627 1879689 44 - "-" "-" "-" "-" "151.101.129.67:443" outbound|443||edition.cnn.com 172.30.109.80:41122 172.30.109.80:443 172.30.109.112:59970 edition.cnn.com到这里我们就实现了通过 Egress Gateway 发起 HTTPS 请求。最后记得清理上面创建的资源对象：$ kubectl delete serviceentry cnn $ kubectl delete gateway istio-egressgateway $ kubectl delete virtualservice direct-cnn-through-egress-gateway $ kubectl delete destinationrule egressgateway-for-cnn需要注意的是，Istio 无法强制让所有出站流量都经过 Egress Gateway， Istio 只是通过 Sidecar 代理实现了这种流向。攻击者只要绕过 Sidecar 代理， 就可以不经 Egress Gateway 直接与网格外的服务进行通信，从而避开了 Istio 的控制和监控。出于安全考虑，集群管理员和云供应商必须确保网格所有的出站流量都要经过 Egress Gateway。这需要通过 Istio 之外的机制来满足这一要求。例如，集群管理员可以配置防火墙，拒绝 Egress Gateway 以外的所有流量。Kubernetes NetworkPolicy 也能禁止所有不是从 Egress Gateway 发起的出站流量，但是这个需要 CNI 插件的支持。此外，集群管理员和云供应商还可以对网络进行限制，让运行应用的节点只能通过 gateway 来访问外部网络。要实现这一限制，可以只给 Gateway Pod 分配公网 IP，并且可以配置 NAT 设备， 丢弃来自 Egress Gateway Pod 之外的所有流量。Egress TLS Origination接下来我们将学习如何通过配置 Istio 去实现对发往外部服务的流量的 TLS Origination（TLS 发起）。若此时原始的流量为 HTTP，则 Istio 会将其转换为 HTTPS 连接。TLS Origination 的概念前面我们也已经介绍过了。TLS Origination假设有一个传统应用正在使用 HTTP 和外部服务进行通信，如果有一天突然有一个新的需求，要求必须对所有外部的流量进行加密。此时，使用 Istio 便可通过修改配置实现此需求，而无需更改应用中的任何代码。该应用可以发送未加密的 HTTP 请求，由 Istio 为请求进行加密。从应用源头发起未加密的 HTTP 请求，并让 Istio 执行 TLS 升级的另一个好处是可以产生更好的遥测并为未加密的请求提供更多的路由控制。下面我们就来学习下如何配置 Istio 实现 TLS Origination。同样我们这里使用 sleep 示例应用来作为测试源，如果启用了自动注入 Sidecar，那么可以直接部署 sleep 应用：kubectl apply -f samples/sleep/sleep.yaml否则在部署 sleep 应用之前，必须手动注入 Sidecar：kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml)创建一个环境变量来保存用于将请求发送到外部服务 Pod 的名称：export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})▍配置对外部服务的访问首先使用 ServiceEntry 对象来配置对外部服务 edition.cnn.com 的访问。这里我们将使用单个 ServiceEntry 来启用对服务的 HTTP 和 HTTPS 访问。创建一个如下所示的 ServiceEntry 对象：apiVersion: networking.istio.io/v1alpha3 kind: ServiceEntry metadata: name: edition-cnn-com spec: hosts: - edition.cnn.com ports: - number: 80 name: http-port protocol: HTTP - number: 443 name: https-port protocol: HTTPS resolution: DNS上面的 ServiceEntry 对象中我们指定了 edition.cnn.com 服务的主机名，然后在 ports 中指定了需要暴露的端口及其属性，表示该 ServiceEntry 对象代表对 edition.cnn.com 的访问，这里我们定义了 80 和 443 两个端口，分别对应 http 和 https 服务，resolution: DNS 定义了如何解析指定的 hosts，这里我们使用 DNS 来解析。直接应用该资源对象，然后向外部的 HTTP 服务发送请求：$ kubectl exec "${SOURCE_POD}" -c sleep -- curl -sSL -o /dev/null -D - http://edition.cnn.com/politics # 输出如下结果 HTTP/1.1 301 Moved Permanently # ...... location: https://edition.cnn.com/politics HTTP/2 200 content-type: text/html; charset=utf-8 # ......上面我们在使用 curl 命令的时候添加了一个 -L 标志，该标志指示 curl 将遵循重定向。在这种情况下，服务器将对到 http://edition.cnn.com/politics 的 HTTP 请求进行重定向响应，而重定向响应将指示客户端使用 HTTPS 向 https://edition.cnn.com/politics 重新发送请求，对于第二个请求，服务器则返回了请求的内容和 200 状态码。尽管 curl 命令简明地处理了重定向，但是这里有两个问题。第一个问题是请求冗余，它使获取 http://edition.cnn.com/politics 内容的延迟加倍，第二个问题是 URL 中的路径（在本例中为 politics）被以明文的形式发送。如果有人嗅探你的应用与 edition.cnn.com 之间的通信，他将会知晓该应用获取了此网站中哪些特定的内容。出于隐私的原因，我们可能希望阻止这些内容被嗅探到。通过配置 Istio 执行 TLS 发起，则可以解决这两个问题。▍用于 egress 流量的 TLS 发起为 edition.cnn.com 创建一个出口网关，端口为 80，接收 HTTP 流量，如下所示：apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: istio-egressgateway spec: selector: istio: egressgateway servers: - port: number: 80 name: tls-origination-port protocol: HTTP hosts: - edition.cnn.com然后为 istio-egressgateway 创建一个 DestinationRule 对象，如下所示：apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: egressgateway-for-cnn spec: host: istio-egressgateway.istio-system.svc.cluster.local subsets: - name: cnn接着我们只需要创建一个 VirtualService 对象，将流量从 Sidecar 引导至 Egress Gateway，再从 Egress Gateway 引导至外部服务，如下所示：apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: direct-cnn-through-egress-gateway spec: hosts: - edition.cnn.com gateways: - istio-egressgateway # Egress Gateway - mesh # 网格内部的流量 http: - match: - gateways: - mesh port: 80 route: - destination: host: istio-egressgateway.istio-system.svc.cluster.local subset: cnn port: number: 80 weight: 100 - match: - gateways: - istio-egressgateway port: 80 route: - destination: host: edition.cnn.com port: number: 443 # 443 端口 weight: 100 --- apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: originate-tls-for-edition-cnn-com spec: host: edition.cnn.com trafficPolicy: loadBalancer: simple: ROUND_ROBIN portLevelSettings: - port: number: 443 tls: mode: SIMPLE # initiates HTTPS for connections to edition.cnn.com需要注意的是上面最后针对 edition.cnn.com 的 DestinationRule 对象，在 trafficPolicy 中指定了 portLevelSettings 用于对不同的端口定义不同的流量策略，这里我们定义了 443 端口的 tls 模式为 SIMPLE，表示当访问 edition.cnn.com 的 HTTP 请求时执行 TLS 发起。应用上面的资源对象，然后再次向 http://edition.cnn.com/politics 发送 HTTP 请求：$ kubectl exec "${SOURCE_POD}" -c sleep -- curl -sSL -o /dev/null -D - http://edition.cnn.com/politics # 直接输出200状态码 HTTP/1.1 200 OK content-length: 2474958 content-type: text/html; charset=utf-8 # ......这次将会收到唯一的 200 OK 响应，因为 Istio 为 curl 执行了 TLS 发起，原始的 HTTP 被升级为 HTTPS 并转发到 edition.cnn.com。服务器直接返回内容而无需重定向，这消除了客户端与服务器之间的请求冗余，使网格保持加密状态，隐藏了你的应用获取 edition.cnn.com 中 politics 端点的信息。如果我们在代码中有去访问外部服务，那么我们就可以不用修改代码了，只需要通过配置 Istio 来获得 TLS 发起即可，而无需更改一行代码。到这里我们就学习了如何通过配置 Istio 实现对外部服务的 TLS 发起。▍TLS 与 mTLS 基本概念前面我们学习了如何通过配置 Istio 实现对外部服务的 TLS 发起，这里其实还有一个 mTLS 的概念呢，由于 TLS 本身就比较复杂，对于双向 TLS（mTLS）就更复杂了。TLS 是一个连接层协议，旨在为 TCP 连接提供安全保障。TLS 在连接层工作，可以与任何使用 TCP 的应用层协议结合使用。例如，HTTPS 是 HTTP 与 TLS 的结合（HTTPS 中的 S 指的是 SSL，即 TLS 的前身），TLS 认证的流程大致如下所示：首先向第三方机构 CA 提交组织信息、个人信息(域名)等信息并申请认证。CA 通过多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等。如信息审核通过，CA 会向申请者签发认证文件-证书。证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构 CA 的信息、有效时间、证书序列号等信息的明文，同时包含一个签名。其中签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用 CA 的私钥对信息摘要进行加密，密文即签名。客户端向服务端发出请求时，服务端返回证书文件。客户端读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应 CA 的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性。客户端还会验证证书相关的域名信息、有效时间等信息; 客户端会内置信任 CA 的证书信息(包含公钥)，比如浏览器基本上都带有知名公共 CA 机构的证书，如 Verisign、Digicert 等，这些证书在发布时被打包在一起，当我们下载浏览器时，就经把正确的证书放进了浏览器，如果 CA 不被信任，则找不到对应 CA 的证书，证书也会被判定非法。认证过程当然 HTTPS 的工作流程和这个过程基本就一致了：1.客户端发起一个 HTTPS 请求。2.服务端把配置好的证书返回给客户端。3.客户端验证证书：比如是否在有效期内，证书的用途是不是匹配 Client 请求的站点，是不是在 CRL 吊销列表里面，它的上一级证书是否有效等。4.客户端使用伪随机数生成对称密钥，并通过证书里服务器的公钥进行加密，后续使用该对称密钥进行传输信息。5.服务端使用自己的私钥解密这个消息，得到对称密钥。至此，客户端和服务端都持有了相同的对称密钥。6.服务端使用对称密钥加密明文内容 A，发送给客户端。7.客户端使用对称密钥解密响应的密文，得到明文内容 A。8.客户端再次发起 HTTPS 的请求，使用对称密钥加密请求的明文内容 B，然后服务器使用对称密钥解密密文，得到明文内容 B。HTTPS 工作流程当然双向 TLS 就更为复杂了，Mutual TLS（双向 TLS），或称 mTLS，对于常规的 TLS，只需要服务端认证，mTLS 相对来说有一个额外的规定：客户端也要经过认证。在 mTLS 中，客户端和服务器都有一个证书，并且双方都使用它们的公钥/私钥对进行身份验证。TLS 保证了真实性，但默认情况下，这只发生在一个方向上：客户端对服务器进行认证，但服务器并不对客户端进行认证。为什么 TLS 的默认只在一个方向进行认证？因为客户端的身份往往是不相关的。例如我们在访问优点知识的时候，你的浏览器已经验证了要访问的网站服务端的身份，但服务端并没有验证你的浏览器的身份，它实际上并不关心你的浏览器的身份，这对于互联网上的 Web 项目来说足够了。但是在某些情况下，服务器确实需要验证客户端的身份，例如，当客户端需要访问某些敏感数据时，服务器可能需要验证客户端的身份，以确保客户端有权访问这些数据，这就是 mTLS 的用武之地，mTLS 是保证微服务之间跨服务通信安全的好方法。首先，你想要安全的通信。当我们把我们的应用程序拆分为多个服务时，我们最终会在这些服务之间的网络上发送敏感数据。任何能够进入网络的人都有可能读取这些敏感数据并伪造请求。其次，你关心客户端的身份。首先，你要确保你能知道调用是什么时候发生的，以便进行诊断，并正确记录指标等事项。此外，你可能想对这些身份进行授权（允许 A 调用 B 吗）。当然授权是另外的话题了。接下来我们就来测试下如何通过 egress 网关发起双向 TLS 连接。▍通过 egress 网关发起双向 TLS 连接首先使用 openssl 命令生成客户端和服务器的证书与密钥，为你的服务签名证书创建根证书和私钥：openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -subj '/O=example Inc./CN=example.com' -keyout example.com.key -out example.com.crt # 生成 CA 证书和私钥为 my-nginx.mesh-external.svc.cluster.local 创建证书和私钥：# 为 my-nginx.mesh-external.svc.cluster.local 创建私钥和证书签名请求 $ openssl req -out my-nginx.mesh-external.svc.cluster.local.csr -newkey rsa:2048 -nodes -keyout my-nginx.mesh-external.svc.cluster.local.key -subj "/CN=my-nginx.mesh-external.svc.cluster.local/O=some organization" # 使用 CA 公钥和私钥以及证书签名请求为 my-nginx.mesh-external.svc.cluster.local 创建证书 $ openssl x509 -req -sha256 -days 365 -CA example.com.crt -CAkey example.com.key -set_serial 0 -in my-nginx.mesh-external.svc.cluster.local.csr -out my-nginx.mesh-external.svc.cluster.local.crt然后生成客户端证书和私钥：# 为 client.example.com 创建私钥和证书签名请求 $ openssl req -out client.example.com.csr -newkey rsa:2048 -nodes -keyout client.example.com.key -subj "/CN=client.example.com/O=client organization" # 使用相同的 CA 公钥和私钥以及证书签名请求为 client.example.com 创建证书 $ openssl x509 -req -sha256 -days 365 -CA example.com.crt -CAkey example.com.key -set_serial 1 -in client.example.com.csr -out client.example.com.crt接着我们来部署一个双向 TLS 服务器，为了模拟一个真实的支持双向 TLS 协议的外部服务，我们在 Kubernetes 集群中部署一个 NGINX 服务，该服务运行在 Istio 服务网格之外，比如运行在一个没有开启 Istio Sidecar proxy 注入的命名空间中。创建一个命名空间 mesh-external 表示 Istio 网格之外的服务，注意在这个命名空间中，Sidecar 自动注入是没有开启的，不会在 Pod 中自动注入 Sidecar proxy。kubectl create namespace mesh-external然后创建 Kubernetes Secret，保存服务器和 CA 的证书。$ kubectl create -n mesh-external secret tls nginx-server-certs --key my-nginx.mesh-external.svc.cluster.local.key --cert my-nginx.mesh-external.svc.cluster.local.crt $ kubectl create -n mesh-external secret generic nginx-ca-certs --from-file=example.com.crt生成 NGINX 服务器的配置文件：$ cat <<\EOF > ./nginx.conf events { } http { log_format main '$remote_addr - $remote_user [$time_local] $status ' '"$request" $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; error_log /var/log/nginx/error.log; server { listen 443 ssl; root /usr/share/nginx/html; index index.html; server_name my-nginx.mesh-external.svc.cluster.local; ssl_certificate /etc/nginx-server-certs/tls.crt; ssl_certificate_key /etc/nginx-server-certs/tls.key; ssl_client_certificate /etc/nginx-ca-certs/example.com.crt; ssl_verify_client on; } } EOF生成 Kubernetes ConfigMap 保存 NGINX 服务器的配置文件：kubectl create configmap nginx-configmap -n mesh-external --from-file=nginx.conf=./nginx.conf然后就可以部署 NGINX 服务了：$ kubectl apply -f - <<EOF apiVersion: v1 kind: Service metadata: name: my-nginx namespace: mesh-external labels: run: my-nginx spec: ports: - port: 443 protocol: TCP selector: run: my-nginx --- apiVersion: apps/v1 kind: Deployment metadata: name: my-nginx namespace: mesh-external spec: selector: matchLabels: run: my-nginx template: metadata: labels: run: my-nginx spec: containers: - name: my-nginx image: nginx ports: - containerPort: 443 volumeMounts: - name: nginx-config mountPath: /etc/nginx readOnly: true - name: nginx-server-certs mountPath: /etc/nginx-server-certs readOnly: true - name: nginx-ca-certs mountPath: /etc/nginx-ca-certs readOnly: true volumes: - name: nginx-config configMap: name: nginx-configmap - name: nginx-server-certs secret: secretName: nginx-server-certs - name: nginx-ca-certs secret: secretName: nginx-ca-certs EOF现在如果我们在网格内部去直接访问这个 my-nginx 服务，是无法访问的，第一是没有内置 CA 证书，另外是 my-nginx 服务开启了 mTLS，需要客户端证书才能访问，现在我们的网格中是没有对应的客户端证书的，会出现 400 错误。开启了双向认证▍为 egress 流量配置双向 TLS创建 Kubernetes Secret 保存客户端证书：kubectl create secret -n istio-system generic client-credential --from-file=tls.key=client.example.com.key \ --from-file=tls.crt=client.example.com.crt --from-file=ca.crt=example.com.crtSecret 所在的命名空间必须与出口网关部署的位置一致，我们这里是 istio-system 命名空间。然后为 my-nginx.mesh-external.svc.cluster.local 创建一个端口为 443 的 Egress Gateway，以及目标规则和虚拟服务来引导流量流经 egress 网关并从 egress 网关流向外部服务。$ kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: istio-egressgateway spec: selector: istio: egressgateway servers: - port: number: 443 name: https protocol: HTTPS hosts: - my-nginx.mesh-external.svc.cluster.local tls: mode: ISTIO_MUTUAL --- apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: egressgateway-for-nginx spec: host: istio-egressgateway.istio-system.svc.cluster.local subsets: - name: nginx trafficPolicy: loadBalancer: simple: ROUND_ROBIN portLevelSettings: - port: number: 443 tls: mode: ISTIO_MUTUAL sni: my-nginx.mesh-external.svc.cluster.local EOF上面我们定义的 Gateway 对象和前面的一样，只是将端口改为了 443，然后在 tls 中指定了 mode: ISTIO_MUTUAL，表示该 Gateway 对象用于 TLS 双向认证协议的请求。然后同样在后面的 DestinationRule 对象中配置了通过 istio-egressgateway 的流量的规则，这里我们定义了 443 端口的 tls 模式为 ISTIO_MUTUAL，表示当访问 my-nginx.mesh-external.svc.clustr.local 的 TLS 请求时执行 TLS 双向认证。最后我们定义一个 VirtualService 对象来引导流量流经 egress 网关：$ kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: direct-nginx-through-egress-gateway spec: hosts: - my-nginx.mesh-external.svc.cluster.local gateways: - istio-egressgateway - mesh # 网格内部的流量 http: - match: - gateways: - mesh port: 80 route: - destination: host: istio-egressgateway.istio-system.svc.cluster.local subset: nginx port: number: 443 weight: 100 - match: - gateways: - istio-egressgateway port: 443 route: - destination: host: my-nginx.mesh-external.svc.cluster.local port: number: 443 weight: 100 EOF上面的 VirtualService 对象定义网格内部对 my-nginx.mesh-external.svc.cluster.local 服务的访问引导至 istio-egressgateway，然后再由 istio-egressgateway 引导流量流向外部服务。添加 DestinationRule 执行双向 TLS：$ kubectl apply -n istio-system -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: originate-mtls-for-nginx spec: host: my-nginx.mesh-external.svc.cluster.local trafficPolicy: loadBalancer: simple: ROUND_ROBIN portLevelSettings: - port: number: 443 tls: mode: MUTUAL credentialName: client-credential # 这必须与之前创建的用于保存客户端证书的 Secret 相匹配 sni: my-nginx.mesh-external.svc.cluster.local EOF发送一个 HTTP 请求至 http://my-nginx.mesh-external.svc.cluster.local：$ kubectl exec "$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})" -c sleep -- curl -sS http://my-nginx.mesh-external.svc.cluster.local <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> ...检查 istio-egressgateway Pod 日志，有一行与请求相关的日志记录。如果 Istio 部署在命名空间 istio-system 中，打印日志的命令为：kubectl logs -l istio=egressgateway -n istio-system | grep 'my-nginx.mesh-external.svc.cluster.local' | grep HTTP将显示类似如下的一行：[2023-11-17T08:23:51.203Z] "GET / HTTP/1.1" 200 - via_upstream - "-" 0 615 17 16 "10.244.1.100" "curl/7.81.0-DEV" "434b5755-54da-9924-9e2a-a204b5a2124c" "my-nginx.mesh-external.svc.cluster.local" "10.244.1.106:443" outbound|443||my-nginx.mesh-external.svc.cluster.local 10.244.2.239:35198 10.244.2.239:8443 10.244.1.100:56448 my-nginx.mesh-external.svc.cluster.local -双向认证即使我们直接在网格中访问的是 HTTP 的服务，但是通过配置 Istio，我们也可以实现对外部服务的双向 TLS 认证。参考文档：https://istio.io/latest/docs/tasks/traffic-management/egress/本文转载自k8s技术圈，原文链接添加社区小助手回复“Istio”进入技术交流群

11月9日，世界互联网大会数字经济引领现代化产业体系构建论坛在浙江乌镇隆重召开。作为本届世界互联网大会规模最大、规格最高的主题分论坛，活动邀请了多国政府代表、国际组织、科研机构、企事业单位嘉宾交流分享，探索数字经济与实体经济深度融合新路径，共绘数字经济引领现代化产业体系构建的新蓝图。华为常务董事、华为云CEO张平安以“构筑核心技术新生态，共建智能世界云底座”为题发表演讲指出，我国数字经济蓬勃发展，数字技术飞速革新，正迎来构建全新核心技术体系的新机遇。华为希望携手产业伙伴、客户，在多元算力领域、AI领域、云原生核心软件领域持续突破，共建智能时代的核心技术新生态。从2014年到2023年，世界互联网大会乌镇峰会迎来十周年。张平安表示，过去十年，云计算在中国风起云涌，AI技术加快从理论走进现实，数字化成为每一家企业的转型共识。如今，以云为底座的创新生态，以大模型为代表的创新技术，正在加快重塑千行万业，为建设包容、普惠、有韧性的数字世界提供全新动能。从宏观数据看，2022年，我国数字经济总规模已突破50万亿元，占GDP比重41.5%，从2016年至2022年年均复合增速达14.2%，成为全球数字经济增长最快的地区之一。然而，在核心技术投入与研发创新方面，我国市场仍与发达经济体有较明显差距。“这也意味着，云服务、SaaS软件等相关产业在中国仍有着广阔空间，未来十年将是中国核心技术创新的黄金十年。”张平安指出，核心技术创新的关键在于生态，生态决定了数字世界的话语权，中国需要建立创新、可靠、可信、中立的技术新生态。张平安表示，面向飞速发展的智能世界，在多元算力领域、AI领域、云原生的核心软件领域，依托中国创新市场，我们有机会构建一个全新的技术生态。这需要产业界紧密携手合作，敢于突破核心技术，敢于构建创新技术生态。这个新的技术体系不仅要立足中国，更要放眼全球，能给世界一个更优选择。首先，算力是智能时代企业发展的关键生产力，构建对等的多元算力势在必行。行业分析指出，到2030年，全球通用算力需求将达到3.3 ZFLOPS，AI算力需求将达到105 ZFLOPS，二者分别是2020年的10倍和500倍。当前以CPU为中心的计算架构，必然加快走向支持多元算力的对等架构，打破输入输出瓶颈，拓宽计算带宽、降低时延、提升性能，适应海量的多样性算力需求。目前，华为正加快软、硬、边、端、云等全面融合，鲲鹏、昇腾生态已汇聚超过440万开发者，合作伙伴超过6000家，解决方案认证超过17000个，并建设72个产教融合的人才基地，持续携手业界伙伴，打造中国坚实的算力底座。其次，AI创新风起云涌，大模型“百花齐放”，AI正加快重塑千行万业。张平安表示，中国拥有千行万业的业务场景，也拥有全球最大的软件创新人群，在AI领域也有机会实现全球领先。华为从2019年开始投入AI大模型研发，坚持“AI for Industries”，华为盘古大模型要帮助行业解最难的题，做最难的事情，思考用大模型解决各行业研、产、供、销、服等环节面临的复杂难题，加快AI重塑千行万业。在数字资产方面华为联合超过30家行业头部企业，建立高质量数据联盟，用AI帮助挖掘数据资产应用价值；在开发者方面华为云提供盘古大模型研发工程套件，打造开放模型社区、大模型云学堂，帮助开发者更快实现大模型的开发落地；过去要完成一个千亿参数大模型的端到端开发准备就需要5个月，现在通过昇腾AI云服务、大模型开发套件等，开发准备工作可以缩减到1个月；在生态合作方面昇腾AI云服务已经可以接入20多个第三方优质的开源大模型，同时华为云携手数百家伙伴、客户企业，打造了超过20个行业大模型、超过400个模型应用场景。再者，云原生的核心软件和开发工具链，将成为数字时代产业创新的加速器。今年，华为陆续发布了软件代码仓、需求管理、测试管理等23款软件开发工具，打造全生命周期的软件开发生产线CodeArts；联合数十家工具软件企业，联合打造硬件开发生产线CraftArts，帮助业界持续提升研发工具的质量和效率。目前每月有20多万软、硬件开发人员正在云上使用这些开发工具。 同时，华为云分布式云数据库GaussDB，全面替代了华为内部使用了27年之久的Oracle数据库，并具备比Oracle更好的高可用、高性能、高弹性等技术优势。目前，GaussDB已经在银行、保险、证券、能源等关键基础行业得到广泛应用。在本届世界互联网大会领先科技奖颁奖典礼上，华为云GaussDB数据库更是凭借领先的技术优势，在一众申报成果中脱颖而出，成功获奖。数字生态的创新繁荣，离不开产业伙伴们的共同力量。目前，华为云全球开发者数量已超过500万人，合作伙伴42000多家，云商店SaaS应用已达10000多个，与全国110多所高校合作培养数万名专业人才，产、学、研、用深度融合，让核心技术生态行稳致远。“中国的数字经济发展和技术创新，仍然需要跨越一道道技术鸿沟，需要更加多元活力的创新生态，需要全行业携手攻坚克难。”张平安表示，华为愿与广大的客户、技术伙伴一起，笃行致远，同赴山海，携手共建智能时代的创新技术新生态。转自华为云公众号

2023年11月17日-19日，中国SaaS大会在苏州举办。在18日举行的生态之变主论坛上，华为云全球生态部总裁康宁发表“基于核心技术构筑健康可持续的新生态”主题演讲，分享华为云生态最新进展和实践，围绕大会“嬗变”主题，阐释了构筑核心技术生态，促进软件产业升级的华为云生态发展理念。康宁表示，以云为底座的创新生态，以大模型为代表的创新技术，正在加快重塑千行万业，数字化成为企业的转型共识，也为软件产业变化加速提供澎湃动力。华为云希望携手伙伴，构筑健康可持续的新生态，共同促进软件产业升级。从宏观数据看，2022年，我国数字经济总规模已突破50万亿元，占GDP比重41.5%，从2016年至2022年年均复合增速达14.2%，成为全球数字经济增长最快的地区之一。然而，在核心技术投入与研发创新方面，我国市场仍与发达经济体有较明显差距。“这也意味着，云服务、SaaS软件等相关产业在中国仍有着广阔空间，未来十年将是中国核心技术创新的黄金十年。” 康宁表示，核心技术创新的关键在于生态，生态决定了数字世界的话语权，中国需要建立创新、可靠、可信、中立的技术新生态。数字时代的百模千态加速重塑千行万业当前，人工智能已从万千碎片化的小模型时代走向“百模千态”的大模型时代。华为云基于昇腾AI云服务算力底座，已原生孵化和适配业界主流大模型，为开发者提供了完善的工具和资源，来支持大模型高效地迁移、保障模型训练的澎湃算力供应和环境的稳定可靠。康宁表示：“我们致力于打造开放、活力、创新的大模型生态，欢迎各行业的伙伴加入大模型创新，让AI重塑千行万业。”云原生的核心能力和开发工具链赋能生态加速产业创新在数字时代，为了更好地适应无处不在的云计算与智能化需求，在云上的服务将会持续的增加与增强，以数据库为代表的云原生核心软件和各种开发工具链的作用会越来越重要。康宁介绍，华为云在今年2月，陆续发布了软件代码仓、需求管理、测试管理等23款软件开发工具；在硬件领域，联合广大产业伙伴打造了硬件开发生产线CraftArts，发布云原生的原理图工具、PCB版图工具等，让电子工业的硬件开发工具连续性得到有效保障。6月，华为云发布了分布式云数据库GaussDB，将华为内部使用了27年之久的Oracle数据库，全部平滑迁移到了高斯数据库。构筑以能力为核心的华为云生态体系助力伙伴商业增长为了适应客户数智化转型和伙伴多元化合作模式的需求，华为云以构建能力为核心，不断加大对于生态伙伴的支持投入。康宁介绍，华为云的伙伴体系包括GoCloud和GrowCloud 2个合作框架：GoCloud目标是培育与发展伙伴的能力，帮助伙伴在华为云上构建丰富的解决方案与服务Offering，共同为客户创造价值；GrowCloud则帮助合作伙伴扩大客户覆盖，加速销售增长，实现商业共赢。同时今年华为云还推出了合作伙伴共拓计划Partner Customer Engagement(PCE)，让伙伴和华为云实现商机共享，共同拓宽市场空间，为客户创造价值。面向新技术的选择，软件伙伴通过与华为云技术融合，实现架构优化、成本降低、效率提升等；服务伙伴在华为云生态体系中从配合到自主，以品质服务成为客户的长期伙伴；数字化转型咨询与系统集成伙伴抓住云化，数字化的机遇，加速发展；企业数智化应用是转型发展的关键动能，作为华为云生态的核心载体，华为云云商店联接着伙伴和用户，打通企业应用供需链路。华为云结合华为多年服务行业的经验，参考业界最佳实践，打造了伙伴价值创造和变现流程，为合作伙伴在联合方案打造、上市、共销及持续运营提供全方位支持。除了体系化的流程，华为云还投入专职团队，与伙伴一起定义客户价值场景、商业及交付模式，以及持续服务的方式。康宁表示，华为云希望与伙伴打造更多有竞争力的解决方案，共同服务好客户，共创行业新价值。构建全方位出海生态助力SaaS企业全球业务部署华为云服务覆盖全球170多个国家和地区，以全球一站式、一致性体验的云服务，助力出海企业开拓海外市场。康宁表示：“我们会向伙伴开放更多本地生态资源，助力SaaS出海企业，立足本地，构建技术底座，实现稳健运营。”未来，华为云携手生态伙伴一起续写科技航海新篇章，把握企业增长的第二曲线，凌云出海，拥抱全球市场。中国SaaS大会专题讨论会11月17日下午，在中国SaaS大会举办期间，华为云与60余家业内领先SaaS企业，围绕“零售”及“出海”两个话题，举办了专题讨论会。在业务全球化趋势之下，出海逐渐成为业务增长的“必选项”。在出海专题讨论会上，华为云分享了自身布局全球经验与生态政策，与纷享销客、合合信息、来也科技等已布局海外SaaS业务的企业展开热烈讨论，共同描绘出海市场新增长的合作路径。面对当前消费者消费降级、消费需求多样化的市场挑战，围绕零售SaaS企业精细化运营，提升服务体验牵引更多商机展开讨论。智简科技、百胜软件、科脉技术、欧电云等专注零售赛道的SaaS企业表示，基于工具运营一体化等经营理念，依托大模型技术在用户增长、体验升级和产品研发等方面进行创新，可提升SaaS企业市场竞争力，促进业绩增长。

告警和日志是运维人员快速定位问题、恢复异常的主要手段。运维人员日常的工作模式往往是先接收告警信息，再根据告警信息初步判断异常的范围和影响，通过相关组件的日志定位出故障原因，进行系统恢复。因此，如何给运维人员提供简单易用的告警和日志管理平台是各个云原生平台高度关注的问题。相较传统系统，云原生场景下应用数量非常巨大，监控指标、事件、日志等运维数据更是海量的。同时，告警配置需要联通多个系统，如告警通知人的配置涉及消息通知系统、指标阈值告警规则涉及监控系统、日志关键字告警涉及日志管理系统等。这就导致云原生场景告警的配置复杂度相当高，且涉及跳转到不同系统，流程存在断点。同样，云原生场景下日志文件庞杂繁复。日志有容器标准输出日志、容器内日志、节点日志等多种类型；且日志可能分布在不同的主机上，位置不固定，从而导致日志查找困难。因此，如何帮助运维人员快速精确地查找到故障时间点的完整日志链路并清晰的呈现是日志服务所面临的关键挑战。图1 日志和告警中的挑战针对于上述云原生场景下告警和日志的问题，华为云CCE服务上线告警中心和日志中心功能，实现“一站式告警配置”、“云原生日志视图”。一站式告警配置为了让用户在极短时间内完成系统的基本告警配置，CCE服务联合AOM服务推出云原生专属告警模板，一键即可配置云原生系统的告警规则。此告警模板基于华为云日常运维经验总结提炼，内容涵盖了集群故障事件以及集群、节点、负载资源监控阈值等多方面的常见故障场景。用户只需要在CCE开启告警中心，绑定故障通知人员的邮箱或手机即可。图2 一键开启另外，告警中心还具备告警通知组配置、告警规则配置、告警查看回溯等能力，让运维人员能够一站式完成告警的配置和处理流程，完成闭环。告警中心基于华为云SMN服务提供告警通知组能力。通过配置告警通知组，能够在故障产生时根据问题触发系统的种类和级别及时通知相应的运维人员介入处理。图3 配置告警通知组告警规则可通过告警模板一键下发，涵盖集群常用的指标告警和事件告警。当然，用户也可以自由选配这些告警规则。图4 配置告警规则当告警产生时，告警通知人会及时收到告警通知，并可以通过告警中心提供的可视化界面查看和消除告警。为方便用户对已发生故障进行回溯，告警中心也同样支持查看历史已经消除的告警。图5 告警列表云原生日志视图为了契合云原生业务特征，方便运维人员快速查询日志并准确定位故障，华为云CCE服务推出日志中心功能，提供云原生视角的专属页面版式。图6 日志中心日志中心支持根据K8s资源对象，如工作负载、Pod等进行过滤筛选。同时支持K8s管理日志、审计日志、业务日志等分类展示，整体页面更加简洁，日志主体内容及关联的K8s资源等重点信息更加突出，能够让运维人员聚焦故障点日志，排除干扰。图7 多维度过滤筛选日志中心还提供了日志采集策略的配置管理能力，支持自由配置采集的K8s资源对象。另外，为了进一步降低日志的使用门槛，日志中心提供了控制面日志、审计日志和容器标准输出日志的采集配置模板，支持一键开启或关闭。图8 采集模板本期我们针对告警中心和日志中心的能力给大家进行了简单的介绍。我们非常期待这些能力能够有效地提升您的运维体验。我们将会进行持续优化。期待您的使用以及宝贵的改进意见。服务体验请访问cid:link_3相关链接cid:link_2cid:link_4云容器引擎 CCE

19日，以“创想无限”为主题的2023华为开发者大赛全球总决赛圆满落幕，紧随其后的是精彩纷呈的华为开发者年度盛典。最顶尖最酷的开发者在盛典上秀出了他们的作品，既能又能还能，真是开发者的快乐，你根本想象不到！听说有好几个项目当场就被投资人相中，赛场上的作品立马成为商业机密，那接下来的一些开发者炫酷作品展示嘛~~想下滑了解更多的朋友，也许需要先签署下保密协议。想象以后再不需要学习外语，世界各地的影片都可以在几秒内转译成你的母语，还跟原来的演员一个音色、一个语气。梦想照进现实了！来自亚太赛区的Soca.AI团队使用华为语音交互服务，将口语转换为文本，理解上下文，结合AI技术无缝将其翻译成新的语言，并搭配华为云容器引擎提升转译效率，开发出了原声语音自动翻译的语言转译系统。videovideovideovideovideovideo要保留说话人原本的声音、情感和语调对于算法和AI模型非常挑战，Soca.AI团队通过语音分割，将说话人的声音从其他声音属性中分离出来，韵律和语调也在专业配音的基础上训练与说话人无关的注释。上面这个视频就是在几秒钟内实现转译并成功输出的，看美剧不看字幕的时代终于要来到了吗？！赶紧列好想冲的观影列表吧！耕耘逐梦团队打造了一套专门针对工地场景的安全监管平台。“不知道人员具体在哪里”，“事故发生就在1秒钟”，“危险的动作和行为无法机制感知”，针对工地安全管理的核心难题，团队开始死磕。因为工地都是从当地采购设备，五花八门，每个设备都需要“手敲代码”进行集成，平均1个工地至少需要3万行代码，平均需要20-25天；随着工地数量的不断增加，服务器需要采用“人拉肩扛”的方式进行扩容；工地的摄像头大多为普通摄像头，不具备AI分析能力。后来他们发现华为云可以很好地解决所有问题，华为云资源的弹性扩容能力大大缩短了应用扩容的工作量；通过与ROMA+IoT组件的融合，将25天的集成工作量缩短至5天，不再需要长时间驻场；通过布设华为云AI边缘智能视频分析算法，实现了在不更换摄像头的前提下进行安全分析。华为云盘古大模型也更加高效地实现了对用户的自然语言交互。现在团队成功开发了劳动实名制、特种设备监管、人员定位、安全帽识别、人员越界检测等具有工地特色化的应用，创新优化了工地管理模式。为了给脑卒中患者寻求一种有效的康复方案，卓越脑康团队提出了新一代主动式外骨骼康复产品——华为云AI赋能脑机手部康复外骨骼。基于华为云AI开发生产线ModelArts和脑机接口技术，通过自研脑电采集设备采集到患者的大脑放电信号，使用AI模型解析得到患者的运动意图，最后驱动外骨骼手套带动患者手指进行康复训练。智睡芯安团队的同学为了解决室友打呼噜的问题开发出了基于昇思MindSpore框架的睡眠呼吸诊疗方案。（室友：没想到我是你的缪斯）阻塞性睡眠呼吸暂停综合征在我国约有1.76亿患者，55%的打呼噜都是由该病引起，且该病有40%的概率引发心脑血管等慢性疾病。团队与医生进行了长达2个月的方案讨论，累计标注72000张CT图像。基于华为云的云边端协调架构和AI开发生产线ModelArts，目前已经可以做到将患者的头部CT放进平台进行全自动分析，20s内即可提供给医生最直观的三维可视化结果，达到97%的预测精度，大大提升医生的检测效率和准确率。同时将患者的头部CT进行高精度分割，对其气道进行三维重建，利用反式呼吸求解，通过查看仿真气流的流动状态和数值来判断预测切除的部分是否合理，集成一个完整辅助诊断的平台。（为了室友不打呼噜自己睡个好觉也是真的很努力了！）为解决听障人士日常生活中沟通困难的问题，知音团队基于华为昇腾的“小藤”开发者套件，开发出了一款知音智能眼镜，将接收到的声音转化为信息显示在镜片上，并用摄像头识别手势，通过扬声器说出语言，以此实现完整的双向沟通。目前知音智能眼镜已经完成了8900万以上的语音转文字和2000万的文字转语音，帮助了无数的听障人士。科技应该向善，花开无声的世界也能充满温暖和声音。为了充分发挥数字化电子发票的优势，标普云团队开发了 “数票通”，针对中小企业经常有财务专业能力缺失的痛点，提供傻瓜式服务，也面向垂直行业提供个性化发票管理能力。开发者前哨站＝一位脱口秀演员马克+华为开发者DTSE专家徐毅（一看发型就知道开发能力出众的洗脑专家技术布道师）+中关村软件园投资管理公司的张锋（钱多又渣、不主动也不拒绝的渣男VC）互相吐槽，说的都是大实话，送的都是纯干货。最后，揭秘本届华为开发者大赛获奖结果。本届大赛开设云底座和产业两大赛道，覆盖中国、亚太、拉美、欧洲、土耳其等区域，共吸引了全球30多个国家和地区、19000多名开发者、3000多支团队报名参赛。在中国赛区的企业赛道，“天图万境”团队凭借“人工智能AI感知视听空间计算技术”作品一举夺魁，荣获银奖的队伍为“深圳前海粤十信息技术有限公司”和 “北京聚力维度科技有限公司”，荣获铜奖的队伍为 “国蓝中天”“Motphys”“耕耘逐梦”，荣获创新奖的队伍是“万商云集”和 “云天励飞”。中国赛区企业赛道金奖在中国赛区的学生赛道，“IoT智慧铝电解”团队凭借“基于华为云IoT的铝电解能耗监测管理系统”作品荣获金奖，荣获银奖的队伍为“质感队”和 “卓越脑康”，荣获铜奖的队伍为 “一把火”“融创眼援”“智睡芯安”，荣获创新奖的队伍是“郁云守护”和 “郑信智眼队”。中国赛区学生赛道金奖在亚太赛区，“nozama”队伍凭借“Magik（虚实游戏玩具）”作品荣获金奖，荣获银奖的队伍为“DecentraRating”和“Netizen”，荣获铜奖的队伍为 “HeyHi”“SmartAM”“IC”，荣获创新奖的队伍是“Soca.AI”“Aye-Aye”“CyberWhiz”。亚太赛区金奖除了丰厚的奖金外，华为云同步为每支参赛队伍提供了无门槛云资源券、优质课程、沙箱实验和华为云开发者认证券，并通过华为云学堂持续培养和赋能开发者。同时，优秀参赛者还能获得华为云云商店KooGallery、沃土云创计划、初创计划等提供的商业成功扶持。此外，大赛额外设置人才招聘绿色通道，如华为人才市场岗位库，人才双选会门票等资源。一直以来，华为云致力于构建以开发者为核心的、开放共赢的生态体系。目前，华为云全球开发者数量已超过500万人，合作伙伴42000多家，云商店SaaS应用已达10000多个。华为云全球生态部总裁康宁在致辞中表示：“全球数字经济蓬勃发展，以云为底座的创新生态，以大模型为代表的创新技术，正在加快重塑千行万业。开发者作为创新技术生态体系的核心力量，也迎来了高速发展的新机遇。华为将在多元算力领域、AI领域、云原生核心软件领域持续突破，构筑核心技术新生态，与开发者一路同行，引领数字未来。”华为云CTO张宇昕表示：“开发者是用代码改变世界的人，每个开发者都在引领数字时代，开创智能世界，每个开发者都了不起！华为公司希望提供连接开发者、连接企业、连接投资人的舞台，让更多开发者投入到软件开发、投入到创造新世界的洪流当中；让更多企业开发者创新产品、创造价值、加速企业发展；让更多的资金发现创新机会，创造商业价值。华为云希望和开发者一起，用创新的技术和产品来推动世界进步，创造更加美好的智能世界！”华为公司战略与产业发展副总裁肖然在致辞中阐述了华为在根技术领域的研发投入成果，以及全面助力开发者成功的决心和行动。他表示：“未来，华为将持续加大技术投入和创新，并通过在供应链、标准和人才等领域开放合作、包容发展，与客户、伙伴、标准组织和开发者一起推动整个产业的进步，为各行各业的数字化转型提供技术保障和价值驱动，以推动数字经济的高质量发展。”作为华为ICT领域的顶级赛事，华为开发者大赛旨在面向全球开发者全面开放华为各产业领域的技术成果，鼓励开发者发挥想象力和创新精神，用ICT技术解决实际问题、创造无限价值，与华为一起引领数字未来、共建智能世界。很惊喜能与这么多有想法、有技术、有勇气的开发者相遇华为开发者大赛，我们明年再见！

【中国，东莞，2023年11月19日】今天，以“创想无限”为主题的2023华为开发者大赛全球总决赛及颁奖典礼在华为松山湖基地圆满落幕。本届大赛开设云底座和产业两大赛道，覆盖中国以及亚太、拉美、欧洲、土耳其等区域，吸引了来自全球30多个国家和地区的19000多名开发者、3000多支团队报名参赛。 在颁奖典礼上，华为颁发了3个金奖、6个银奖、9个铜奖、7个创新奖等超过25个奖项。全球总决赛大合照本届大赛自启动报名以来，备受全球各领域开发者关注，涌现了众多具有丰富想象力和创造力的优秀作品，包括应用华为云盘古大模型和IoT等能力的智慧工地管控平台、基于华为云AI开发生产线ModelArts和端云协同开发的新一代主动式外骨骼康复产品、将华为昇腾和AI技术应用于为特殊人士打造的无障碍智能交流应用、通过华为昇思MindSpore和AI能力打造的阻塞性睡眠呼吸暂停综合征解决方案、以及通过AI技术实现原声语音自动翻译的语言转译系统等。参赛作品由评委团从技术领先性、方案创新性、商业前景等维度进行综合评审，最终评选出获奖作品。在中国赛区的企业赛道，“天图万境”团队凭借“人工智能AI感知视听空间计算技术”作品一举夺魁，荣获银奖的队伍为“深圳前海粤十信息技术有限公司”和“北京聚力维度科技有限公司”，荣获铜奖的队伍为“国蓝中天”“Motphys”“耕耘逐梦”，荣获创新奖的队伍是“万商云集”和 “云天励飞”。中国赛区企业赛道金奖在中国赛区的学生赛道，“IoT智慧铝电解”团队凭借“基于华为云IoT的铝电解能耗监测管理系统”作品荣获金奖，荣获银奖的队伍为“质感队”和 “卓越脑康”，荣获铜奖的队伍为 “一把火”“融创眼援”“智睡芯安”，荣获创新奖的队伍是“郁云守护”和 “郑信智眼队”。中国赛区学生赛道金奖在亚太赛区，“nozama”队伍凭借“Magik（虚实游戏玩具）”作品荣获金奖，荣获银奖的队伍为“DecentraRating”和“Netizen”，荣获铜奖的队伍为 “HeyHi”“SmartAM”“IC”，荣获创新奖的队伍是“Soca.AI”“Aye-Aye”“CyberWhiz”。亚太赛区金奖华为云全球生态部总裁康宁、华为云CTO张宇昕、华为公司战略与产业发展副总裁肖然等嘉宾出席了总决赛颁奖典礼并为获奖队伍颁奖。康宁在致辞中表示：“全球数字经济蓬勃发展，以云为底座的创新生态，以大模型为代表的创新技术，正在加快重塑千行万业。开发者作为创新技术生态体系的核心力量，也迎来了高速发展的新机遇。华为将在多元算力领域、AI领域、云原生核心软件领域持续突破，构筑核心技术新生态，与开发者一路同行，引领数字未来。”张宇昕表示：“开发者是用代码改变世界的人，每个开发者都在引领数字时代，开创智能世界，每个开发者都了不起！华为公司希望提供连接开发者、连接企业、连接投资人的舞台，让更多开发者投入到软件开发、投入到创造新世界的洪流当中；让更多企业开发者创新产品、创造价值、加速企业发展；让更多的资金发现创新机会，创造商业价值。华为云希望和开发者一起，用创新的技术和产品来推动世界进步，创造更加美好的智能世界！”肖然在致辞中阐述了华为在根技术领域的研发投入成果，以及全面助力开发者成功的决心和行动。他表示：“未来，华为将持续加大技术投入和创新，并通过在供应链、标准和人才等领域开放合作、包容发展，与客户、伙伴、标准组织和开发者一起推动整个产业的进步，为各行各业的数字化转型提供技术保障和价值驱动，以推动数字经济的高质量发展。”作为华为ICT领域的顶级赛事，华为开发者大赛旨在面向全球开发者全面开放华为各产业领域的技术成果，鼓励开发者发挥想象力和创新精神，用ICT技术解决实际问题、创造无限价值，与华为一起引领数字未来、共建智能世界。本届大赛总奖金达500万元，除了丰厚的奖金外，华为云同步为每支参赛队伍提供的无门槛云资源券，提供优质课程、沙箱实验等丰富的学习资源扶持和华为云开发者认证券，并通过华为云学堂持续培养和赋能开发者。同时，优秀参赛者还能获得华为云云商店KooGallery、沃土云创计划、初创计划等提供的商业成功扶持。此外，大赛额外设置人才招聘绿色通道，如华为人才市场岗位库，人才双选会门票等资源。一直以来，华为云致力于构建以开发者为核心的、开放共赢的生态体系。目前，华为云全球开发者数量已超过500万人，合作伙伴42000多家，云商店SaaS应用已达10000多个，与全国110多所高校合作培养数万名专业人才，产、学、研、用深度融合，让核心技术生态行稳致远。面向飞速发展的大模型时代，在开发者方面，华为云提供盘古大模型研发工程套件，打造开放模型社区、大模型云学堂，帮助开发者更快实现大模型的开发落地。华为云希望广大开发者基于华为的根技术，利用云上的澎湃算力和盘古大模型的强大能力，共同构建起“百模千态”的繁荣生态。面向未来，华为将加快软、硬、边、端、云等全面融合，协同华为云、鲲鹏、昇腾、鸿蒙等开发生态，持续加大投入研发创新，与全球各领域开发者一起用技术推动世界进步。

作者：华为云云原生团队随着云原生技术在越来越多的企业和组织中的大规模落地，如何高效、可靠地管理大规模资源池以应对不断增长的业务挑战成为了当下云原生技术的关键挑战。在过去的很长一段时间内，不同厂商尝试通过扩展单集群的规模来扩展资源池。然而，Kubernetes社区很早就发布了大规模集群的最佳实践，其中包括几项关键数据：节点数不超过5k，Pod数不超过150k，单个节点的Pod数量不超过110 k等。这侧面说明了支持超大规模的集群不是Kubernetes社区主要努力的方向。同时，以单集群的方式扩展资源池通常需要定制Kubernetes的原生组件，这在增加了架构复杂度的同时也带来了不少弊端：（1）集群运维复杂度急剧增加。（2）与社区演进方向相左，后续的维护成本上升，升级路径不清晰。（3）单集群本质上属于单个故障域，集群故障时将导致无法控制爆炸半径。而多集群技术能在不侵入修改Kubernetes单集群的基础上横向扩展资源池的规模，在扩展资源池的同时降低了企业的运维管理等成本。此外，多集群系统天然支持多故障域，符合多数业务场景，如多地数据中心、CDN就近提供服务等。Karmada作为CNCF首个多云容器编排项目，提供了包括Kubernetes原生API支持、多层级高可用部署、多集群故障迁移、多集群应用自动伸缩、多集群服务发现等关键特性，致力于让用户轻松管理无限可伸缩的资源池，为企业提供从单集群到多云架构的平滑演进方案。随着以Karmada为代表的多集群架构在企业的逐步落地，大规模场景下多集群系统的性能问题往往是用户的核心关注点之一。本文将围绕以下几个问题，结合Karmada社区对大规模场景的思考，揭示Karmada稳定支持100个大规模集群、管理超过50万个节点和200万个Pod背后的原理。（1） 如何衡量一个多集群系统资源池的维度与阈值？（2） 对多集群系统进行大规模环境的压测时，我们需要观测哪些指标？（3） Karmada是如何支撑100个大规模K8s集群并纳管海量应用的？（4） 在Karmada的生产落地过程中，有哪些最佳实践和参数优化手段可以参考？▎多集群系统资源池的维度与阈值当前，业界对于多云资源池的Scalability尚未达成统一标准，为此，Karmada社区结合企业用户的实践，率先对这一问题进行了深入探索。一个多集群系统资源池规模不单指集群数量，实际上它包含很多维度的测量标准，在不考虑其他维度的情况下只考虑集群数量是毫无意义的。在若干因素中，社区按照优先级将其描述为以下三个维度：（1） 集群数量。集群数量是衡量一个多集群系统资源池规模和承载能力最直接且最重要的维度。（2） 资源（API对象）数量。对于多集群系统的控制面来说，存储并不是无限的，在控制面创建的资源对象的数量和总体大小受限于系统控制面的存储，也是制约多集群系统资源池规模的重要维度。这里的资源对象不仅指下发到成员集群的资源模板，而且还包括集群的调度策略、多集群服务等资源。（3） 集群规模。集群规模是衡量一个多集群系统资源池规模不可忽视的维度。一方面，集群数量相等的情况下，单个集群的规模越大，整个多集群系统的资源池越大。另一方面，多集群系统的上层能力依赖系统对集群的资源画像，例如在多集群应用的调度过程中，集群资源是不可或缺的一个因素。综上所述，单集群的规模与整个多集群系统息息相关，但单集群的规模同样不是制约多集群系统的限制因素。用户可以通过优化原生的Kubernetes组件的方式来提升单集群的集群规模，达到扩大整个多集群系统的资源池的目的，但这不是衡量多集群系统性能的关注点。在集群的标准配置中，Node与Pod毫无疑问是其中最重要的两个资源，Node是计算、存储等资源的最小载体，而Pod数量则代表着一个集群的应用承载能力。▎大规模场景下多集群系统的性能指标在多集群系统的大规模落地进程中，如何衡量多集群联邦的服务质量是一个不可避免的问题。在参考了Kubernetes社区的SLI(Service Level Indicator)/SLO(Service Level Objectives)和多集群系统的落地应用后，Karmada社区定义了以下SLI/SLO来衡量大规模场景下多集群联邦的服务质量。API Call LatencyStatusSLISLOOfficial最近5min的单个Object Mutating API P99 时延除聚合API和CRD外，P99 <= 1sOfficial最近5min的non-streaming read-only P99 API时延除聚合API和CRD外P99 :(a) <= 1s if scope=resource (b) <= 30s otherwise (if scope=namespace or scope=cluster)注：API调用时延仍然是衡量基于Kubernetes的多集群系统服务质量的关键指标。Karmada兼容Kubernetes原生API，用户除了使用原生API创建K8s的资源模板外，也可以使用Karmada自有API来创建多集群策略和访问跨集群的资源。Resource Distribution LatencyStatusSLISLOOfficial用户在联邦控制面提交资源模板和下发策略后到资源在成员集群上被创建的P99时延，不考虑控制面与成员集群之间的网络波动P99 <= 2sCluster Registration LatencyStatusSLISLOWIP集群从接入联邦控制面到状态能被控制面正常收集的P99时延，不考虑控制面与成员集群之间的网络波动TBD注：集群注册时延是从集群注册到控制面到集群在联邦侧可用的时延，它反映了控制面接入集群以及管理集群的生命周期的性能。但它在某种程度上取决于控制面如何收集成员集群的状态。因此，我们不会对这个指标进行强制的限制。Resource UsageStatusSLISLOWIP在接入一定数量的集群后集群联邦维持其正常工作所必需的资源使用量TBD注：资源使用量是多集群系统中非常重要的指标，我们希望在纳管海量的集群和资源的同时消耗尽量少的系统资源。但由于不同的多集群系统提供的上层服务不同，因此对于不同的系统，其对资源的要求也会不同。因此，我们不会对这个指标进行强制的限制。▎Karmada百倍集群规模基础设施揭秘Karmada社区在结合对上述两个问题的思考以及用户在落地过程中的反馈后，测试了Karmada同时管理100个5K节点和2w Pod的Kubernetes集群的场景。本文不详细描述具体的测试环境信息与测试过程，而是侧重于对测试结果进行分析在整个测试过程中，API调用时延均符合上述定义的SLI/SLO。图一：只读API（cluster-scope）调用时延图二：只读API(namespace-scope)调用时延图三：只读API(resource-scope)调用时延图四：Mutating API调用时延Karmada在百倍集群规模下，仍能做到快速的API响应，这取决于Karmada独特的多云控制面架构。事实上，Karmada在架构设计之初就采用了关注点分离的设计理念，使用Kubernetes原生API来表达集群联邦资源模板，使用可复用的策略API来表达多集群的管理策略，同时控制面的资源模板作为应用的模板，不会在控制面生成具体的Pod。不同集群的应用在控制面的映射（Work对象）通过命名空间来进行安全隔离。完整的API工作流如下图所示。如此设计，不仅可以让Karmada能够轻松集成Kubernetes的生态, 同时也大大减少了控制面的资源数量和承载压力。基于此，控制面的资源数量不取决于集群的数量，而是取决于多集群应用的数量。此外，Karmada的架构极具简洁性和扩展性。karmada-apiserver作为控制面的入口与kube-apiserver类似，即使是在百倍集群规模下，Karmada仍能保持快速API响应。Karmada支持通过命令行快速接入集群，以及集群的全生命周期管理。Karmada会实时采集集群心跳和状态，其中集群状态包括集群版本、支持的API列表、集群健康状态以及集群资源使用量等。其中，Karmada会基于集群资源使用量对成员集群进行建模，这样调度器可以更好地为应用选择资源足够的目标集群。在这种情况下，集群注册时延与集群的规模息息相关。下表展示了加入一个5,000节点的集群直至它可用所需的时延。你可以通过关闭集群资源建模来使集群注册时延与集群的大小无关，在这种情况下，集群注册时延这个指标将小于2s。Cluster Registration Latency:metricP50(ms)P90(ms)P99(ms)SLOcluster_register535661256904N/AKarmada支持多模式的集群统一接入，在Push模式下，Karmada控制面直连成员集群的kube-apiserver，而在Pull模式下，Karmada将在成员集群中安装agent组件，并委托任务给它。因此Push模式多用于公有云的K8s集群，需要暴露APIServer在公网中，而Pull模式多用于私有云的K8s集群。下表展示了Karmada在不同模式下下发一个应用到成员集群所需的时延。Resource Distribution Latency:MetricP50(ms)P90(ms)P99(ms)SLOcluster_schedule121532N/Aresource_distribution(Push)70689912982000resource_distribution(Pull)6128819892000结论：我们容易得出，不论是Push模式还是Pull模式，Karmada都能高效地将资源下发到成员集群中。在Karmada演进的数个版本中，大规模场景下使用Karmada管理多云应用的资源消耗一直是用户比较关注的问题。Karmada社区做了许多工作来减少Karmada管理大型集群的资源使用量，比如我们优化了Informer的缓存，剔除了资源无关的节点、Pod元数据；减少了控制器内不必要的类型转换等等。相较于1.2版本，当前Karmada在大规模集群场景下减少了85%的内存消耗和32%的CPU消耗。下图展示了不同模式下Karmada控制面的资源消耗情况。Push模式：Pull模式：总的来说，系统消耗的资源在一个可控制面的范围，其中Pull模式在内存使用上有明显的优势，而在其他资源上相差的不大。▎Karmada大规模环境下的最佳实践Karmada支持性能参数的可配置化，用户可以通过调整组件的参数来调整同一时间段内并发处理Karmada内部对象的数量、系统的吞吐量等以优化性能。同时Karmada在不同模式下的性能瓶颈并不相同，以下着重对此进行分析。在Push模式中，控制面的资源消耗主要集中在karmada-controller-manager（约70%），而Karmada控制面基座（etcd/karmada-apiserver）的压力不大。结合karmada-apiserver的qps以及karmada-etcd的请求时延我们可以看出karmada-apiserver的请求量保持在一个较低的水平。在Push模式中，绝大多数的请求来自karmada-controller-manager。因此我们可以通过调整karmada-controller-manager的--concurrent-work-syncs来调整同一时间段并发work的数量来提升应用下发的速度，也可以配置--kube-api-qps和--kube-api-burst这两个参数来控制Karmada控制面的整体流控。在Pull模式中，控制面的资源消耗主要集中在karmada-apiserver，而不是karmada-controller-manager。结合karmada-apiserver的qps以及karmada-etcd的请求时延我们可以看出karmada-apiserver的请求量保持在一个较高的水平。在Pull模式中，每个成员集群的karmada-agent需要维持一条与karmada-apiserver通信的长连接。我们很容易得出：在下发应用至所有集群的过程中请求总量是karmada-agent中配置的N倍(N=#Num of clusters)。因此，在大规模Pull模式集群的场景下，Pull模式在资源下发/状态收集方面有更好的性能，但同时需要考虑控制面的抗压能力以及各个karmada-agent和控制面的整体流控。当前，Karmada提供了集群资源模型的能力来基于集群空闲资源做调度决策。在资源建模的过程中，它会收集所有集群的节点与Pod的信息。这在大规模场景下会有一定的内存消耗。如果用户不使用这个能力，用户可以关闭集群资源建模来进一步减少资源消耗。▎总结根据上述测试结果分析，Karmada可以稳定支持100个大规模集群，管理超过50万个节点和200万个Pod。在Karmada落地进程中，用户可以根据使用场景选择不同的部署模式，通过参数调优等手段来提升整个多集群系统的性能。受限于测试环境和测试工具，上述测试尚未测试到Karmada多集群系统的上限，同时多集群系统的分析理论以及测试方法仍处于方兴未艾的阶段，下一步我们将继续优化多集群系统的测试工具，系统性地整理测试方法，以覆盖更大的规模和更多的典型场景。添加小助手微信k8s2222，进入云原生交流群

在 KubeCon + CloudNativeCon North America 2022 ，ING集团发表了《Efficient Scheduling Of High Performance Batch Computing For Analytics Workloads With Volcano - Krzysztof Adamski & Tinco Boekestijn, ING》主题演讲，重点介绍了云原生批量计算项目Volcano如何在数据管理平台中为大数据分析作业提供高性能调度工作。详情参见：KubeCon + CloudNativeCon North America ▎ING背景介绍ING集团（荷兰语：Internationale Nederlanden Groep），亦名荷兰国际集团，是一个国际金融服务私营企业，成立于1991年，由荷兰最大的保险公司Nationale-Nederlanden，与荷兰的第三大银行NMB PostBank Group合并而成。ING集团的服务遍及全球40多个国家，核心业务是银行、保险及资产管理等。ING集团的全球职员大约56,000人，顾客5320万人，包括自然人、家庭，企业、政府及其他等，例如基金组织。务背▎业务背景介绍在银行行业有许多法规和限制，如：监管要求在全球范围内各不相同、数据孤岛-全局和本地限制、数据安全、合规创新等，想要快速引入新技术不是一件容易的事情，为此，ING布局符合自身产业的DAP平台（Data Analytics Platform），为全球50%的ING员工提供安全的、自助的端到端分析能力，帮助员工在数据平台之上构建并解决业务问题。2013年开始我们有了数据平台的概念，2018年通过引入云原生技术打造新一代基础设施平台，从那时起，平台需求有了稳定的增长，采用率也在持续提升，目前数据索引平台上的项目已超过400个。我们所构建的平台目标是在高度安全的自助服务平台中完成所有分析需求，并且具备以下特点：开源工具模型强大的计算能力严格的安全和合规措施所有的分析集中在同一个平台满足全球和本地需求▎挑战与方案目前我们在由传统的Hadoop平台向Kubernetes过渡，但是对于作业管理和多框架支持方面还存在一些挑战，如下：1.Job的管理a.Pod级调度，无法感知上层应用b.缺乏细粒度的生命周期管理c.缺乏任务依赖关系，作业依赖关系2.调度a.缺少基于作业的调度，如：排序、优先级、抢占、公平调度、资源预定等b.缺少足够的高级调度算法，如：CPU拓扑、任务拓扑、IO-Awareness，回填等c.缺少对作业、队列、命名空间之间资源共享机制的支持3.多框架支持a.对Tensorflow、Pytorch等框架的支持不足b.对每个框架部署（资源规划、共享）等管理比较复杂利用Kubernetes来管理应用服务（无状态应用、甚至是有状态应用）是非常方便的，但是对于批量计算任务的调度管理不如yarn友好，同样yarn也存在一些限制，比如对新框架的支持不够完善，比如TensorFlow、Pytorch等，为此，我们也在寻找新的解决方案。▍Kubernetes + Hadoop在我们之前的集群管理上，会把Hadoop和Kubernetes的调度分开，基本上所有的spark作业都会运行在Hadoop集群中，其他的一些任务和算法会运行在Kubernetes集群，我们的目标是希望所有的任务全部运行在Kubernetes集群，这样管理起来会更简单。Kubernetes和YARN共同工作时，由于Kubernetes和Hadoop资源是静态划分的，在正常办公时间，Hadoop应用和Kubernetes各自使用自身分配资源，即便spark任务压力大也无法借用更多资源。夜晚时间，集群中仅有批处理任务，Kubernetes资源全部空闲，却无法分配给Hadoop进行有效利用，对于调度平台来讲，这不是一种最佳的资源分配方式。▍Kubernetes with Volcano使用Kubernetes管理整个集群，通过Volcano进行spark任务调度，此时不需要再对资源做静态划分，集群资源可根据Pod、Batch、Interactive任务的优先级、资源压力等进行动态调整，集群整体资源利用率得到极大提升。比如在正常办公时间内，常规服务应用资源空闲的情况下，Batch和Interactive应用资源需求增多时，可以暂时借用常规服务的资源；在假期和夜晚休息时，Batch业务可以使用集群所有资源进行数据计算，集群资源利用率得到极大提升。比如在正常办公时间内，常规服务应用资源空闲的情况下，Batch和Interactive应用资源需求增多时，可以暂时借用常规服务的资源；在假期和夜晚休息时，Batch业务可以使用集群所有资源进行数据计算，集群资源利用率得到极大提升。Volcano是专为Kubernetes而生的批处理调度引擎，其提供了以下能力：加权优先级的作业队列如果集群具有备用容量，可提交超过队列资源限制的任务当更多的pod被调度时，具备抢占能力丰富可配置的工作负载调度策略     5.兼容YARN的调度能力Volcano的引入，补齐了Kubernetes平台对批处理作业的调度管理能力，并且自Apache Spark 3.3版本以来，Volcano被作为Spark on Kubernetes的默认batch调度器，安装使用更方便。业务常用特性▍冗余与局部亲和Volcano保留Kubernetes中pod级别的亲和性反亲和性策略配置，并增加了task级别的亲和性和反亲和性策略。▍DRF（Dominant Resource Fairness）调度DRF调度算法的全称是Dominant Resource Fairness，是基于容器组Domaint Resource的调度算法。volcano-scheduler观察每个Job请求的主导资源，并将其作为对集群资源使用的一种度量，根据Job的主导资源，计算Job的share值，在调度的过程中，具有较低share值的Job将具有更高的调度优先级。比如集群资源总量为CPU：18C，Memory：72GB，两个用户分别是User1和User2，每个User分配1个队列，在提交作业时会根据主导资源计算job的调度优先级。User1: CPU share值为 6/18=0.33，Memory share值为 24 / 72 = 0.33，最终share值为0.33User2：CPU share值为 12/18=0.67，Memory share值为 24 / 72 = 0.33，最终share值为0.67DRF策略在任务调度时，优先分配share值较低的Job，即User1所申请的资源。集群内队列资源可以通过配置权重值进行划分，但是当本队列提交任务超出队列分配的资源，并且其他队列存在资源空闲时，可以进行队列间资源共享。即User2在使用完本队列CPU资源后，可以使用User1队列内的空闲CPU资源。当User1队列提交新任务需要CPU资源时，将会触发抢占动作，回收User1被其他队列借用的资源。▍避免资源匮乏在使用过程中，需要避免批量计算任务与自有服务出现资源抢占与冲突的问题。比如：我们集群中有两个可用节点，集群中需要部署一个统一的服务层对外提供服务，比如Presto，或者类似Alluxio的缓存服务。但是在批量计算调度时，集群的资源空间有可能全部被占用，我们将无法完成自有服务的部署或升级，为此我们增加了空间可用系数相关配置，为集群预留一些备用空间，用于自有服务的部署使用。▍DRF 仪表盘我们根据Volcano的监控数据做了一个drf调度的仪表盘，在不同层次显示更细粒度的调度信息。在业务集群中，我们有一个队列存放交互式用户的任务，另有队列存放平台运行的所有重大项目的计算任务，我们可以为重大项目队列提供一定的资源倾斜，但是此时对交互式用户的任务将不会太友好。目前我们正在考虑增加集群高峰时段展示的功能，为用户提供更多的集群使用状态和压力等信息，在自助服务平台用户视角来看，用户按照集群的繁忙程度选择自己任务的开始时间，这样可以避免后台复杂的配置就可以获得高性能的运算体验。总结Volcano对批处理任务调度做了很好的抽象，使我们在Kubernetes平台能够获得更高的调度性能，后面我们也会将开发的功能逐步回合社区，比如：DRF Dashboard、在每个节点添加空闲空间、自动队列管理、更多的Prometheus监控指标、Grafana仪表盘更新、kube-state-metrics更新和集群角色限制等。Volcano社区技术交流地址Volcano官网：https://volcano.shGitHub : cid:link_0每周例会： https://zoom.us/j/91804791393添加社区小助手k8s2222回复“Volcano”进入技术交流群

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 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 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)

作者：华为云云原生团队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，进入云原生交流群