"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

规格/指标项具体规格/指标描述基础功能规格操作系统的进程管理、内存管理和文件系统管理应满足台区操作系统规范要求。支持运行容器个数 不少于6个 性能规格在最小系统运行、系统空载条件下满足如下性能指标：进程创建平均时长应小于1ms；进程删除平均时长应小于1ms；上电正常运行平均时长应小于90s；管道本地通信平均延时应小于80ms；信号量平均延时应小于300us；内存连续读写平均延时应小于300ns；内存随机访问平均延时应小于500ns；安装容器平均时长应小于30s；卸载容器平均时长应小于10s；安装微应用平均时长应小于30s；卸载微应用平均时长应小于10s；驱动支持满足《台区智能融合终端操作系统技术规范 第2部分：硬件抽象层》规范要求的设备节点，和对外接口定义安全规格操作系统提供日志审计功能；关闭不使用或不在访问控制范围内的端口及服务；可信启动机制满足规范要求。对终端启动过程中操作系统引导程序、操作系统内核、关键系统文件做完整性校验并形成审计记录；操作系统版本安全升级。支持校验升级包的来源和完整性。

   基于台区SCU操作系统规范要求，使用国产操作系统RTOS和轻量化容器引擎isulad，满足了嵌入式轻量化、资源占用少的要求，为应用层提供稳定的基础服务平台。主要定制特性如下：基于RTOS基础能力实现进程管理、内存管理和文件系统管理等基础功能和性能规格要求。适配电力行业安全标准，满足安全启动、可信启动要求。使用国产轻量化容器isula实现容器功能。基于台区规范要求，增加了命令行、设备管理等基础管理功能。操作系统板级外设驱动适配。功能名称功能简述日志管理对日志大小、转存等进行管理；日志压缩等用户管理添加、删除用户；用户权限控制；用户密码修改等网络管理对网络IP、路由等进行配置4G上网 提供4G上网功能  设备管理  提供容器管理  安全加固  安全启动、权限控制，用户隔离  驱动适配  支持载波、交采、串口管理、4G上网、以太网 表1 操作系统功能域简述表   

1.1 Isula是什么？iSula是中南美洲亚马逊丛林中的一种非常强大的蚂蚁，被称为“子弹蚁”，因为被它咬一口，犹如被子弹打到那般疼痛，它是世界上最强大的昆虫之一。iSula是一种轻量级容器解决方案，可通过统一、灵活的架构满足 ICT 领域端、边、云场景的多种需求。具有轻、灵、巧、快等特点，不受硬件规格和架构的限制，底噪开销更小，可应用领域更为广泛。其中iSulad就是iSula的核心-容器引擎。1.2 isula的产生背景起初，华为为了在智能摄像头上达到快速、简单切换算法应用部署的功能，经过技术研究，他们决定使用容器来实现所需的功能。一开始，技术团队考虑对开源容器引擎 Docker 进行轻量化改造，对其裁剪和精简化、去除不需要的功能、优化组件结构等，甚至还对 Go 语言环境的编译进行了优化。但是，由于要运行在端侧的嵌入式设备上，这种裁剪和压榨资源的做法所能取得的效果有限。在这种情况下，针对端侧和 IoT 环境，华为的 iSula 容器团队做了一个大胆的决定，使用 C/C++ 来量身打造一套轻量级的容器引擎，能够具备Docker所不具备的优势。相比 Golang 编写的 Docker，使用 C/C++ 实现的 iSula 容器引擎，具有轻、灵、巧、快等特点，不受硬件规格和架构的限制，底噪开销更小，可应用领域更为广泛。在严苛的资源要求环境下，轻量模式下的 iSulad 本身占用资源极低（< 15M），再结合上特殊的轻量化镜像，可以达成极致的资源占用效果。2018 年，iSula 开始在华为内部的部分产品上使用。2019 年，华为决定将 iSula 开源出来，让开源社区和 iSula 共同发展，因此针对 CRI 接口进行了一次大范围的重构和补全后，与 openEuler 操作系统一并开源发布。1.3 isula何以轻灵巧快iSula 是全量的容器软件栈，包括了引擎、网络、存储、工具集与容器操作系统；而 iSulad 作为其中轻量化的容器引擎，可以为多种场景提供灵活、稳定、安全的底层支撑。1.3.1 轻iSulad 的第一个使用场景是在端侧设备上，这自然要求这个容器引擎具有轻量级资源占用的特性。再结合为端侧设备特殊定制的轻量化镜像，它可以达成极致的资源占用的效果。除了在端侧环境，在通用场景下，iSulad 也具有不错的轻量化表现。1.3.2 灵针对不同的使用场景提供了不同的模式，可以根据需要灵活配置切换注重性能的性能模式和注重资源占用的轻模式。1.3.3 巧为了使开发者迁移方便，iSulad 在开发一系列迁移工具，以帮助开发者将自己的应用平滑迁移到 iSulad 上来。1.3.4 快采用 C/C++ 语言实现的 iSulad，自然具备运行速度快等特性。再加上 iSulad 独特的架构设计，除了启动容器部分需要通过 fork/exec 的方式，其他部分均使用调用函数库的方式加快执行速度。

北京时间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/

前面我们了解了位于服务网格内部的应用应如何访问网格外部的 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”进入技术交流群

告警和日志是运维人员快速定位问题、恢复异常的主要手段。运维人员日常的工作模式往往是先接收告警信息，再根据告警信息初步判断异常的范围和影响，通过相关组件的日志定位出故障原因，进行系统恢复。因此，如何给运维人员提供简单易用的告警和日志管理平台是各个云原生平台高度关注的问题。相较传统系统，云原生场景下应用数量非常巨大，监控指标、事件、日志等运维数据更是海量的。同时，告警配置需要联通多个系统，如告警通知人的配置涉及消息通知系统、指标阈值告警规则涉及监控系统、日志关键字告警涉及日志管理系统等。这就导致云原生场景告警的配置复杂度相当高，且涉及跳转到不同系统，流程存在断点。同样，云原生场景下日志文件庞杂繁复。日志有容器标准输出日志、容器内日志、节点日志等多种类型；且日志可能分布在不同的主机上，位置不固定，从而导致日志查找困难。因此，如何帮助运维人员快速精确地查找到故障时间点的完整日志链路并清晰的呈现是日志服务所面临的关键挑战。图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

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

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

2023年4月8日，Kurator正式发布v0.3.0版本。Kurator 是华为云推出的分布式云原生开源套件，通过集成业界主流开源技术栈，帮助用户一站式构建专属的分布式云原生基础设施，助力企业业务跨云跨边、分布式化升级。Kurator v0.2 版本已具备管理多云基础设施和异构基础设施的核心能力，通过引入Cluster Operator组件，支持“AWS自建集群”和“本地数据中心集群”包括集群创建、清理等在内的生命周期管理特性。在最新发布的v0.3.0版本中，Cluster Operator不仅分别对两类集群的生命周期管理能力进行了增强，也将v0.2.0版本中的多个API对象抽象成一个API对象cluster，方便用户使用。 同时，在 cluster 对象基础上，Kurator引入了舰队的概念。每个舰队代表一个物理集群组，方便Kurator未来进行统一的编排、调度，统一的流量治理以及统一的监控运维。目前，Kurator的舰队管理支持多个特性，包括舰队控制平面的生命周期管理，以及集群注册和注销到舰队等。至此，Kurator 通过集群舰队统一了集群视图。这意味着，Kurator开始具备了支持用户体验一致地管理分布在任何云上的集群的能力，从而进一步协助用户的分布式云原生架构的升级。Kurator v0.3.0关键特性介绍集群生命周期管理能力增强Kurator 通过 Cluster Operator组件对集群的生命周期进行管理。基于Cluster API，Cluster Operator 不仅可以管理集群生命周期，还统一并简化了创建集群所需的配置，为用户在不同云平台上管理集群提供了简单易用的API。目前Cluster Operator 支持“本地数据中心集群”和“AWS自建集群”。本地数据中心集群Kurator基于kubespray对本地数据中心集群的生命周期进行管理。与 kubespray不同的地方在于，Kurator采用了更易于理解和配置的云原生声明式的方法管理集群。相比较v0.2.0版本，v0.3.0版本的Kurator 带来了以下几个方面的增强特性：• 批量的工作节点扩缩容。 现在Kurator支持以声明式的方式，在原有集群上增加、删除或者替换多个工作节点。 用户只需要声明集群所需要的最终工作节点状态，Kurator即可在没有任何外部干预的情况下完成节点的批量扩缩容。• 集群版本升级。 用户可以在API对象上声明要升级到的Kubernetes版本，Kurator便会自动对目标集群的各节点进行升级。• 增强集群控制面高可用。Kurator为用户提供了一种基于VIP的增强集群控制面高可用的方案。在这种方案下，Kurator利用kube-vip的能力，使用VIP实现跨多个控制平面副本的入站流量负载均衡。图片来源：https://inductor.medium.com/say-good-bye-to-haproxy-and-keepalived-with-kube-vip-on-your-ha-k8s-control-plane-bb7237eca9fc用户手册：https://kurator.dev/docs/cluster-operator/vms-cluster-lifecycle/AWS自建集群Kurator 通过Cluster Operator对AWS自建集群进行生命周期管理管理。相较于Cluster API 对AWS 自建集群的支持， Kurator简化了Cluster API提供的部署模型，通过部署Kurator集群操作器组件即可获得全部的管理能力。v0.3.0在以下几个方面带来了特性增强：• 易用性提升。kurator新增了一系列提升用户体验的改进, 包括了在创建集群之前验证凭据是否有效，自动管理云平台运营商所需的IAM角色和策略，校验依赖资源是否存在以及集中展示错误信息等。一键关联IAM与K8s身份。通过将AWS IAM角色与Kubernetes Pod身份关联，可以让IAM验证和接受Kubernetes颁发的令牌，而不需要创建和分发AWS凭据。这种关联具有最小特权、凭证隔离和审计性等优点，但是需要通过多个步骤设置。Kurator现在可以通过Cluster.Spec.PodIdentityg一键启用该功能，简化配置。apiVersion: cluster.kurator.dev/v1alpha1 kind: Cluster metadata: name: pod-identity namespace: default spec: ... podIdentity: enabled: true用户手册：https://kurator.dev/docs/cluster-operator/kurator-cluster-api/https://kurator.dev/docs/cluster-operator/aws-irsa/云原生舰队管理Kurator引入了代表物理集群组的逻辑单元“舰队”，旨在一致地管理一组集群，舰队允许您轻松、一致地管理分布在任何云中的集群。Kurator通过Fleet Manager实现了对舰队控制平面生命周期管理，并且可以轻松的将集群添加到或从舰队中删除。 未来，Kurator将支持Fleet级的应用编排，并且在Fleet的所有集群中提供统一的命名空间、ServiceAccount、Service，以支持在多个集群之间实现服务发现和通信。此外，Kurator将汇总来自所有集群的监控指标。Kurator Fleet Manager作为一个Kubernetes Operator运行，负责Fleet控制平面生命周期管理，也负责集群的注册和注销。用户手册：https://kurator.dev/docs/fleet-manager/Kurator，一键构建分布式云原生平台访问Kurator Release（cid:link_0），体验、升级最新版Kurator v.0.3.0，构建您的专属分布式云原生平台。如您对Kurator新版本特性有更多兴趣或见解，也欢迎来到Kurator社区，参与社区讨论与开发。GitHub地址：cid:link_1Slack地址：https://join.slack.com/t/kurator-hq/shared_invite/zt-1sowqzfnl-Vu1AhxgAjSr1XnaFoogq0A

作者：华为云云原生团队Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。在最新发布的1.5版本中，Karmada 提供了多调度组的能力，利用该能力，用户可以实现将业务优先调度到成本更低的集群，或者在主集群故障时，优先迁移业务到指定的备份集群。本版本其他新增特性：提供了多调度器支持能力，默认调度器可以与第三方自定义调度器协同工作，提供更强的定制能力。集群差异化配置策略（OverridePolicy/ClusterOverridePolicy）将按照隐式的优先级进行应用。内置资源解释器支持聚合StatefulSet/CronJob 状态。新特性概览多调度组根据 Flexera 发布的《2023 年云现状调查报告》，云成本的管理取代了安全性话题，成为当下云使用者面临的首要问题。Karmada 秉承这一趋势，同样关注云成本管理。从v1.5版本开始，用户可以在 PropagationPolicy/ClusterPropagationPolicy 中设置多个集群组，实现将业务优先调度到成本更低的集群组。下面我们给出一个针对成本优化进行调度的例子：apiVersion: policy.karmada.io/v1alpha1 kind: PropagationPolicy metadata: name: nginx spec: resourceSelectors: - apiVersion: apps/v1 kind: Deployment name: nginx placement: clusterAffinities: - affinityName: local-clusters clusterNames: - local-member1 - local-member2 - affinityName: cloud-clusters clusterNames: - huawei-member1 - huawei-member2上面的例子配置有本地集群组（local-clusters）和云上集群组（cloud-clusters），Karmada 在选择集群组进行资源分发时， 将按顺序对集群组逐一进行评估，直到找到满足调度约束的集群组。所以在调度Deployment/nginx时，会优先尝试调度到本地集群组的local-member1和local-member2，如果失败（如资源不足），则选择云上集群组，从而实现在本地集群资源足够时，优先选择成本更低的本地集群。基于此，系统管理员也可以定义主集群组和备份集群组，在主集群组故障时，将业务往备份集群组的集群迁移。下面我们给出一个针对容灾迁移的例子：apiVersion: policy.karmada.io/v1alpha1 kind: PropagationPolicy metadata: name: nginx spec: resourceSelectors: - apiVersion: apps/v1 kind: Deployment name: nginx placement: clusterAffinities: - affinityName: primary-cluster clusterNames: - member1 - affinityName: backup-cluster clusterNames: - member2上面的例子通过配置主群组（primary-cluster）和备份集群组（backup-cluster），在调度 Deployment/nginx 时，如果主集群组满足要求，会调度到主集群组的member1。在主集群组的集群故障时，调度器按顺序匹配新集群组，将业务迁移到备份集群组的member2。关于多调度组更多信息，请参考：cid:link_0自定义调度器Karmada 默认调度器内置多款可灵活配置的插件，可以满足大部分使用场景，用户还可以使用插件扩展机制来实现个性化调度诉求。Karmada 1.5版本提供了多调度器支持能力，Karmada 默认调度器可以与第三方自定义调度器协同工作，以提供更强的定制能力。用户可以参考默认调度器实现自定义调度器，当多个调度器共存时，需通过命令行启动参数指定调度器名称，如 --scheduler-name=my-scheduler 。如果自定义调度器与默认调度器部署在同一namespace中，建议同时配置 --leader-elect-resource-name 参数，以避免副本选主冲突。关键命令行启动参数如下所示：command: - /bin/karmada-scheduler - --kubeconfig=/etc/kubeconfig - --bind-address=0.0.0.0 - --secure-port=10351 - --enable-scheduler-estimator=true - --leader-elect-resource-name=my-scheduler # 你的自定义调度器名称 - --scheduler-name=my-scheduler # 你的自定义调度器名通过参数 --scheduler-name 将多个调度器进行区分，每个调度器将只负责调度特定的工作负载。通过 Karmada 分发工作负载时，可以在 PropagationPolicy/ClusterPropagationPolicy 的 schedulerName 字段指定调度器名字，如下所示：apiVersion: policy.karmada.io/v1alpha1 kind: PropagationPolicy metadata: name: nginx-propagation spec: schedulerName: my-scheduler resourceSelectors: - apiVersion: apps/v1 kind: Deployment name: nginx placement: clusterAffinity: clusterNames: - member1 - member2上例通过 schedulerName 指定此Deployment必须由名为 my-scheduler 的调度器进行调度，此时默认调度器将自动忽略该工作负载。schedulerName 如果没有指定，则默认值为 default-scheduler ，意味着由默认调度器进行调度，前面版本的用户升级到新版本时无需额外配置。关于如何扩展调度器插件和实现自定义调度器，请查看官方文档：cid:link_1版本升级Karmada v1.5版本API兼容v1.4版本API，v1.4版本的用户仍然可以平滑升级到v1.5版本。可参考升级文档：https://karmada.io/docs/administrator/upgrading/v1.4-v1.5致谢贡献者Karmada v1.5版本包含了来自25位贡献者的数百次代码提交，在此对各位贡献者表示由衷的感谢：贡献者GitHub ID:@a7i@calvin0327@carlory@chaunceyjiang@fengshunli@Fish-pro@Garrybest@helen-frank@ikaven1024@jwcesign@lonelyCZ@maoyangLiu@my-git9@Poor12@qingwave@RainbowMango@VedRatan@Wang-Kai@whitewindmills@wlp1153468871@wongearl@XiShanYongYe-Chang@yanfeng1992@yanggangtony@Zhuzhenghao参考链接Release Notes：cid:link_2多调度组：cid:link_02023 年云现状调查报告：cid:link_3扩展调度器插件和实现自定义调度器：cid:link_1附：Karmada社区技术交流地址项目地址：cid:link_4Slack地址：https://slack.cncf.io/(#karmada)

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

作者：华为云云原生团队如果说在以Kubernetes为基础构建起的云原生世界里，哪种设计模式最为经典，Sidecar模式无疑是其中最有力的竞争者。当需要为应用提供与自身逻辑无关的辅助功能时，在应用Pod内注入对应功能的Sidecar显然是最Kubernetes Native的方式，而Istio则是这种模式的代表。Istio项目的愿景是以尽量透明的方式，解决微服务场景下，服务间的连接、安全以及可观测性问题。主要实现手段则是通过在应用旁部署一个Proxy，在Kubernetes场景下则为应用Pod注入Sidecar，拦截应用流量至Sidecar。Sidecar根据从Istio控制面获取的用户配置对应用流量进行处理，以一种对应用代码几乎无侵入的方式实现了服务治理。图1虽然Istio并不局限于仅支持Kubernetes平台，但是Istio的设计理念与Kubernetes的Sidecar模式有着天然的亲和性。基于Sidecar模式，Istio能够实现在Kubernetes平台上的快速开发、部署、验证。同时，在功能层面，Isito将服务治理功能从应用代码中剥离，作为基础设施下沉至Sidecar，抽象出了事实上的云原生应用网络层，极大地减轻了应用开发者的心智负担，这部分能力刚好也是Kubernetes生态一直以来缺失的。基于Istio对于Kubernetes生态的完美补充，随着Kubernetes的大规模普及，Istio也实现了对用户心智以及市场的快速抢占。虽然以Sidecar模式部署Istio数据面似乎是一个理所应当，让人无法拒绝的选择，但是需要强调的是，Istio完整功能的实现并不与Sidecar模式强绑定，我们还有各种各样其他的选择。另外，随着对于Istio使用程度不断加深，落地规模不断扩大，可以发现以Sidecar模式部署Istio数据面诸多挑战：1. 侵入性：Istio基本实现了对应用代码的零侵入，但是由于Sidecar的注入需要更改Pod Spec并且对应用流量进行重定向，因此应用接入网格时需要重启Pod，而应用容器与Sidecar容器的启动顺序不确定造成的冲突也可能导致应用中断；2. 生命周期绑定： Sidecar本质上是基础设施，它和应用的生命周期往往不一致，因此升级Sidecar时也需要对应用Pod进行重启，同样可能导致应用中断，而对于Job类应用，Sidecar的存在则会导致Pod无法被及时清理；3. 资源利用率低：Sidecar为单个应用Pod独占，应用的流量存在波峰波谷，而一般情况下Sidecar的内存占用与集群规模（Service数目，Pod数目）强相关，因此需要按照极端情况预留资源，导致集群整体的资源利用率低。同时由于需要为每个Pod注入Sidecar，随着集群规模的不断扩大，Sidecar占用的资源总量也会线性上涨。针对Sidecar部署模式的缺陷，Google和Solo.io联合推出了一种新的Sidecar-less部署模式 --- Ambient Mesh。架构介绍图2Ambient Mesh架构如上图所示，从设计的角度来看，它主要有以下两个特点：1. Sidecar-less：为了避免上述Sidecar模式的种种缺陷，Ambient Mesh不再为任何Pod注入Sidecar，将网格功能的实现进一步下沉到Istio自有组件中。2. L4/L7处理分层：Ambient Mesh引入了ztunnel和waypoint两个组件用于代替原来的Sidecar实现相关功能，与Sidecar既能处理L4，又能处理L7流量的实现方式不同，Ambient Mesh对两者进行了区分，ztunnel只负责L4流量的处理，L7的流量则按需交由waypoint处理。Ambient Mesh的控制面与原先Sidecar模式的Istio相比基本没有变化，数据面的组件构成以及各个组件的作用如下：1. istio-cni：必装组件，以DaemonSet的形式部署。其实istio-cni并不是Ambient Mesh的新增组件，在原先的Sidecar模式中就已经存在，当时主要用于替代istio-init这个Init Container配置流量拦截规则，同时规避istio-init引发的安全问题。Ambient Mesh对它进行了扩展，以必装组件的形式部署，负责配置流量转发规则，劫持本节点中已加入Ambient Mesh的Pods的应用流量，转发至本节点的ztunnel；2. ztunnel: 必装组件，以DaemonSet的形式部署。ztunnel对所在节点Pods的流量进行代理，主要负责L4流量的处理、L4的遥测以及服务间mTLS（双向认证）的管理。最初ztunnel基于Envoy实现，但是考虑到对ztunnel功能的有意约束以及对安全性、资源占用率的要求，社区已经用rust从零构建该组件；3. waypoint：按需配置，以Deployment的形式部署。waypoint负责处理HTTP，故障注入等L7功能。以负载或者Namespace粒度进行部署，在Kubernetes中，即一个Service Account或者一个Namespace对应生成一个waypoint的Deployment，用于处理发往对应负载的七层流量，同时waypoint实例数可以根据流量动态伸缩。图3下面以Ambient Mesh数据面实际的处理过程来展示上述各个组件在其中扮演的具体角色：1. 与Sidecar模式类似，Ambient Mesh也能以网格、Namespace以及Pod的粒度将服务加入网格；不同的是，新加入的Pod无需重启，更不需要注入Sidecar；2. istio-cni监听本节点内Pods的增删以及进出网格的情况，动态调整转发规则，网格内Pods发出的流量会被透明地转发至本节点的ztunnel，直接跳过kube-proxy的处理；3. ztunnel同样需要对本节点Pods的增删以及进出网格的情况进行监听，从控制面获取位于本节点且被网格接管的Pods的证书并进行管理；4. 源端ztunnel对拦截的流量进行处理，根据流量的源IP找到对应Pod的证书，由此和对端建立mTLS；5. 如果要访问的目标服务没有配置waypoint或者没有配置L7相关的处理策略，则源端ztunnel直接和目的端ztunnel建立连接（如上图黄线标注），对端的ztunnel终止mTLS，执行L4安全策略，将流量转发到目标Pod；6. 如果目标服务配置了waypoint（利用特殊配置的Gateway对象）以及L7的处理策略，则源端ztunnel会和对应的waypoint建立mTLS，waypoint终止mTLS后，进行L7的逻辑处理，之后再与目标Pod所在节点的ztunnel建立mTLS，最终同样由目的端的ztunnel终止mTLS并将流量发往目标Pod。▎价值分析虽然从底层实现来看，Ambient Mesh和原有的Sidecar模式的差别巨大，但是从用户面看，两者在核心Istio API（VirtualService, DestinationRules等）的使用方式、实现效果都是一致的，能够确保基本相同的用户体验。Ambient Mesh是Istio社区除Sidecar模式外，支持的第二种数据面模式，所以网格技术本身能为用户带来的价值，Ambient Mesh与先前的Sidecar模式并不二致。因此这里只对Ambient Mesh相对于原生Sidecar模式的价值进行分析，对于网格本身的价值不再赘述。Ambient Mesh主要是针对Istio的数据面架构进行调整，用于克服既有Sidecar模式的不足，因此它的价值产生必然是基于其架构特点。前文已经提到过Ambient Mesh的架构特点主要有“Sidecar-less”和“L4/L7处理分层”这两点，下面就从这两点出发进行价值分析：1. Sidecar-less的优势，其实可以看作Sidecar模式缺陷的对立面：a) 透明：网格功能下沉至基础设施，不仅对应用代码零侵入，和应用的生命周期也完全解耦，做到真正对应用透明，允许应用与网格独立演进；b) 优化资源占用：数据面占用的CPU、内存等资源不再随着实例数线性增长，随着数据面的实例数减少，与控制面的连接数也相应减少，极大地减轻控制面的资源与处理压力。2. 对于为什么要对L4/L7进行分层处理，首先要区分两者之间的区别。与L4相比，L7的处理更为复杂，需要占用更多的CPU/内存等资源，不同类型的操作之间资源占用也存在较大差别；同时操作越复杂暴露的攻击面越大。另外Envoy当前并不支持对不同租户的流量进行强隔离，“Noisy Neighbor”的问题不可避免。因此Ambient Mesh分层处理架构的优势如下：a) 资源利用率高：ztunnel仅负责L4的处理，L4处理较为简单且资源占用较为固定，所以更易对ztunnel进行资源规划，无需过量预留资源，能够将更多的节点资源供用户使用；waypoint更可以根据L7负载动态扩缩容，充分利用集群中的资源碎片；b) 租户隔离：处理复杂、安全风险高的L7处理由租户（Service Account）各自的waypoint处理，既避免了租户间的资源抢占，又限制了安全问题的爆炸半径；c) 平滑落地：允许用户逐步接入网格，当仅需网格的L4处理能力时，完全无需考虑L7的资源占用以及可能造成的潜在负面影响（例如：因为错误配置导致进入L7处理而应用并未完全遵守L7协议，导致服务中断），之后在适当时刻按需开启相关功能即可。当然Ambient Mesh作为Istio全新的数据面架构，在社区中依然以实验特性的形式存在，仍然有许多问题亟待解决，例如：1. 性能：尤其是针对L7的处理，Ambient Mesh需要经过两个ztunnel以及一个waypoint，肉眼可见地又额外增加了一跳，因此完整的L7处理需要额外经过三跳。虽然社区声称这对性能的影响很小，但是仍需待其特性稳定后进一步观察对比；2. 容器网络适配：虽然Ambient Mesh与应用基本实现了完全解耦，但是反过来也增加了网格与底层基础设施的耦合，Sidecar模式仅需在Pod的net ns实现流量的拦截处理，但是Ambient Mesh在主机网络进行流量拦截，显然需要更多考虑与底层容器网络的适配；3. 配置复杂：原本Envoy复杂的配置就被广为诟病而Ambient Mesh更需要实现一个ztunnel对节点所有Pods的代理，配置复杂度更是上升一个数量级，同时配置的复杂意味着处理流程的增加，也会对数据面的排错以及整体性能造成影响；4. 其他：ztunnel的高可用？waypoint事实上将原本双端的L7处理变为了单端，对L7监控指标正确性的影响？…▎未来展望从版本发布的角度，自从2022年9月份发布以来，Ambient Mesh一直作为实验特性存在于独立的分支之中。因此对于Ambient Mesh下一步的计划就是合入主干分支（已于2023年2月实现）并作为Alpha特性发布，最终在2023年底到达Stable，实现生产可用。从API的角度，最理想的是能在两种架构下共用同一套API。当然这是不现实的，因为已有的一部分Istio API是以Sidecar模式部署为前提条件设计的。最典型的就是Sidecar这个CRD，它用于定制化下发至不同Sidecar的配置，从而减少Sidecar不必要的资源占用。这些Sidecar-Only的API显然在Ambient Mesh下毫无意义。同时，Ambient Mesh自身也引入了ztunnel和waypoint两个独有组件，因此Ambient Mesh也需要创建新的API，用于管理这些独有组件以及实现一些Ambient Mesh Only的功能。最终Ambient Mesh会实现已有的核心Istio API（VirtualService, DestinationRules等）并创建一些其独有的API，重要的是做到三类API（Sidecar模式独有、Ambient Mesh独有、两者共有）统一的使用与交互。那么Ambient Mesh是否做到了对Sidecar模式使用场景的全覆盖，从而让Sidecar模式彻底退出历史舞台了呢？答案自然是否定的，类似于业界各种独占模式和共享模式之争，Sidecar模式本质上是应用Pod对Proxy的独占。专属的Proxy往往能保证更好的资源可用性，尽量避免其他应用的影响，确保高优先级应用的正常运行。可以预见，最终两种模式的混合部署，应用按需选择代理模式是更为理想的方式。所以构建混合部署模式，保证该模式下两种模式的良好兼容性和统一的体验也将是后续工作的重点。▎总结Sidecar模式对于Istio就像一场原型验证，以一种最Kubernetes Native的方式快速展示网格技术的价值，抢占用户认知和市场。不过随着Istio的落地逐渐进入深水区，开始在生产环境大规模部署，Sidecar模式就显得力不从心了。此时Ambient Mesh以一种更符合大规模落地要求的形态出现，克服了大多数Sidecar模式的固有缺陷，让用户无需再感知网格相关组件，真正将网格下沉为基础设施。但是显然Ambient Mesh并不是网格数据面架构演进的终点。当前还没有一种网格数据面方案能在侵入性、性能、资源占用等各个考量维度做到完美。Ambient Mesh基本做到了对应用的零侵入，但是L7的三跳处理引发的性能问题，ztunnel等常驻进程的资源占用令人无法忽视；gRPC等RPC库通过内置实现xDS，直连Istio控制面，将网格杂糅进SDK，确实能实现很好的性能和资源占用表现，只是不可避免地需要付出与应用强耦合、多语言支持复杂度高等固有代价；基于eBPF直接将全套网格数据面功能像TCP/IP协议栈一样下沉到内核貌似是理想的终局方案，只是考虑到内核安全以及与内核交互的复杂性，eBPF的执行环境其实是非常受限的，例如eBPF程序加载到内核前必须经过verifier的校验，执行路径必须完全已知，无法执行任意的循环。因此对于HTTP/2，gRPC等复杂的L7处理，基于eBPF的开发和维护都会比较困难。考虑到基础设施对性能、资源损耗的极致要求以及过往相关技术的演进规律，例如对于基础网络，绝大多数应用共享使用内核协议栈即可，部分特殊应用利用DPDK，RDMA等专用技术进行加速。同样，对于网格数据面，多种技术结合，分别优化相应场景的解决方案，可能是更具可行性的。可以预见，这类方案基本上是以类Ambient Mesh的节点级代理作为主体，随着网格以及eBPF技术的发展，将尽量多的网格数据面功能下沉至eBPF（Fast Path）实现；少部分高级功能交由用户态的Proxy（Slow Path）实现；那些对性能、隔离性等有较高要求的应用，则为其部署专属的Sidecar。这样一来，就能满足绝大多数场景下，对侵入性、性能、资源占用等各个维度的要求。综上 ，最终是一套数据面方案一统天下，还是各种方案混合部署，取各家所长，仍有待对相关技术不断探索演进，再用实践检验，最后让时间告诉我们答案。参考文献[1] Istio Ambient Mesh Explained: https://lp.solo.io/istio-ambient-mesh-explained[2] What to expect for ambient mesh in 2023: https://www.solo.io/blog/ambient-mesh-2023[3] Introducing Ambient Mesh: https://istio.io/latest/blog/2022/introducing-ambient-mesh[4] Get Started with Istio Ambient Mesh: https://istio.io/latest/blog/2022/get-started-ambient

作者：华为云云原生团队▎边缘计算安全防护的实践与洞察随着开源软件安全漏洞持续引起世界各地政府和企业的关注，越来越多的组织、开发人员、研究人员和安全专家投入到开源安全工作中，在各方力量的推动下，开源安全目前已初步形成体系化的生态大网，覆盖了国际化的软件工程行业标准、安全评估体系、安全工具链与整体解决方案等，并逐步撬动整个业界开源软件安全行业的生态产业链。在2020年Linux基金会与多家硬件和软件厂商合作创立了开源软件安全基金会OpenSSF（Open Source Security Foundation），这是一个跨行业的合作组织，汇集了行业领军企业与机构，涵盖世界上最重要的软件供应链安全计划、开源开放的工具链、安全指南、培训等，旨在提高开源软件（OSS）的安全性。作为业界首个云原生边缘计算项目，KubeEdge社区致力于提升KubeEdge在云原生边缘计算场景下的安全性，将安全视为社区发展的重要指导原则。社区充分结合了业界的开源安全经验，于2022年7月完成了对KubeEdge项目的安全威胁模型分析。尽管云原生边缘计算的安全问题备受用户关注，但业界目前缺乏相关的安全威胁模型分析，这使得用户难以有效地加固其边缘系统。因此，KubeEdge社区发布了安全威胁模型及分析白皮书，为用户和厂商提供了重要的安全实践指导。下文将着重介绍Kubeedge在安全防护方面的实践，并介绍OpenSSF在开源软件安全方面的计划与目标。▎KubeEdge安全防护安全防护背景KubeEdge在边端云协同领域正在加速布局，已在智慧交通、智慧城市、智慧园区、智慧能源、智慧工厂、智慧银行、智慧工地、CDN等行业提供一体化的边端云协同解决方案。随着越来越多的用户将KubeEdge项目用于生产环境中， KubeEdge社区把安全问题放在优先地位，并成立Sig- Security 和安全团队 ，负责KubeEdge的系统安全设计，并快速响应和处理安全漏洞。为了对KubeEdge项目进行更加全面的安全评估，KubeEdge社区联合ADA LOGICS公司、OSTIF及云原生计算基金会（CNCF）对KubeEdge项目进行安全评估并输出安全评估报告，分析和总结KubeEdge项目的安全威胁模型及相关安全问题。该评估对KubeEdge项目的安全防护有重要的指导意义，感谢ADA LOGICS公司的专家Adam Korczynski和David Korczynski在该项工作中的巨大贡献，同时，感谢OSTIF的Amir Montazery和Derek Zimmer以及CNCF基金会，他们对这次评估提供了很大帮助。对于安全报告中发现的安全问题，KubeEdge社区已根据社区的漏洞处理策略第一时间完成修复，并针对v1.11、v1.10、v1.9三个版本发布了安全补丁，版本号分别为v1.11.1、v1.10.2和v1.9.4，漏洞公告已发布在cid:link_4。接下来将通过解读KubeEdge威胁模型，为边缘计算领域提供更多的安全防护经验，并在开源软件供应链安全加固工作上为更多的开源社区提供参考。威胁模型分析KubeEdge的安全审计报告指出，该系统可能受到外部攻击、内部操作人员的不当操作和供应链攻击等三种潜在攻击类型的影响。本章节使用STRIDE威胁建模方法，结合安全审计报告对KubeEdge进行了系统的安全分析，包括上述三个方面。目的是帮助开发者和用户了解系统中的潜在安全威胁、明确风险并列举出目前KubeEdge社区已有的消减机制和安全加固建议。以下人群使用KubeEdge过程中，了解KubeEdge的威胁模型分析和可能的缓解措施将对他们的工作有所帮助：• KubeEdge的贡献者：一个通用的威胁模型对KubeEdge贡献者很有用，他们可以从整体角度考虑并加固他们的系统。• 部署KubeEdge的组织：对于在集群中使用KubeEdge的组织来说，了解常见的攻击和可能的弱点是很有用的，这样他们就可以检查和评估自己的配置。• 安全评估员：负责评估KubeEdge及所属Kubernetes集群的安全性。通过了解该威胁模型，让安全评估员可以对系统的安全风险进行更加全面的评估。• KubeEdge的用户及其开发人员：需要了解KubeEdge的更新和攻击，以主动避免未来可能发生的安全风险。外部攻击分析根据STRIDE威胁建模方法对KubeEdge潜在的外部攻击进行分析，对应的数据流图如下。如数据流图所示，当数据流穿越不同的信任级别（区域）时，就存在信任边界，已在图中用红框标出。下面将详细分析KubeEdge系统架构中的信任边界（引用自KubeEdge第三方安全报告）、社区已有的消减措施并给出安全加固建议。威胁一：云端CloudCore组件与EdgeCore组件之间的连接描述：该威胁涉及边缘EdgeCore与云端CloudCore之间的连接。在这个数据流中，较低信任级别组件EdgeCore向较高信任级别组件CloudCore发起访问。由于EdgeCore在系统中拥有独立的权限级别，攻击者控制EdgeCore后，不应该能够对其他边缘节点造成负面影响，例如通过攻击和操控CloudCore来攻击其他节点（该漏洞描述引用自安全评估报告）。影响：攻击者恶意修改CloudCore与EdgeCore组件之间的请求和应答报文，导致通信过程存在仿冒和篡改的威胁风险。消减措施：• CloudCore与EdgeCore之间的通信通过数字签名证书加密和服务端/客户端双向认证的方式保障信息交互的机密性和完整性，安全加密协议使用TLS 1.2，且指定加密算法套件白名单，防止客户端使用不在白名单中的不安全算法进行通信造成安全风险；• 证书默认有效期为一年，过期后失效，防止证书被攻击者利用。用户基于KubeEdge项目已有的证书轮转机制，可以实现证书过期自动更换，保障业务连续性。针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 1和2）。威胁二：边缘组件ServiceBus在本机范围内提供HTTP服务描述：边缘组件ServiceBus监听本地local host端口并在本机范围内提供HTTP服务。该数据流中，较低信任级别的用户应用进程向较高信任级别组件ServiceBus发起访问。如果发起攻击，不应该使攻击者能够将影响范围扩大到云端控制面（该漏洞描述引用自安全评估报告）。影响：ServiceBus组件收到的数据往往是不受管理面控制的，攻击者能够对ServiceBus组件发起恶意报文攻击，导致通信过程存在仿冒和篡改的威胁风险。ServiceBus组件异常仅影响单个边缘节点服务故障，不会导致整个KubeEdge系统崩溃。消减措施：• ServiceBus组件仅监听本地local host端口，已限制服务范围，只允许本机进程访问，通过对本机用户访问权限的限制保障本组件安全；• 服务端接收客户端连接时记录连接访问的日志，可作为审计日志，可以让管理员及时发现攻击的发生，并及时停止ServiceBus服务，阻止攻击继续进行；• ServiceBus服务默认关闭，遵守默认安全的原则。在用户使用文档中已明确提示用户如果开启该服务，则存在上述风险。针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 3、4和5）。威胁三：边缘端Device通过MQTT Broker连接到EdgeCore描述：边缘device设备通过MQTT Broker（集成在EventBus组件中）连接到EdgeCore。该数据流中，较低信任级别的用户device设备向较高信任级别组件EdgeCore发起访问（该漏洞描述引用自安全评估报告）。影响：EdgeCore组件收到的数据往往是不受管理面控制的，攻击者能够对MQTT Broker发起恶意报文攻击，存在仿冒和篡改的威胁风险。如果发起攻击导致EventBus组件异常，异常仅影响单个边缘节点服务故障，不会导致整个KubeEdge系统崩溃。消减措施：• MQTT Broker仅监听在本机端口，已限制服务范围，只允许本机进程访问，通过对本机用户访问权限的限制保障本组件安全；同时，EventBus组件可作为客户端，对接外置第三方MQTT Broker，如果用户使用第三方MQTT Broker，详细的消减措施请参考对应第三方MQTT Broker服务提供厂商的安全文档。• EventBus仅对MQTT Broker中的特定Topic进行处理，用户无法通过该通道对EdgeCore任意访问。针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 3、4、5和6）。威胁四：Edged管理和监控Pods及其他K8s资源描述：Edged管理和监控Pods及其他K8s资源。该数据流中，较低信任级别的应用容器与较高信任级别组件EdgeCore之间进行数据交互。如果主动发起连接时，被恶意服务器攻击，不应该使攻击者能够将影响范围扩大到云端控制面（该漏洞描述引用自安全评估报告）。影响：如果Edged访问的CRI插件被攻击者恶意伪造，则存在CRI插件仿冒和篡改的威胁风险，导致本地业务异常。消减措施：• Edged与CRI插件通信时，只在本地访问受信任路径，由管理员控制访问路径，最小化Unix domain sockets文件描述符的权限，避免被仿冒者恶意替换。针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 3和7）。威胁五：MetaServer在边缘节点提供HTTP服务描述：MetaServer作为边缘“api-server”，对边缘插件提供HTTP服务。该数据流中，较低信任级别的用户应用插件向较高信任级别组件MetaServer发起访问（该漏洞描述引用自安全评估报告）。影响：MetaServer组件收到的数据往往是不受管理面控制的，攻击者能够对MetaServer组件发起恶意报文攻击，导致通信过程存在仿冒和篡改的威胁风险。MetaServer组件异常仅影响单个边缘节点服务故障，不会导致整个KubeEdge系统崩溃。消减措施：• MetaServer组件仅监听本地local host端口，已限制服务范围，只允许本机进程访问，通过对本机用户访问权限的限制保障本组件安全；• MetaServer服务默认关闭，遵守默认安全的原则。在用户使用文档中已明确提示用户如果开启该服务，则存在上述风险。针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 3、4和5）。内部攻击分析对于内部管理员或操作人员，可能的风险主要包括管理员或操作人员错误操作将恶意软件部署至集群中、在高风险场景中执行高风险配置等。消减措施：• KubeEdge用户手册中已提供各个组件的详细功能描述及配置使用指导文档 ，指导系统管理员或操作人员正确操作，减少人为误操作或误配置导致的安全风险。由于KubeEdge的持续迭代，该文档也将持续更新并完善。针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 3、4、8和9）。供应链攻击分析攻击可能发生在典型软件供应链的每一个环节，而且在当今环境中，这些类型的攻击越来越公开，破坏性和代价高昂。攻击方向包括源代码完整性、构建完整性和构建产物的可用性。消减措施：• 社区联合安全公司对KubeEdge软件供应链流程已进行SLSA等级评估，并引入SLSA软件供应链安全评估框架，包括对源代码、构建流程、依赖库等进行安全评估，防止针对软件供应链的攻击，从源头上保障软件供应链的安全。值得一提的是，在2023年1月18日发布的v1.13.0版本中，KubeEdge项目已达到SLSA L3等级（包括二进制和容器镜像构件），成为CNCF社区首个达到SLSA L3等级的项目，并加入Sigstore生态系统，实现更高等级的安全标准。• KubeEdge仓库CI/CD流水线中已开启dependence bot第三方依赖库检查功能，及时发现第三方依赖库的安全漏洞并在KubeEdge版本中同步更新，降低被攻击的风险；• KubeEdge security team已具备完整漏洞处理机制，包括漏洞发现、漏洞上报、漏洞分析处理、漏洞披露和发布整个流程，可以及时处理和修复安全漏洞。详细漏洞处理及披露策略请见https://github.com/kubeedge/community/blob/master/security-team/SECURITY.md。针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 10和11）。安全加固建议列表Recommendation ID描述1使用安全长度的私钥加密，并加密保存私钥。建议用户生成至少为2048位私钥，且在本地加密存储私钥，存储私钥的文件设置最小化的访问权限，仅属主可读。2使用可信来源的CA证书。从可信的CA获取数字证书，不使用自签名证书。3严格限制边缘节点的本机权限，限制外部用户的用户登录权限，减少非必要的授权。4严格限制边缘节点应用部署的权限，只有系统服务和管理员才能拥有部署特权容器的权限。5在边缘节点部署应用时，严格校验应用镜像的合法性，防止部署恶意应用。6对于接入边缘节点的Device设备进行严格审核，避免非必要设备接入。7严格审查CRI插件的配置，使用CRI对应插件的官方推荐配置。8严格划分系统中各个角色权限，通过RBAC、OPA等方式实现系统角色权限的细粒度控制。9社区发现漏洞后将在最近的3个minor release版本中合入解决，用户可以关注社区security advisory 获取漏洞披露信息，及时跟进并更新KubeEdge版本。10用户使用社区发布的二进制文件前，应该根据社区发布的校验文件进行严格校验，防止二进制被仿冒和篡改。社区release软件包发布地址cid:link_6。11用户或vendors在使用源代码构建过程中，应该参考SLSA软件供应链安全评估框架，对源代码、构建流程、依赖库等进行安全加固。开源安全洞察本章节通过对OpenSSF社区的战略规划、OpenSSF工作组内容及开放源代码软件安全动员10个TOP计划进行介绍，为相关从业人员、开源生态产业提供参考。1) OpenSSF介绍社区工作组为了更好的提升开源软件安全，OpenSSF目前已成立了8个工作组，主要负责开源软件开发最佳实践、软件代码安全、用户、安全工具链、开源项目安全威胁识别、软件供应链完整性、保护关键开源项目、漏洞披露。相关项目1. OpenSSF最佳实践徽章（OpenSSF Best Practices Badge Program）开源软件开发的最佳实践目的是提供开源开发者安全相关行业标准、框架、安全指导、课程、开源安全评估体系、包括工具支持开发人员日常开发过程的软件安全检测。开源项目可以通过OpenSSF最佳实践徽章项目进行最佳实践评估，该项目是自由/开源软件（FLOSS）项目展示其遵循最佳实践的一种方式。可以通过使用这个网站来解释他们如何遵循每个最佳实践，从而自愿地进行自我认证，认证分为通过、银、金三个级别，不需要任何费用。该项目是基于核心基础设施倡议（CII）项目发展而来。2. 积分卡（Scorecards）通过Scorecards积分卡项目可以实现自动化地对开源项目相关安全指标进行评估，以加强项目的安全状况，根据项目的评估结果给出0-10分数，帮助项目maintainer改进项目安全。3. 安全知识框架（Security Knowledge Framework）SKF是一个完全开源的Python-Flask / Angular网络应用程序，它使用许多其他的开源项目来训练你和你的团队通过设计来构建安全的应用程序。其涵盖了整个软件开发生命周期如构建、测试、需求、设计、代码开发、度量、培训等环节。4. 安全开发指南提供安全开发、安全评估的详细指导步骤，以开发者使用视角将上面的项目全部串接起来，已完整覆盖了OpenChain Security Assurance Specification、SLSA、工具如 GitHub's dependabot、GitLab dependency scanning、Scorecards check等。5. 教育与培训课程提供开发人员免费的安全开发课程，完成学习后可以发放证书有效期2年。6. 软件构建供应链级别（SLSA）软件构建的供应链级别SLSA由Google贡献给OpenSSF，是软件供应链完整性的安全标准准则，以帮助企业和开源生态确保软件开发生命周期的安全，ScoreCards是SLSA度量的工具组成部分。7. 令牌分发项目Great Multi-Factor Authentication (MFA) 分发项目。致力于将硬件 MFA 令牌分发给关键的 100+开源软件项目，目标是防止开源软件开发凭据薄弱或受损的供应链攻击。8. 包管理最佳实践提供业界主流的构建框架、包管理器的最佳实践如 maven、gradle、npm、pip、RubyGems，重点介绍其依赖管理、可重复构建、发布、基于包管理的漏洞披露等。当前文档还不完善，只重点介绍了npm，其它的包管理器待建设中。9. C/C++编译选项制定 C/C++场景的编译选项规则，避免潜在的安全风险和被攻击的风险。当前在孵化阶段。10. 开源社区安全教育SIG当前在孵化阶段，主要致力于提供行业标准的安全软件开发相关的培训材料，提供网络和应用程序安全方面的最佳实践辅导开发人员安全地创建、编写、部署和维护软件。OpenSSF安全工具链安全领域涉及面广，规则规范多，开发人员甚至从事资深安全工作的专家人工识别冗余遗漏。安全工具链用于快速识别安全风险，使开发人员专注于功能特性开发。覆盖范围：涵盖整个DevSecOps的各环节工具链，并支撑开源软件开发的最佳实践章节，如：linters(cleanCode), SAST, SCA, DAST, Fuzzers, Hard Coded Secrets Detectors, and SBOM generators。提供方：部分来自公司捐赠，部分来自OpenSSF基金会自主规划，部分在规划阶段待建设。2) 开源软件安全动员计划及目标2022 年 1 月，美国政府专家、 OSS 基金会、相关企业在白宫举行会议讨论，制定如下三个动员计划的总体目标：• 保护 OSS 生产：首先是专注于防止安全缺陷、代码和开源包漏洞• 改进漏洞识别和修复：改进缺陷识别过程、漏洞修复• 缩短补丁响应时间：缩短漏洞披露和修复时间在2022年5月第二届开源软件安全峰会上，Linux基金会、OpenSSF及各行业安全专家，就提高开源软件安全性计划达成共识，将集中在以下10个方向进行投资和安全改善，项目投资1.5亿美元，分为两年规划。备注：动员计划和OpenSSF工作组是相辅相成的，其动员计划的能力会融入到工作组中。投资方向描述安全培训向所有人提供基础安全软件开发培训和认证。风险评估为前 10,000 个（或更多）OSS 组件建立一个公开的、供应商中立的、客观的、基于指标的风险评估仪表板。数字签名加快在软件版本上采用数字签名。内存安全通过替换非内存安全语言来消除大多数漏洞的根本原因。事件响应建立一个由安全专家组成的 OpenSSF 事件响应团队，以协助开源项目加快对新发现漏洞的响应速度。安全扫描通过高级安全工具和专家指导，加快维护人员和专家发现新漏洞的速度。代码审计每年对200+个最关键的OSS组件进行一次第三方代码审查（以及任何必要的补救工作）。数据共享协调全行业的数据共享，以改善研究，帮助确定最关键的开放源码软件组件。SBOMs改进SBOM工具和培训，以推动采用。提升软件供应链安全用更好的供应链安全工具和最佳实践来增强10个关键的开放源码软件构建系统、软件包管理器和分发系统。▎总结本文通过从外部攻击面、内部攻击面及软件供应链三个维度对KubeEdge项目进行安全威胁建模，实现对KubeEdge项目的系统性安全评估，帮助社区maintainer及时发现和修复安全风险。同时，对业界OpenSSF社区开源安全策略及相关项目进行洞察，通过洞察分析可以看出，越来越多的组织、开发人员、研究人员和安全专家将加大投入资源来加强开源安全，并已逐步形成业界开源安全行业的生态产业链，在开源安全上占据标准高地可以为后续的商业扩展提供有力地位。KubeEdge社区结合业界安全理念，将能够推动社区持续巩固和演进项目的安全。▎附录相关链接• 社区漏洞处理机制: cid:link_5• 安全审计报告: cid:link_1• 社区security advisory链接: cid:link_4• KubeEdge威胁模型及安全防护分析（本文档）: cid:link_0• 社区用户文档链接: https://kubeedge.io/en/docs• SLSA软件供应链安全框架: https://slsa.dev/spec/v0.1/#supply-chain-threats• KubeEdge实现SLSA L3分析: https://kubeedge.io/en/blog/reach-slsa-l3/• Release版本发布链接: cid:link_6• 开源软件安全动员计划：https://cta-redirect.hubspot.com/cta/redirect/8112310/3b79d59d-e8d3-4c69-a67b-6b87b325313c• OpenSSF最佳时间徽章：https ://bestpractices.coreinfrastructure.org/en• 最佳实践项目：https://github.com/ossf/wg-best-practices-os-developers添加小助手微信k8s2222，进入云原生交流群