背景介绍  当今社会正处在一个技术飞速发展、机器人与人工智能深入应用于工业领域的时代。在物流、制造和零售等领域，自动导引车（AGV）已经成为高效生产的关键工具，正在全球范围内迅速发展并得到广泛应用。2022年，我国 AGV 销量为93000台，同比增长29.2%；销售规模为185亿元，同比增长46.8%；海外销售规模为36亿，同比增长44%。AGV 系统中的无人驾驶技术，不仅可以提高生产效率，减少人工操作失误的概率，还可以在复杂和危险的环境下保障操作人员的安全。图 1 定制化接口与统一接口下，工厂调度系统架构图尽管 AGV 技术被广泛应用，却缺乏调度系统与 AGV 之间的统一接入协议。图1(a)展示了单个工厂部署不用厂家 AGV 的软件架构图，其中 MES/WMS/ERP 代表上层业务系统，RCS 代表 AGV 调度系统或云端控制平台。由于 AGV 与 RCS 之间的接口是定制化且封闭的，因此 AGV 与 RCS 的厂家属于强耦合关系，即厂家1的 RCS 无法调度厂家2的 AGV。因此对于工厂用户来讲，为了保证不同厂家的机器人安全工作，必须划定交管区域。在同一个交管区内，同一时刻只允许同一厂家的机器人进入，显著降低了任务的执行效率和 AGV 的利用效率。因此，制定一套全面、深入、适用各种环境和物流领域的调度系统与 AGV 的协议，对于统一调度系统与设备之间对接，提升 AGV 的效率、稳定性和安全性至关重要。统一的协议标准不仅明确 AGV 供应方的责任，同时也为 AGV 需求方提供保障。图 1(b)展示了统一接口下的软件架构图，可以看到，RCS 与 AGV 之间不再存在耦合关系。总结来讲，统一接口相比于定制化的接口存在以下优势：安全性高：所有厂商的 AGV 被 RCS 当作白盒集中处理，从源头杜绝碰撞，保障安全；调度效率高：同一场地无需划定交管区，AGV 也无需在“红绿灯”前长时间等待；业务连续性强：终端用户的采购方案更加灵活，无需被单个 AGV 供应商绑定；部署运维成本低：单 RCS 部署的模式，显著降低计算资源和运维人员的成本；扩展性强：支持不同厂家的新旧设备共存，用户可以按需引入新的 AGV；为此，华为联合中外运、顺丰、龙岩烟草、海康、海柔、蓝芯、斯坦德、镭神、边缘计算产业联盟、中国物流与采购联合会等30+伙伴共同起草了《云端控制平台与物流自动导引车通用接口指南》，旨在将相关的经验贡献给行业，促进我国机器人行业的蓬勃发展。  协议内容  ▍内容简介该文件规定了 AGV 与云端控制平台的接口模型、客户端通信安全认证、通信协议结构，以及控制、传输流程接口的技术要求和检验规则。适用于物流、仓储、制造业等领域的物流自动导引车实现云端控制的系统接口设计、开发、检验等。图 2 云端控制平台与AGV报文交互示意图图 2 展示了云端控制平台与 AGV 的交互流程图，整体分成以下几步：AGV 在初始化完成后，向云端控制平台发起接入申请，可选普通模式接入和安全模式接入。在普通模式中，后续报文将直接发送至对端。在安全模式中， AGV 与云端控制平台将协商会话密钥，且后续报文以密文的形式发送。AGV 向云端控制平台发起注册请求。注册成功后，将会周期性的上报自身状态；云端控制平台配置 AGV 的全局信息，如状态上报周期、告警参数等；AGV 周期性地向云端控制平台上报自身状态，并与云端控制平台保持心跳；云端控制平台根据上层业务系统输入，下发每个 AGV 的控制报文，驱动 AGV 运动；AGV 可以根据需求向云端控制平台申请安全空间，以完成自主运动，如动态绕障。▍协议亮点图 3 协议亮点信息安全：在普通接入模式的基础上，新增了安全加密模式。AGV 与云端控制平台通过 SM2 密钥交换协议协商会话密钥，然后使用该密钥对传输的报文进行 SM4 分组密码算法进行加密后，利用 SM2 数字签名算法生成签名，再对密文和签名进行传输，从而保证整个通信过程的安全；多地图管理：为满足 AGV 跨楼层和跨楼栋搬运的需求，协议规定了 RCS 和 AGV 的地图切换流程。同时指明了 AGV 在同一场地下，在 SLAM 和二维码导航之间的切换流程；双向路径规划：协议不仅规定了 RCS 规划的路径下发给 AGV 的流程，同时支持车体在极端环境下自主规划且平台授权的轨迹形式方法，如临时性避障；通信数据：采用二进制报文，显著降低通讯的数据量，减轻了对网络的依赖。同时保留多个预留字段，便于扩展和定制化实现。▍行业推广 协议的蓬勃发展离不开行业的应用和推广。KubeEdge 是边缘计算领域的开源平台，构建在 Kubernetes 之上，为网络、应用部署和云端与边缘之间的数据同步提供基础设施的支持，其目标和应用范围与当前协议的宗旨十分契合。因此 KubeEdge 将作为协议推广的重要阵地，其功能包括但不限于文档展示、协议内容详细解读、协议代码参考实现和端到端调度系统实现等，为了广大厂商和终端用户提供了良好的交流平台。▍相关链接仓库地址：cid:link_0更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群

作者：达益鑫 |南开大学，刘家伟、吴锟 |DaoCloud，王杰章 |华为云▍特性研发背景以及原理KubeEdge EdgeMesh 边缘 CNI 特性针对于边缘容器网络复杂异构环境提供与云上一致的容器网络体验，包括：1. 云边统一的容器网络资源管理分配2.基于分布式中继及穿透能力的 PodIP 级别跨子网流量转发服务特性开发背景EdgeMesh 致力于研究和解决边缘计算场景下网络连通、服务协同、流量治理等相关的一系列问题，其中在异构复杂的边缘网络环境内，不同物理区域的容器在面对动态变迁的网络环境以及短生命周期且跳跃变迁的服务位置，一部分服务可能需要使用 PodIP 进行跨网段通信，而主流的 CNI 方案主要针对于云上稳定且集成式的网络环境，并不支持跨子网流量的转发，致使这些 CNI 方案并不能够很好地适应边缘复杂异构的环境，最终导致容器即便在同一个集群内却没有享用一个平面的网络通信服务。针对这个需求，EdgeMesh 进行逐步的优化。首先实现的是网络底层的中继以及穿透服务功能开发，即 EdgeMesh 高可用特性。在分布式网络场景当中，该特性能够为节点提供基于 Service 的中继流量以及网络穿透服务，但还没有完全支持对 PodIP 层次流量的转发和穿透能力。换句话说在云边混合的场景当中 ，EdgeMesh 能够为跨网段的 Service 流量提供穿透服务，但并没有涉足到容器网络的资源管理和 IP 层的连通性功能，仍旧依赖于集群原本的 CNI 方案。这个局限性导致 EdgeMesh 无法为更加底层的网络 IP 流量提供服务，意味着 EdgeMesh 并不能够完全覆盖混合云边的场景需求，对于那些需要穿透和中继服务的 PodIP 流量，老版本的 EdgeMesh 爱莫能助。那么为什么主流的 CNI 方案无法兼容边缘环境，EdgeMesh 又是如何理解这个需求的呢？关键问题在于主流的 CNI 方案大多建立于至少三层可通的环境要求之下，具体来说 CNI 自身管理创建网络资源的时候，并不能够感知底层网络的状态，其管理能力高度依赖于 Kubernetes 系统提供的 Node IP 地址，而这个地址的连通性是由底层的网络设备来维持的，如果宿主机不能通过该 Node IP 访问到目标，那么容器网络的虚拟 IP 就更没有办法联通了，原理也将在下文详述。这也意味着 Kubernetes 系统所给的 Node IP 在边缘这样底层网络并不稳定的环境下无法保障稳定的底层通信服务。EdgeMesh 基于上述理解，对这个需求进行细化的分析：边缘网络拓扑结构变动性强，且物理隔离场景较多，致使容器网络环境难以呈现出云上那样稳定的底层设施特征，比如边缘环境中自动驾驶场景或者是快递运输场景等。在这样的环境中，物理节点本身并不是绑定固定地址，甚至涉及到 5G 信号核心网注册切换等通信上的流程问题，使得 IP 地址和网络拓扑并不具备完全意义上的寻址能力，通俗说某个节点可能在上一时刻在 A 区域但是过了一会他就行驶到 B 区域了，这样动态变化切换的场景是以往 CNI 架构不曾考虑的。CNI 的连通性是基于 Kubernetes 的 Node IP 维持的，更加深入理解这个结论：主流的 CNI 相信 Kubernetes 系统设置的 IP 地址是可以联通的，所以这些主流的 CNI 方案管理虚拟网络往往都使用这样的方法：宿主机操作系统中的一个切换装置，通过让自己作为虚拟网络资源和实际物理网络环境的中继；正如下图所示， CNI 只是通过 k8s 系统，在各个节点上创建了虚假的地址，通过信息协同的方式让拥有这些虚假地址的数据包可以正常在单机节点上传送给目标，但根本还是依赖于 Node IP 可以访问联通，毕竟如果数据包不能够正常到达目标节点，CNI 利用操作系统所作的虚假行为也就没有了意义。反过来说也无法超过于单机操作系统能够管理的网络连通性，多机分布式场景下完全只能够依靠 Kubernetes 系统。当然，也并非所有的主流 CNI 都只在本机的操作系统内做文章，更加深入解决连通性的 Calico 组件有提供基于 BGP 协议的跨机连接方案，但也围绕着云上数据中心架构展开的。与此相对应的边缘环境中， 节点的 IP 地址是存在着局域性、变动性、不确定性的，可以风趣地说 Kubernetes 系统被节点欺骗了。容器生命周期短暂且不确定，这个特性更像是此类问题的催化剂，使得边缘割裂场景下的网络连接更加难以使用固定的拓扑结构来进行规划管理。系统设计思路在本特性初阶段我们确定了此次项目实现的目标：是结合 EdgeMesh 已有的 P2P 功能来提供 CNI 特性， CNI 特性在目前阶段并不意味着开发出完全替代Flannel、Calico、Cilium 等已有架构的完全独立 CNI，而是作为多阶段逐步迭代实现的特性。一方面从用户角度来说，如果直接替代云上已有的 CNI 架构，会带来额外的部署成本，也无法向用户保证新的架构有足够的价值可以完全覆盖老体系的场景和功能，以项目迭代开发的方式，优先实现一些能力，再慢慢优化、敏捷开发更能符合用户的利益。因而对于云上环境，我们倾向于直接兼容已有的 CNI 架构，使用它们提供的服务，但是补足他们不能够提供的 P2P 功能。与此同时，现有的 CNI 方案并不能够为边缘复杂异构的环境提供统一的容器网络服务，所以相较于 Docker 或者是其他 CRI 提供的简单网络功能，我们更倾向于直接开发出自己的 CNI 来实现对边缘容器网络资源的管理。而在上述的 CNI 需求之外，最重要的是如何与 EdgeMesh 的 P2P 服务结合起来；目前的开源社区中实现隧道的技术有：如 VPN，包含 IPSec、Wireguard等；如 P2P，包含 LibP2P 等，结合 EdgeMesh 应对的复杂异构多变边缘环境，我们选用了 LibP2P 技术进行开发。在此之上需要判断哪些PodIP流量需要 P2P ,哪些流量仍旧使用原本的 CNI 网络服务；再来是将这两部分的功能解耦，以便后期的功能逐步迭代优化，主要的系统架构如下图所示：上述系统设计将集群内的流量分为两类：同一网段流量： 指的是底层网络 NodeIP 可通信，Pod 容器流量通过 CNI 转换即可进行通讯。跨网段流量: 指的是底层网络不可直接访问， Pod 容器流量通过 CNI 转换封装也无法到达目标节点。针对于不同的流量我们提供不同的流量传输方式：对于同一网段的流量：依旧使用主流 CNI 的方案，通过 CNI 转换地址的形式切换虚拟网络和真实网络，连通性依赖 Kubernetes 系统获取的 NodeIP。对于跨网段的流量： 将这部分流量拦截到 EdgeMesh 当中，通过中继或者是穿透的形式转发到目标的节点，此时 EdgeMesh 充当具有 P2P 功能的 CNI 插件，来完成虚拟网络的切换。这样的设计需要解决亮点重要的问题：云边集群容器网络资源统一控制管理边缘节点以及云上节点 CNI 共同管理容器网络资源，使得容器可以分配到集群唯一的 IP地址，且不论云边都可以通过这个 IP 地址进行通信。云边以及边边跨网段容器网络通信能力兼容原本 CNI 的通信方式让需要 P2P 的流量跨网段传输。系统设计的关键抉择在于，是否需要将 P2P 的功能放置到 CNI 执行的关键路径当中，或者是将 P2P 的功能与 CNI 架构解耦。针对于第一个问题，核心关键是 IPAM 插件的设计和兼容，这方面我们倾向于集成开源社区成熟的方案 Siderpool ：📌 ：https://github.com/spidernet-io/spiderpool Spiderpool 是一个kubernetes 的 underlay 和 RDMA 网络解决方案， 同时也是一款 CNCF Sanbox级别项目这一方案也更加契合容器网络插件化设计的理念，用户可以依据业务的需求来更改系统组件的组合，在现阶段完全满足多 CNI 统一管理集群资源的设计。针对第二个问题，核心在于为 CNI 创建的容器网络资源添加跨子网的连通性。方案设计上，如果将中继和穿透的功能放置到 CNI 执行的关键路径中，那就意味着需要在内核中实现中继和穿透的流程，否则将带来巨大的性能消耗。实际上目前 Calico 、 Flannel 、Cilium 等架构在云上使用隧道技术时候就是采用这个方法：在容器资源创建修改的时候，同步修改内核中的网络设备参数，然后对数据包进行封装或者是修改，比如 Vxlan 服务中将目标是其他节点容器的流量拦截，然后添加对协议参数。这个方式在云上运用较为普遍，但是明显无法适应边缘的环境，原因在于：CNI 执行是无状态且一次性的，只有当容器网络资源创建、修改、删除的时候， CNI 调用链会被触发并执行对应的功能；这个方式的实质是通过静态配置的方式来提供通信服务，对于云上较为稳定的网络环境以及通信条件来说，确实是合适的选择，但对于边缘环境来说，网络资源并非一成不变；如果将隧道信息配置为静态形式，再通过 CNI 调用链触发管理，就无法应对部分容器动态变化之后隧道信息变迁的情况。在上述考量的基础上，本特性将 分开 CNI 和 P2P 的功能，解耦彼此在系统运作上的依赖关系，这样也更加方便用户可以选择是否开启其中的一项功能。边缘 CNI 功能这部分设计为实现基础的 CNI 调用链功能，在边缘节点管理容器网络资源，同时通过 IPAM 组件 spiderpool 兼容云上其他的 CNI 架构，统一分配集群的容器网络资源，包括基础的 CNI 功能，其次是通过 SpiderPool 实现全局的容器 IP 地址唯一。基于以上各组件设计,当集群内每一个容器都拥有了唯一的 IP 地址，我们接下来需要做的是为需要中继穿透的流量提供服务，设计方式为： 用户配置全局容器网段文件，分为云上 CIDR 和 边缘 CIDR ，每一段 CIDR 对应一个区域网络即 三层不可通的网络， EdgeMesh 通过配置文件插入路由表规则，将目标地址于本节点 CIDR 不相同的流量都拦截到本机的Tun 设备，再传输到 EdgeMesh 的 libP2P host 通过中继或者穿透的方式传输到目标地址。▍特性启用以及功能启用 EdgeMesh 边缘 CNI 特性您可以通过以下配置的方式，在启动 EdgeMesh 时候启用 CNI 边缘 P2P 特性，配置过程中您可以依据对云边网段资源的划分需求来配置云边容器网络所处的区域：# 启用 CNI 边缘特性 helm install edgemesh --namespace kubeedge \ --set agent.relayNodes[0].nodeName=k8s-master,agent.relayNodes[0].advertiseAddress="{1.1.1.1}" \ --set agent.cloudCIDR="{10.244.1.0/24,10.244.1.0/24}",agent.edgeCIDR="{10.244.5.0/24,10.244.6.0/24}" https://raw.githubusercontent.com/kubeedge/edgemesh/main/build/helm/edgemesh.tgz上述配置的参数中 cloudCIDR 是云上容器集群分配的地址， edgeCIDR 是边缘容器集群分配的地址；EdgeMesh 会对比部署节点分配到的容器网段 CIDR 与配置文件中是否属于不同网段，属于不同网段的地址会添加对应的 ip route 规则拦截到 Tun 设备。cloudCIDR 参数是云上分配的容器网段，类型为 []string ，形式为容器 IP 地址以及其子网掩码，表示一段虚拟网络区域，在区域内的容器应当网络二层可通，如果容器不能够通过二层设备访问，请划分为不同的容器网段。edgeCIDR 参数是边缘分配的容器网段，类型为 []string ，形式为容器IP地址以及其子网掩码，表示一段虚拟网络区域，在区域内的容器应当网络二层可通，如果容器不能够通过二层设备访问，请划分为不同的容器网段。名称参数类型使用实例agent.meshCIDRConfig.cloudCIDR[]string--setagent.meshCIDRConfig.cloudCIDR="{10.244.1.0/24,10.244.1.0/24}"agent.meshCIDRConfig.edgeCIDR[]string--setagent.meshCIDRConfig.edgeCIDR="{10.244.1.0/24,10.244.1.0/24}"需要注意的是设置的地址必须为 CIDR 形式 ，同时需要您依据云边网络情况划分出对应的网段；另一方面本特性需要同时启动高可用特性，为跨网段的流量提供中继和穿透服务。更多的安装配置信息请详见：helm安装 : https://edgemesh.netlify.app/zh/guide/#helm手动安装：https://edgemesh.netlify.app/zh/guide/项目功能特性介绍依据系统的设计，边缘 CNI 特性提供以下具体的功能：云边集群容器网络资源控制管理📌 ：现版本推荐集群云上节点使用 calico/flannel/cilium 等 CNI 插件，同时边缘集群节点使用 EdgeMesh CNI 插件，整个集群配置 SpiderPool 作为统一的地址管理插件来提供服务。针对于边缘网络复杂异构的情况，EdgeMesh 提供了边缘 CNI 插件来创建和管理边缘节点容器的地址资源，同时通过配合 IPAM 插件 spiderpool 协调云上节点的其他 CNI 插件来实现 整个集群的容器地址唯一，云边节点都可以通过唯一的地址进行通讯。如下图所示，该项功能的主要特性在于屏蔽了云边复杂的网络集群拓扑，实现了云边集群统一的容器资源管理，使得云边的容器可以体验如同在一个局域网内的通信服务，而不必考虑边缘集群节点容器地址重复或者是云边集群底层地址不通的问题。云边以及边边容器网络通信能力针对于边缘环境中云边和边缘通信问题，EdgeMesh CNI 特性集成了 P2P 的功能，为跨网络集群的容器流量提供中继和穿透服务。该 P2P 特性现版本主要通过 TUN 设备在 IP 层拦截需要中继和穿透服务的流量实现，能够为应用网络通信提供底层连接的服务，而不受到 IP 层以上网络协议的影响。系统功能运行如下图所示，在每个节点上的 EdgeMesh 会通过修改 IP Route 的形式拦截流量到 TUN 设备，再传输到 EdgeMesh 的 libP2P host 通过中继或者穿透的方式传输到目标地址。这个过程中 EdgeMesh 并不会拦截所有的流量而是通过用户在启动时候设置的网络区域参数来区别哪些流量是跨网段，哪些流量是同局域网访问的，并不会干扰到正常同网段流量的通信。后续计划以及未来设想在项目开发的初期阶段，系统设计基础实现了最初的需求，但是在边缘容器网络环境当中，由于网路部署和设备架构的使用情况多样复杂，对于容器网络提出了三方面重点的需求：可观测具体指的是对于云边以及边边流量的去向，包含在节点内操作系统处理的过程以及节点外多节点之间转发传输的流程可观测性。这类需求对于运维人员以及应用开发人员有着非常重要的价值和意义，可以快速定位网络流量问题出现的位置和导致的原因，并快速得出性能优化的方案和解决问题的办法。高性能与纯云部署的容器集群相似，云边混杂集群同样也面临着性能堪忧的问题，在网络层面主要指的是节点内对网络数据包在操作系统处理路径上的优化，减少其处理的逻辑和相关资源的消耗。强稳定相较于纯云上集群的部署，云边混杂集群的状态往往难以稳定，需要服务能够应对环境变化同时在出现问题时候较快地将流量卸载到正常的服务当中。针对于这些需求， 容器网络 CNI 功能是重点开发和创新的系统组件， EdgeMesh 将在接下来的系统开发中结合 eBPF 等内核优化技术，同时以实现一款泛用的边缘 CNI 插件为目标，推出应对这三点需求的特性和功能，期待能够为用户带来更加丰富和稳定的网络服务体验。附：KubeEdge社区贡献和技术交流地址[1] 网站: https://kubeedge.io[2] Github地址: cid:link_0[3] Slack地址: https://kubeedge.slack.com[4] 每周社区例会: https://zoom.us/j/4167237304[5] Twitter: https://twitter.com/KubeEdge[6] 文档地址: https://docs.kubeedge.io/en/latest/更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群

12月27日，由中国信息通信研究院、中国通信标准化协会主办的2023系统稳定性与精益软件工程大会在北京隆重举行，在云服务稳定性保障技术专场暨稳定性保障实验室年会上，华为云aPaaS应用平台AppStage运维中心专家受邀发表了“云原生时代如何构建应用稳定性”的演讲，分享了华为云应用平台AppStage运维中心在如何应对云原生应用运维挑战及保障应用稳定性上做出的探索和实践。云原生时代应用运维模式从传统的以资源管理为核心，升级为以应用管理为核心，原有运维方式面临着多方面的挑战：业务软件快速迭代、运维工具林立、业务快速发展与应用高稳定性要求存在矛盾。为应对云原生时代运维挑战而生的华为云应用平台AppStage运维中心，围绕云原生的业务场景，构建了4大能力：一是，基于智能运维AIOps，实现无人值守变更。通过Everything as a Code (XaC)声明，华为云应用平台AppStage运维中心将变更的评审、执行和验证等步骤自动化，避免人因失误，缩短变更过程中的步骤和操作时间，实现无人值守变更，帮助企业提升了运维效率；二是，通过端、管、边、云的联动监控，实现故障生命周期智能化管理。华为云应用平台AppStage运维中心通过端、管、边、云的联动监控，让指标、日志、调用链全栈可观测，打通了数据孤岛。在端侧告警后，通过AI异常检测算法及AI根因诊断等能力，实现1分钟发现、5分钟定位、10分钟恢复，大大降低了故障恢复时间，提升了业务质量；三是，通过混沌工程故障注入，充分验证应用可靠性。华为云应用平台AppStage运维中心支持80多种故障注入方式，预定义了50多种故障演练场景，通过模拟各种故障、全自动化演练，主动给应用“打疫苗”，使业务对故障具备免疫能力，提升了业务的稳定性；四是，FinOps运维成本可视化，帮助企业降本增效。华为云应用平台AppStage运维中心通过将AIOps的灰度评估、告警归并、异常检测、故障根因诊断等能力，嵌入运维的各个活动中，将以前的被动运维转为主动运维，帮助企业优化资源利用，实现降本增效。华为云应用平台AppStage运维中心将华为内部沉淀多年的构建、管理、使用和维护大规模云原生应用的经验构建到平台上来，通过平台化的开放，让更多的能力、经验共享出来，实现向产业‘经验即服务’的能力复制。以往需要大量工作的可靠性、韧性、安全等基础的工程能力，都通过平台提供，让企业可以聚焦于业务代码。未来，华为云希望通过应用平台AppStage运维中心帮助更多企业降低应用维护和使用云原生应用的门槛，实现应用维护智能化，为企业应用稳定性保驾护航。目前，华为云应用平台AppStage正在火热公测中，欢迎前往华为云官网，点击“产品-开天aPaaS-应用平台AppStage”体验使用。

12月16日-17日，以“一切为了开发者”为主题的开放原子开发者大会在无锡举办。会上，由开放原子开源基金会主导，华为、浪潮、DaoCloud、谐云、青云、飓风引擎以及OpenSDV开源联盟、openEuler社区、OpenCloudOS社区等成员单位共同发起建设的AtomHub可信镜像中心正式开放公测。AtomHub秉承共建、共治、共享的理念，旨在为开源组织和开发者提供中立、开放共建的可信开源容器镜像中心。AtomHub可信镜像中心正式公测平台地址：https://atomhub.openatom.cn/▍背景容器技术是云原生生态的基石，随着云原生技术在千行百业大规模落地和快速发展，容器镜像已经成为云原生应用分发的关键形态。开源容器镜像安全可靠的传播和分享，对云原生技术生态的繁荣有巨大促进作用。由于Docker Hub等镜像仓库的不稳定性和不可控性，以及一些政策和法规的限制，开发者们使用这些镜像仓库时也面临着种种问题和困难。网络不稳定：包括Docker Hub在内的多数容器镜像托管平台，服务器都位于海外，国内用户在访问时经常会遇到网络延迟和丢包的问题，导致镜像的上传和拉取频繁超时或请求失败。镜像拉取被限流：以Docker Hub为例，匿名用户6小时内只能拉取镜像100次，而注册登录的免费用户每6小时也只能拉取镜像200次，严重影响了镜像构建和应用部署的效率。缺失中立平台：国内用户缺失中立的镜像分享平台，构建镜像上传到Docker Hub再从国内下载受限制，影响容器镜像在中国的分享和传播。▍AtomHub定位鉴于上述原因，打造一个中立、开放共建的可信开源容器镜像中心，成为了当前亟待解决的问题。AtomHub项目——开源容器镜像中心由此发起，旨在为开发者提供来源真实、生态开放、平台中立、安全可信的新一代开源容器镜像中心。▍AtomHub架构AtomHub将采用镜像评级机制，确保镜像质量和安全性。官方镜像是由AtomHub官方发布的镜像，具有最高度可靠性和安全性，涵盖各种流行的操作系统、编程语言、数据库、中间件和应用程序；认证社区镜像由经过认证的开源社区发布，符合社区的质量标准和安全规范；认证厂商镜像则由经过认证的软件厂商发布，具有较高可靠性和专业性。与此同时，AtomHub还支持开发者自行构建和发布镜像，以满足个性化的需求。AtomHub将基于国产操作系统和软件打造自主可信根镜像、可信全链路构建系统，支持安全漏洞扫描和内容合规检测，及时发现和修复镜像漏洞和安全风险，确保镜像层层安全可信，重建可持续容器镜像供应链。AtomHub计划采用高性能镜像存储后端、多云CDN同步、冷热数据自动转储分流等关键技术，打造百万级并发规模容器镜像分发平台，为用户提供稳定可靠的镜像下载服务。▍AtomHub五大战略规划安全性：AtomHub将提供一套完善的安全机制，包括镜像签名、漏洞扫描和内容合规检测等功能，确保镜像安全可靠。高性能：AtomHub将采用高性能存储引擎和多云CDN加速，为您提供高速的镜像拉取和推送体验。易用性：AtomHub将会提供用户友好的Web界面，支持关键词搜索、分类浏览和镜像智能推荐，方便用户快速找到和下载所需镜像。兼容性：AtomHub采用OCI标准，兼容Docker Hub生态，可以无缝对接您现有的容器编排和持续集成/持续部署（CI/CD）工具。开放性：AtomHub将完全开源，打造一个开放、中立、透明的容器镜像共享平台，允许所有爱好者共同参与项目的开发、维护和使用。AtomHub作为一个新兴的开源容器镜像中心项目，对中国本土云原生技术和开源生态良性循环有巨大促进作用，我们欢迎所有对开源和容器技术感兴趣的开发者们加入我们的社区，一起打造安全可靠、高效便捷的容器镜像中心！AtomHub可信镜像中心平台地址https://atomhub.openatom.cn/首批提供160+款基础软件容器镜像，包含操作系统，编程语言，主流中间件等，欢迎体验！更多镜像陆续增加中

12月16日-17日，以“一切为了开发者”为主题的开放原子开发者大会在江苏无锡举办。秉持“共建、共治、共享”原则，聚焦大模型、云原生、前端、自动驾驶、物联网、开源治理与开发者运营等多领域内容，大会汇聚百万开发者生态，集聚政、产、学、研、用、金、创、投等各方力量，云集全球技术专家和行业大咖，持续推动软件生态蓬勃发展。华为云重磅参会开幕式、云原生分论坛、展区等多个环节，共同推进开源与云原生产业发展。▍开放原子云社区正式成立开幕式上，开放原子开源基金会理事长孙文龙与北京航空航天大学、华为技术有限公司、阿里巴巴集团控股有限公司、深圳市腾讯计算机系统有限公司、招商银行股份有限公司、京东科技信息技术有限公司代表共同启动成立开放原子云社区。▲开放原子云社区成立仪式北京航空航天大学的胡春明教授当选担任开放原子云社区主席，华为技术有限公司王泽锋，阿里巴巴集团控股有限公司丁宇，深圳市腾讯计算机系统有限公司邹辉，招商银行股份有限公司罗文江分别当选开放原子云社区副主席。开放原子云社区的成立，将通过凝聚云原生产学研用各方力量，共同推动我国云产业高质量发展。未来，该社区将围绕云原生技术路线图及生态全景规划、发掘孵化优质项目形成完整技术栈、培育壮大国内云原生开源生态、积极开展人才培养和国际合作等方面，推动云计算行业迈入“云上价值挖掘”的新阶段，重塑云计算产业价值链。▍AtomHub可信镜像中心正式公测由开放原子开源基金会牵头，开放原子云社区多家成员单位共同建设的AtomHub可信镜像中心在本次大会上正式开放公测。▲ AtomHub可信镜像中心正式公测AtomHub可信镜像中心由开放原子开源基金会牵头，华为、浪潮、DaoCloud、谐云、青云、飓风引擎以及OpenSDV开源联盟、openEuler社区、OpenCloudOS社区等成员单位共同发起，秉承共建、共治、共享的理念，旨在为开源组织和开发者提供中立、开放共建的可信开源容器镜像中心。▲ AtomHub可信镜像中心首批共建单位&社区▍云原生技术前沿落地实践论坛大会的“云原生技术前沿落地实践论坛”由CNCF基金会大使、技术监督委员会贡献者及多个项目创始人王泽锋担任出品，复旦大学计算机科学技术学院副院长、教授、博士生导师彭鑫，网易资深云原生专家侯诗军，腾讯云容器技术专家孟凡杰，蚂蚁集团高级研发工程师王思远，蚂蚁集团算法专家徐剑，华为云云原生团队开源技术专家徐中虎，开源项目 Serverless Devs 联合发起人、项目负责人袁坤，通明智云产品总监单雷，DaoCloud大容器团队技术负责人张潇，DaoCloud大容器团队开发工程师涂立海分别带来议题分享。云原生论坛议题聚焦云原生架构的创新与演进、云原生中间件的稳定性与可靠性、云原生的智能化运维与告警、云原生的FinOps实践、云原生Serverless架构与研发体验等多领域，为参会者提供全面视角和实践分享。▲云原生技术前沿落地实践论坛嘉宾合影在《融入未来：分布式云原生架构演进》的主题演讲中，华为云云原生团队核心成员、开源技术专家徐中虎分享了分布式云原生的发展历史与挑战，分布式云原生架构的演进，华为云Kurator项目在分布式云原生领域的创新。Kurator源于华为云在分布式云原生架构演进过程中多年探索，借助Kurator快速构建分布式云原生平台，可以帮助用户快速构建、部署、监控分布式云原生应用。▲华为云云原生团队核心成员、开源技术专家徐中虎▍Kurator分布式云原生开源社区展区Kurator是一款打造统一分布式云原生基础设施的开源套件。项目整合Karmada、KubeEdge、Volcano、Kubernetes、Istio、Promethus等业界主流开源技术栈，提供多云、多集群统一编排，统一调度，统一流量治理，边云协同，统一监控运维等核心能力，助力企业业务跨云跨边，分布式化升级。社区地址：cid:link_0▲Kurator分布式云原生开源社区随着云原生产业的不断发展，如何从战略全局去规划软件产业高质量发展，充分发挥开源生产方式的作用，是加快推进新型工业化发展的一大命题。社会各界都在整个过程中发挥着环环相扣的力量，而各行各业的开发者和使用者是数字时代创造知识、沉淀知识的主力军，开发者活力是软件产业繁荣发展最直接、最生动的体现。大会倡议，深化交流互鉴，聚焦产业亟需，增添发展动力，加强国际合作，做好服务保障。希望社会各界关注开源、拥抱开源、支持开源，深刻认识开源价值，为开发者提供服务，特别是在资产评估、价值认定、集成创新方面予以重点支持。也希望广大开发者和使用者能积极贡献智慧与力量，以时代责任应对共同挑战，以实干担当开创美好未来。更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群

"Kubernetes运维确实复杂，这不仅需要深入理解各种概念、原理和最佳实践，还需要对集群的健康状态、资源利用率、容器的稳定性等多个方面进行风险评估。当集群出现故障时，我们通常需要花费大量时间来分析各种日志和监控信息，以找出问题的根本原因。"一位IT公司运维总监如此说道。近年来，越来越多的公司转向了基于Kubernetes的云原生架构。随着微服务和云原生架构的变得越来越复杂，我们也收到不少客户反馈在生产中进行监控和故障排除变得越来越困难。虽然CCE云原生可观测平台提供了监控、告警、日志等功能，能够让用户更加方便的定位问题，但是同样也无形中提高了运维人员的技术门槛。为了让运维和开发人员能够从繁重的故障定位排查中解脱出来，CCE服务提供了集群健康诊断能力。CCE集群健康诊断集合了容器运维专家的经验，为您提供了集群级别的健康诊断最佳实践。可对集群健康状况进行全面检查，帮助您及时发现集群故障与潜在风险，并给出对应的修复建议供您参考。▎开箱即用：免开通零依赖，一键健康诊断集群健康诊断功能作为CCE内置健康专家系统，可以在不依赖任何插件和其他服务的情况下独立运行。用户无需繁琐的开通与配置流程，就可以一键触发集群健康诊断。图1 一键健康诊断▎定时巡检：无人值守，持续守护集群健康在主动运维场景，比如集群升级前后或业务重保期间，用户可随时主动触发健康诊断来保障业务的顺利运行。另一方面，在日常运维中，我们无法一直盯屏保障，为了将客户从这种低级的劳动中解放出来，健康诊断支持定时巡检功能，只需要简单的配置定时任务，健康诊断任务就可以在后台守护您的集群健康，并将检查结果定时存档，方便随时回溯复盘。图2 健康检查结果▎多维诊断：丰富的诊断项，集群全方位体检CCE集群健康诊断提炼了运维专家提供的高频故障案例，覆盖了集群/核心插件/节点/工作负载/外部依赖等多种维度的健康检查，并且所有的诊断项都给出了风险评级、影响风险、以及修复建议。集群维度：包括集群运维能力检查，安全组配置检查，集群资源规划检查等诊断项。图3 集群维度诊断项核心插件维度：覆盖监控、日志、coredns、存储等核心插件的健康检查。图4 核心插件维度诊断项节点维度：包括节点资源负载情况和节点状态诊断。图5 节点维度诊断项工作负载维度：包括工作负载配置检查，Pod资源负载检查，Pod状态诊断等。图6 工作负载维度诊断项外部依赖维度：主要包括ECS和云硬盘等资源配额检查。图7 外部依赖维度诊断项▎智能分析：智能健康评级，专业修复建议CCE集群健康诊断会针对故障和潜在风险，给出风险等级并提供修复建议。风险等级按照紧急程度分为高风险和低风险两种：高风险：说明该诊断项会危及到集群或应用稳定性，可能造成业务损失，需要尽快修复。低风险：说明该诊断项不符合云原生最佳实践，存在潜在的风险，但是不会马上对业务造成重大影响，建议修复。在每一次健康诊断完成之后，所有的诊断结果会被汇总分析，并给出最终的集群健康评分，该评分反映了集群的整体健康状况。健康评分较低的集群往往存在较大的故障风险，需要引起集群管理员的高度重视。图8 健康风险等级评估▎案例分析：一次安全组误操作导致的业务故障CCE作为通用的容器平台，安全组规则的设置适用于通用场景。集群在创建时将会自动为Master节点和Node节点分别创建一个安全组。如果用户不小心误操作了默认安全组中的规则，可能会导致节点网络不通等问题，而且这种问题往往比较难以排除，需要花费较多的时间才能定位到安全组的原因，影响业务恢复速度。这种情况我们可以通过健康中心的巡检功能来进行故障诊断。例如修改一个集群的默认安全组规则，将Master与Node通信规则，从允许改为拒绝。图9 修改安全组规则以上操作会导致集群部分功能异常，如网络不通出现无法执行kubectl命令的问题。这种问题往往难以排查，会消耗用户大量的时间来寻找根因。此时如果用户在CCE健康中心执行一次健康巡检，会发现安全组高风险巡检项提示：图10 安全组异常提示通过诊断详情可以直接定位异常安全组，便于进行针对性修复：图11 定位异常安全组整个故障诊断流程方便快捷，可以大幅减低故障排查时间，帮助客户业务更稳定的运行在CCE集群上。▎结语CCE集群健康诊断功能，集成沉淀了大量的专家运维经验，目标是为客户提供更加智能、快捷的运维能力。当前该能力依然在快速迭代，后续我们会增加巡检结果通知、风险评估阈值调整以及更丰富的诊断项等能力，为大家带来更智能、更可靠稳定的云原生系统。服务体验请访问cid:link_0云容器引擎 CCE

北京时间12月20日，云原生计算基金会（CNCF）正式接纳多沙箱容器运行时项目 Kuasar（cid:link_0）。Kuasar的加入，极大地推动了云原生领域容器运行时技术的探索、创新和发展。作为CNCF首个多沙箱容器运行时项目，Kuasar于2023年4月在KubeCon + CloudNativeCon Europe上由华为云、中国农业银行以及openEuler社区、WasmEdge社区和Quark Containers社区联合发起。Kuasar融入了各企业和社区在容器运行时领域的前沿探索、技术积累和生产实践，开源至今受到业界的广泛关注和支持，已收获900多个GitHub Star和70多个Fork，数十位来自外部企业、高校的开源爱好者参与开发贡献和积极落地应用，Kuasar正以开源创新的姿态促进云原生产业发展。“WebAssembly正在快速成为云原生技术栈的一个关键部分，Kuasar深度集成了高性能、轻量级的WasmEdge沙箱，Kuasar的加入使得WebAssembly生态和CNCF生态联系更加紧密，未来WasmEdge和Kuasar将共同推动在大模型、边缘计算和函数计算等领域的发展。”—— WasmEdge项目创始人  Michael Yuan“openEuler社区在Kuasar项目发布之初就率先完成与Kuasar多沙箱生态的对接，推出基于iSulad + Kuasar + StratoVirt的极速轻量安全容器解决方案。未来openEuler社区将继续深化与CNCF社区项目的合作，为用户提供更轻量、更安全、更多样的容器化底座。”—— openEuler技术委员会主席  胡欣蔚“Kuasar项目融入了华为云在容器运行时领域多年的积累，结合了社区合作伙伴的实践经验。成为CNCF官方项目，表明了Kuasar社区开放治理的决心，致力于为企业和开发者提供厂商中立、多方协作的开放环境，促进各种沙箱技术的商用成熟，为用户带来极致体验。”—— CNCF官方大使  华为云云原生开源团队负责人  王泽锋“云原生场景多样化促进了多种沙箱技术的蓬勃发展，沙箱技术接入北向生态成为普遍需求，Kuasar推动了Containerd中沙箱技术标准的统一，提供了多种沙箱技术实现，为CNCF的容器运行时板块注入了新鲜活力。”——  CNCF官方大使  Containerd社区维护者  蔡威▍Kuasar项目介绍为了满足企业在云原生场景下的诉求，业界出现了多种沙箱容器隔离技术。然而，应用云原生的沙箱技术仍面临挑战。一方面，各类云原生场景对沙箱提出更高要求，单一沙箱无法同时满足用户云上业务对安全隔离、极速低噪、标准通用等多个维度的要求，企业面临云原生业务场景全覆盖问题；另一方面，支持多类沙箱带来运维压力显著上升，当前业界沙箱技术对接容器运行时的实现缺乏统一开发框架，因此关键日志、重要事件、沙箱管理逻辑等均存在差异，新引入沙箱的同时运维压力陡增。Kuasar在保留传统容器运行时功能的基础上，与Containerd社区一起推动新的沙箱接口统一标准，并通过全面Rust化以及优化管理模型框架等手段，进一步降低管理开销，简化调用链路，灵活扩展对业界主流沙箱技术的支持。此外，通过支持多安全沙箱共节点部署，Kuasar可以充分利用节点资源、降本增效，为用户提供更安全高效的沙箱场景解决方案。▲ Kuasar项目全景图南向沙箱方面，Kuasar已支持基于轻量级虚拟化技术的安全容器沙箱（Cloud Hypervisor、Qemu、StratoVirt），基于新兴的WebAssembly沙箱（WasmEdge、Wasmtime），基于进程级虚拟化的App Kernel沙箱（Quark）以及基于内核的原生普通容器沙箱（runC）；北向引擎方面，Kuasar已与Containerd联合构建最新的沙箱接口标准，并共同推动该标准在Containerd v2.0版本的完整实现。此外，轻量级容器引擎iSulad项目也已经完成与Kuasar项目的深度集成，支持在openEuler 23.09创新版本上一键部署。▍未来可期此次CNCF正式将Kuasar接纳为官方项目，将极大促进Kuasar上下游社区生态构建及合作。Kuasar将持续探索云原生容器运行时领域技术创新，在企业数字化、云原生转型过程中发挥作用，让基于Kuasar的多沙箱容器运行时方案融入更广泛的云原生技术生态。作为CNCF亚洲唯一创始成员、白金会员，华为云在CNCF贡献量、Kubernetes社区和Istio社区的代码贡献量持续多年稳居亚洲第一，已向CNCF贡献了业界首个云原生边缘计算项目KubeEdge、首个云原生批量算力项目Volcano、首个多云容器编排项目Karmada等多个重量级云原生开源项目，并持续开源Kurator、Kappital、Kmesh等创新项目，与全球云原生社区共同发展。Kuasar社区技术交流地址Kuasar官网：https://kuasar.io项目地址：cid:link_0Twitter: https://twitter.com/Kuasar_io添加社区小助手回复“Kuasar”进入技术交流群

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多所高校合作培养数万名专业人才，产、学、研、用深度融合，让核心技术生态行稳致远。面向飞速发展的大模型时代，在开发者方面，华为云提供盘古大模型研发工程套件，打造开放模型社区、大模型云学堂，帮助开发者更快实现大模型的开发落地。华为云希望广大开发者基于华为的根技术，利用云上的澎湃算力和盘古大模型的强大能力，共同构建起“百模千态”的繁荣生态。面向未来，华为将加快软、硬、边、端、云等全面融合，协同华为云、鲲鹏、昇腾、鸿蒙等开发生态，持续加大投入研发创新，与全球各领域开发者一起用技术推动世界进步。