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

作者：华为云云原生团队随着云原生技术在越来越多的企业和组织中的大规模落地，如何高效、可靠地管理大规模资源池以应对不断增长的业务挑战成为了当下云原生技术的关键挑战。在过去的很长一段时间内，不同厂商尝试通过扩展单集群的规模来扩展资源池。然而，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)