• [区域初赛赛题问题] 请问三等奖证书什么时候发呀
    请问三等奖证书什么时候发呀
  • [热门活动] KubeCon 巴黎|与华为云一起,共创 CloudNative × AI 未来
    更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群
  • [热门活动] 直播预告 | CCE Autopilot:华为云容器全面进入“自动驾驶”时代
    还在为K8s集群繁琐的资源管理投入大量的运维时间和人力?还在担心K8s集群节点伸缩不够及时或者不合理导致成本浪费?华为云Serverless K8s服务 CCE Autopilot通过资源全托管的方式让基础设施免运维,为用户节省运维成本,通过高效精准的弹性灵活应对业务的平峰和洪峰,为用户节省资源成本。3月13日16:30 -18:00,华为云云原生DTSE技术布道师颜栎将带来《CCE Autopilot:华为云容器全面进入“自动驾驶”时代 》直播分享。本期直播将聚焦企业集群运维痛点提供Serverless最新方案,系统化介绍华为云CCE Autopilot带来的全新集群服务体验。使用华为云CCE Autopilot进行集群节点全托管,无需配置和运维基础设施,帮你自动部署、扩展和管理容器化应用程序,高效构建业务,运维效率提升90%。华为云CCE Autopilot,应运而生的Serverless K8s服务资源设施全托管,节点免运维,降低运维成本,让用户聚焦业务创新;资源精益管理,通过FinOps提供成本治理能力,提升资源利用率,降低资源成本;业界领先弹性速度,4,000Pod/30s,高效弹,精准弹,灵活应对业务洪峰和平峰,实现稳敏双修;面向不同场景提供通用负载、SMB(中长尾)负载、AI负载、Batch负载的场景化调优能力;直播观看平台华为云官网 华为云开发者联盟视频号、CSDN、B站、虎牙、微博华为云视频号、快手、B站、虎牙、微博▍本期直播精彩看点CCE Autopilot,提供业务运行最优的云原生基础设施:1. 集群节点全面托管,基础设施自动升级。2.故障实时监测与自愈,漏洞自动修复。集群管理“无极变速”:1. 集群规格自动调整,取消规格档位限制。2. 资源使用“无级变速”,算力资源灵活规格档位,去Flavor化。智能弹性,动态感知业务特征,自动预测触发弹性华为云CCE Autopilot提供Serverless服务体验的同时,保留了用户对资源的可见性满足了部分客户对资源灵活管理的需求。此外,CCE Autopilot完全兼容K8s接口,及时跟随K8s社区动态,用户可以从普通的K8s集群平滑迁移到CCE Autopilot,立即省去节点运维投入。扫描下方二维码体验华为云CCE Autopilot▼▼▼
  • [分享交流] 码豆商城的礼物一直没有,码豆时常过期了,也没见有东西可兑换。是不是码豆没啥用了?
    码豆商城的礼物一直没有,码豆时常过期了,也没见有东西可兑换。是不是码豆没啥用了?
  • [热门活动] 【云原生专题直播有奖提问】DTSE Tech Talk 技术直播 NO.53:看直播提问题赢华为云定制键盘、华为云定制U型按摩枕等好礼!
    中奖结果公示感谢各位小伙伴参与本次活动,欢迎关注华为云DTSE Tech Talk 技术直播更多活动~本次活动获奖名单如下:请于3月20日下班前在此问卷中反馈您的中奖邮寄信息~直播简介【直播主题】CCE Autopilot:华为云容器全面进入“自动驾驶”时代【直播时间】2024年3月13日 16:30-18:00【直播专家】颜栎 华为云云原生DTSE技术布道师【直播简介】华为云容器已全面进入“自动驾驶”时代! CCE Autopilot为你带来基于Serverless基础设施的企业级Kubernetes集群服务,集群节点全托管,无需配置和运维基础设施,运维效率提升90%。提供应用智能调度,极致弹性等管理编排能力,帮你自动部署、扩展和管理容器化应用程序,高效构建业务。观看直播:cid:link_1活动介绍【互动方式】直播前您可以在本帖留下您疑惑的问题,专家会在直播时为您解答。直播后您可以继续在本帖留言,与专家互动交流。我们会在全部活动结束后对参与互动的用户进行评选。【活动时间】即日起—2024年3月14日【奖励说明】评奖规则:活动1:直播期间在直播间提出与直播内容相关的问题,对专家评选为优质问题的开发者进行奖励。奖品:华为云定制键盘活动2:在本帖提出与直播内容相关的问题,由专家在所有互动贴中选出最优问题贴的开发者进行奖励。奖品:华为云定制U型按摩枕更多直播活动直播互动有礼:官网直播间发口令“华为云 DTSE”抽华为云定制雨伞、填写问卷抽华为云定制Polo衫等好礼。【注意事项】1、所有参与活动的问题,如发现为复用他人内容或直播间中重复内容,则取消获奖资格。2、为保证您顺利领取活动奖品,请您在活动公示奖项后2个工作日内私信提前填写奖品收货信息,如您没有填写,视为自动放弃奖励。3、活动奖项公示时间截止2024年3月15日,如未反馈邮寄信息视为弃奖。本次活动奖品将于奖项公示后30个工作日内统一发出,请您耐心等待。4、活动期间同类子活动每个ID(同一姓名/电话/收货地址)只能获奖一次,若重复则中奖资格顺延至下一位合格开发者,仅一次顺延。5、如活动奖品出现没有库存的情况,华为云工作人员将会替换等价值的奖品,获奖者不同意此规则视为放弃奖品。6、其他事宜请参考【华为云社区常规活动规则】。
  • [区域初赛赛题问题] 一些不太懂的问题
    这个练习赛当日的maps不能公布文件嘛/ll以及,这个数据是在范围内纯随机吗/ll
  • [问题求助] AI原生应用引擎可以进行低码应用开发吗?
    AI原生应用引擎可以进行低码应用开发吗?
  • [问题求助] AI原生应用引擎的优势是哪些?
    AI原生应用引擎的优势是哪些?
  • [公告] 华为云云原生专家入选全球顶级开源组织CNCF技术监督委员会
    全球顶级开源组织云原生计算基金会(Cloud Native Computing Foundation,简称 CNCF)正式宣布其2024年技术监督委员会(Technical Oversight Committee,简称CNCF TOC)席位,华为云云原生开源负责人王泽锋,凭借其在CNCF领域长期卓越的贡献成功当选,成为本届 CNCF TOC 11位技术领军人物之一。CNCF致力于云原生技术的普及和可持续发展,汇集世界顶级厂商,发展至今会员单位已超过750+。CNCF技术监督委员会是CNCF的核心决策团队,为云原生社区提供技术领导,决定CNCF社区的技术走向,由董事会、Maintainer以及End User等多个选区投票产生。一直以来,CNCF TOC主要以欧美专家为主,本届选举中,华为云开源专家王泽锋获得CNCF Maintainer广泛支持,凭借Maintainer选区最高票当选新一届CNCF TOC委员(2024-2026任期)。这也标志着其个人及华为在云原生领域的持续贡献获得产业界的高度认可,代表了整个中国本土贡献者在国际舞台上开源影响力的新高度。云原生产业规模和前景巨大,不少技术领域仍然处于窗口期,可谓机遇与挑战并存。王泽锋表示:“中国在全球云原生产业发展中拥有非常明显的优势:巨大的数字经济规模、丰富的应用场景,不断推动技术层面的创新;不少本土科技公司凭借技术实力已在云原生的核心赛道中占据了重要位置。作为CNCF TOC的新任成员,我将致力于更好地联接国内以及国际开源社区,借助CNCF、华为等平台及资源,携手更多企业、开源组织、学术机构及广大开发者一起,共同推动云原生技术发展与产业标准化,赋能千行万业的数字化转型。”王泽锋:协作创新,共建更有生命力的开源社区作为最早来自中国的Kubernetes维护者之一,王泽锋早在2014年基于 Upstream first 的理念,参与 Kubernetes 上游社区贡献,并于2015年成为了国内最早的 Kubernetes maintainer 之一,其主导的 Kubernetes 社区的多个关键特性和子项目的设计研发工作在社区完成开发后被大量企业用户在生产环境中广泛使用;与此同时,他指导了超过30名开发人员成为Kubernetes和其他CNCF项目的业务骨干、核心开发者。2018 年,王泽锋与同事联合创立了业界首个云原生边缘计算项目KubeEdge 开源项目,并捐赠到 CNCF 基金会,通过开放社区的治理模式与业界开发者协作共享。KubeEdge 也因此成为 CNCF 第一个将云原生技术应用到边缘计算的开源项目。时至今日,KubeEdge 在交通、能源、通信、金融、工业制造、CDN、智慧园区等各行各业已经有了更加深广的应用和普惠价值。此外,他还发起了 Volcano云原生批量计算 、Karmada云原生多集群管理 等多个云原生开源项目,填补了云原生技术在相关领域的技术空白。作为CNCF中国大使,王泽锋在KubeCon + CloudNativeCon 程序委员会任职多年,并于 2023 年担任 KubeCon + CloudNativeCon China 联合主席。作为公认的演讲者,王泽锋多次在 KubeCon Europe 和 KubeCon China 上发表Keynote和分论坛议题演讲。此外,王泽锋一直是Kubernetes贡献者峰会的长期支持者,联合规划和组织多场KCS China、KCD,并从2018年开始,联合策划了 “Cloud Native Days China”系列 Meetup、“Cloud Native Lives”等一系列业内活动;与此同时,由他发起的系列云原生技术公共课程,帮助超过百万的中国开发者构筑云原生技术交流平台,学习和采用云原生技术。技术先驱,引领全球云原生生态圈作为CNCF亚洲唯一创始成员、白金成员,华为对 Kubernetes、Istio 等社区核心项目的贡献一直位居全球前列,社区影响力持续多年亚洲第一,加速了云原生技术从起步到成熟的过程;华为拥有10余位CNCF项目核心Maintainer,出版多部云原生领域技术书籍,是全球云原生开源技术的领导者之一。近年来,华为持续开源创新,先后向CNCF捐献业界首个云原生边缘计算项目KubeEdge、首个云原生算力调度引擎Volcano、首个多云容器编排引擎Karmada等重量级云原生项目,在网络、边缘、调度、多云等技术领域形成了相对成熟生态圈,并开源了Kurator、Kappital、Kuasar、Kmesh等创新项目,加速了云原生与边缘计算、AI、大数据等产业的融合。共享开源价值,为行业发展注入源生动力在数字经济快速演进的大背景下,开源作为数智化转型的创新驱动力,不断催生技术突破和业务创新,发挥出愈加凸显的价值。华为与业界分享生产实践经验及创新成果,与国际云原生社区共发展。未来,面向全球的云原生社区工作有何创新?王泽锋提出了他对CNCF TOC的愿景和其独特的价值:促进跨区域新贡献者和现有贡献者之间的经验分享和沟通。建立公共的维护者地图,帮助新加入的贡献者找到周围的维护者以获得支持和帮助,以新一代的维护者增进社区活力,促进项目的可持续性。建立项目导师和项目冠军机制,帮助加快新开源项目向CNCF的申请/引导过程,以及项目在CNCF沙盒和孵化器中的成长。更清晰的项目推进过程和相应的自动化工具,以减少项目维护者和TOC/TAG成员在观察和评估项目健康和项目成熟度方面所花费的时间。云原生+AI,开源加速构建AI基础设施面对AI时代迎面而来的挑战,华为云在云原生领域持续引领,打造多云场景下的AI云原生基础设施,加速构建AI时代最佳云底座。作为全球最早参与CNCF重点项目产品化的企业之一,华为云早在2015年基于Kubernetes、Istio等上游社区,推出了国内最早的商用容器产品,并于2016年发布国内首个公有云容器服务CCE(云容器引擎)。伴随华为云近年来的高速发展,目前华为云已经陆续发布Serverless容器CCI、应用服务网格ASM、智能边缘平台IEF、分布式云原生UCS等多个创新产品,连续七次登顶IDC发布的中国容器市场份额报告,这也是业界对华为云在容器领域一路领先给与的充分肯定。智能浪潮新形势下,华为云结合在云原生领域的领先优势,打造云原生多云融合基础设施,云原生AI基础设施,云原生Serverless基础设施等系列解决方案,陆续升级发布华为云CCE Turbo,华为云CCE Autopilot,Serverless云耀云容器等创新产品。由华为云开源并捐赠至CNCF的孵化级开源项目也在AI云边协同、AI混部调度、多集群算力分配等技术领域加速行业产品应用升级,为行业智能升级攻坚克难,注入源生动力。未来,华为云云原生将持续与全球开发者紧密合作,共同推进云原生技术的创新与发展,积极推动云原生技术在产业领域的深度融合应用,为促进全球数智化经济的繁荣发展贡献力量。更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群
  • [行业前沿] 亿级月活游戏《迷你世界》全栈容器化实践分享
    作者:本文由华为云客户迷你玩投稿背景迷你玩旗下《迷你世界》是一款国产沙盒创意平台,拥有全球数千万创作者进行去中心化内容创作,通过方块组合自由创造等方式,引导用户在平台上创作虚拟作品。2021《迷你世界》的每月活跃玩家人数已超过一亿。《迷你世界》此前面临的突出问题在于服务端的弹性:迷你世界服务器的规格较大,每个服务器上承载了很多游戏服进程,不同玩家的游戏时间上差异也比较大,为了保障深度玩家的游戏体验,即使只有一个玩家还在进行游戏,对应的游戏服务器也是不会缩容的,这必然会影响服务端整体的资源利用率和运营成本。我们期望通过容器灵活规格来解决《迷你世界》服务端的缩容问题,同时提升整个游戏系统的扩缩容、部署升级效率。挑战云原生技术以其灵活性、可扩展性和可维护性等优势,正在迅速改变企业的 IT 架构。第三方报告显示,2022年已经有超过75%的互联网公司在基于K8s部署生产业务,预期2025年这个数字将超过90%。然而在游戏场景中,k8s的还面临一些局限性。首先,游戏业务天然是有状态的,K8S原生的有状态资源StatefulSet并不擅长处理大量的、复杂的状态管理任务。其次,时延敏感性也是一个问题。在游戏中,时延直接影响到游戏的流畅度和玩家的体验,这就对K8s的容器网络实现提出了更高的要求。同时,安全性也是一个挑战。游戏服中可能包含大量的敏感信息,普通容器的隔离程度与虚拟化相比仍有一定差距。解决方案华为云CCE在网络、容器运行时上进行了增强,再配合社区workload,使能《迷你世界》后端全栈容器化,资源使用量较虚拟化部署环境减少了50+%。整体架构如下:网络方面,华为云CCE Turbo提供了一种更接近虚拟机的容器网络,这种模式下,容器成为和虚拟机等同的“一等公民”。容器网卡集成了虚拟网络的能力,比如通过CRD关联到安全组进行安全加固,更细粒度的IP地址管理等。更重要的是,这种容器网络支持Pod直接关联EIP,用户可以直接通过EIP访问应用。EIP的成本管理上,华为云提供了95计费的共享带宽,以多个EIP共享的带宽为计费单元。我们开发了专门的K8s webhook为不同的pod分配不同的共享带宽,来做到最优的成本控制。有状态应用管理方面:我们使用了OpenKruise社区的CloneSet来管理游戏服pod。CloneSet提供了pod的原地升级能力,可以在不重建pod的情况下对运行中的容器进行更新。我们还深度使用了它的定向缩容能力,通过自定义Hooks判断指定游戏服pod是否有活跃玩家,实现对游戏服缩容的精细化控制。OpenKurise的CRD配合控制器的模式在不同的K8s环境中具有良好的扩展性,只要厂商提供社区一致的API,均可正常部署运行。安全方面,当前我们的使用方式是服务端Pod与节点1:1部署,游戏服pod配置关联指定安全组,通过安全组和虚拟化对游戏服进行双重安全加固。效果《迷你世界》完成全量容器化后,在运维效率、资源成本都有了显著优化资源占用节省50%计算资源根据游戏的实施访问量自动管理,定时弹性伸缩配合指标触发的自动弹性伸缩,再加上定向缩容,资源总是能伸缩至合理水平,保障玩家的游戏体验。迭代效率提升容器化缩短了应用的迭代周期,通过灰度发布,流量治理等保证了业务平滑稳定升级,应用升级从小时级提升至分钟级。迷你玩和华为云在未来将Serverless领域加深合作:华为云容器实例服务CCI具有秒级弹性、按量计费的特性,非常贴合我们的应用场景。此外,华为云CCE提供弹性突发引擎,可以将CCI资源池以虚拟节点的方式接入CCE。基于这项能力,我们仅需将与节点强绑定的部分资源稍作调整即可将应用部署到Serverless容器服务中,进一步提升后端的弹性能力。同时CCI基于安全容器构建,独享内核,具有虚拟机级别的安全保障。下一阶段,我们考虑将部分负载逐步迁移到Serverless容器上。
  • [技术干货] Kurator V0.6.0:实现应用全流程生命周期管理
    Kurator 是华为云开源的面向分布式云原生环境的一站式解决方案。它利用 Karmada 作为多集群编排基础,内置集成了Istio、Prometheus、Thanos、Volcano、KubeEdge、Argo 等主流云原生技术。基于此,Kurator 构建了包括集群舰队管理、集群生命周期管理、统一应用分发、流量治理、监控和策略管理在内的分布式云平台管理能力。在最新 0.6.0 版本中,Kurator 为云原生应用增加了 CI/CD 流水线设置与管理功能,简化流水线创建。此外,强化了 0.4.0 版本发布的统一应用分发功能,可以在部署新应用时设置金丝雀(灰度)发布、A/B 测试、蓝绿发布三种渐进式发布策略。新增的流水线特性和渐进式发布功能与统一分发能力结合,实现基于代码仓库的 GitOps 工作流。这有助于快速构建分布式云原生平台,简化应用开发与发布流程。Kurator CI/CD 的结构图如下所示:用户更新代码仓库后,触发 Kurator 流水线,完成代码拉取、检查、编译并构建镜像。其后,用户更新应用部署模板,例如更改应用配置中的镜像信息。Kurator Application Controller 侦测到配置更新,将自动触发已应用的渐进式发布策略,实现应用的自动发布。如此一来,整个软件研发生命周期以代码为中心,实现开发至发布完整流程的自动化,简化运维、部署工作。  流水线  CI/CD 流水线实现源码到发布的自动化过程,包括源码管理、检查、测试等阶段。但由于每个阶段技术需求不同,导致流水线配置和管理难度大。Kurator 参考开源项目 Tekton,通过预定义常用任务模版的方式简化流水线创建操作。用户只需指定任务名称和代码仓库访问凭证即可创建流水线,使用门槛低。对熟悉流水线的高级用户,Kurator 也支持自定义任务。用户可以根据自己需求定制任务内容,满足个性化场景。通过预置任务模板和自定义任务的能力,Kurator 大幅简化了流水线配置和管理的难度。从图中可以看出,在使用流水线时,Kurator 完成了大部分工作。用户只需配置运行环境,选择任务模板即可完成流水线创建,大大减少学习成本。特别是与传统Tekton 相比,Kurator 提供了预定义任务模板,用户只关注任务内容而不再处理具体实现,实现了流水线使用的极致简化。除了简化流水线的创建操作外,Kurator 还考虑到了软件供应链安全,可以在流水线构建镜像时自动为其添加数字签名和源头证明,以防范假冒镜像,保证镜像源头可靠,保证在镜像制作方面的安全性。软件供应链安全指的是保护软件从开发到部署的整个生命周期过程中的安全性。软件供应链安全可以提高软件安全性能和用户信任度,预防恶意代码渗透。签名和证明添加后,镜像将自动上传至仓库。在镜像仓库中可以直接查看镜像签名和证明的详细情况,如图所示。用户可以用签名过程生成的公钥验证镜像签名和源头。这样在生产中,生产者仅需公布签名公钥,就能让用户验证数字签名和来源证明。接下来将展示一个在 Kurator 中创建一个流水线的示例:在流水线定义 spec.tasks 中指定任务名称,即可选择 Kurator 内置的常用任务模板。目前内置的常用任务模板包括:名称任务目标git-clone拉取源码go-test运行go代码单元测试go-lintgo源码静态检查build-and-push-image编译,构建镜像并上传此外,通过 customTask 定义可以发布自定义任务。通过指定 image、command 和 args,实现定制任务需求,如上述示例中自定义任务完成的工作就是打印README.md。更多的示例和细节,请参考: https://kurator.dev/docs/pipeline/  渐进式发布  金丝雀发布、A/B 测试和蓝绿发布都是主流的应用发布策略,可有效减少上线风险。Kurator 0.6.0 在原统一应用分发基础上,增加渐进式发布功能。现在应用可以指定三种渐进式发布策略中的一种策略。同时,可以将具备发布能力的统一分发,与 CI/CD 流水线结合起来,实现基于代码仓库的 GitOps 工作流。▍金丝雀发布金丝雀部署是一种渐进式发布策略。先向少数用户发布新的软件版本进行测试,根据测试结果,决定是否向更多用户推出新版本。旨在最大限度地减少新版本上线后对用户的影响,是一种更安全、更可靠的软件发布策略。参阅以下的操作示例,了解如何使用 Kurator 配置金丝雀发布。通过配置 rollout 中的 workload 字段,可以将金丝雀发布的目标设置为 webapp 命名空间下名为 backend 的应用。发布目标除了支持 deployment 应用之外,还支持 daemonSet应用。流量分析使用 Kurator 内置的请求成功率(request-sueccess-rate)和平均访问时延(request-duration)两个指标作为衡量新版本是否健康的标准。其中通过 thresholdRange 指定阈值。示例中要求请求成功率大99%,平均访问时延小于 500ms,新版本的服务才会被认定为健康。rolloutPolicy.canaryStrategy 配置了每次测试成功后,下次流量递增的比例和最终允许测试版本流量占比的最大值,从而实现渐进式发布新版本。示例中每次递增 10% 的流量流向新版本,最多为 50%。也可以设置 maxWeight 为 55,这样在最后一次测试的时候,只会新增 5% 的流量流向新版本。除了这些配置之外,Kurator 还可以设定完成验证之后,流量以什么样的比例逐步流向新版本。更多细节请参考: https://kurator.dev/docs/fleet-manager/rollout/canary/▍A/B测试A/B 测试为效果测试,是验证应用两版本表现的测试方法。它通过将用户分到不同组,每个组体验不同版本,然后分析每个组用户在使用过程中的各项指标,选择效果较好的版本。A/B 测试也可以先让部分用户试用新版本,收集真实环境下的用户反馈,再决定是否上线新版本。了解如何在 Kurator 配置应用的 A/B 测试,请参考下方操作示例。和金丝雀发布类似,由 workload 指定 A/B 测试的目标。通过 metric 指定测试的指标。A/B 测试和金丝雀发布不同的点在于需要配置 match 中的匹配规则,实现流量分组。上述 match 配置是只有 http 请求头满足使用 FireFox 浏览器或请求的 cookie 中包含 “type=insider” 的情况下,请求才会被转发到新版本。通过对不同请求头的处理达到对用户分组的效果,对不同的版本进行效果测试。除了匹配请求头之外,还能匹配 URI、端口号等。更多细节请参考: https://kurator.dev/docs/fleet-manager/rollout/abtest/▍蓝绿发布蓝绿发布是一种渐进零停机发布方法。它将生产环境分为两个独立运行的蓝绿环境,蓝环境承载当前实际流量,绿环境预部署新版本。新版本通过测试后,只需切换流量到绿环境,就能实现零停机升级。蓝环境备用支持回滚。通过实时扩容,可近乎零停机完成迭代交付,提高发布效率和用户体验。了解如何在 Kurator 配置蓝绿发布的操作示例,请参考下方。蓝绿发布需要配置目标应用、测试指标、迭代次数和容许测试失败的次数,其中测试的迭代次数由 analysisTimes 指定,容许测试失败的次数由 checkFailedTimes指定,除此之外无需配置别的规则。因为蓝绿发布在测试新版本的时候是将全局流量转发到绿环境中进行测试,没有金丝雀发布的渐进式流量递增和 A/B 测试的对用户分组的需求。更多细节请参: https://kurator.dev/docs/fleet-manager/rollout/blue-green/  未来展望  综上所述,通过 CI/CD 流水线和渐进式发布功能,Kurator 实现了从源码到发布的完整流水线自动化,真正提升了开发效率和运维能力,实现开发、配置和发布的应用全流程生命周期管理。此外还大幅简化了采用 CI/CD 流水线和渐进式发布的门槛。随着 Kurator 的不断迭代升级,我们还将继续为流水线添加更多的预定义任务模板,为渐进式发布提供更多的测试指标。欢迎大家试用 Kurator 并提出宝贵的意见与需求。Kurator的门户为:cid:link_0随着功能的逐渐完善,Kurator 将成为用户快速立体掌握云原生技术体系、高效运行分布式应用的强大工具。参考链接Kurator项目地址:cid:link_0CI/CD流水线:https://kurator.dev/docs/pipeline/软件供应链安全:https://kurator.dev/docs/pipeline/chain-security/渐进式发布:https://kurator.dev/docs/fleet-manager/rollout/金丝雀发布:https://kurator.dev/docs/fleet-manager/rollout/canary/A/B测试:https://kurator.dev/docs/fleet-manager/rollout/abtest/蓝绿发布:https://kurator.dev/docs/fleet-manager/rollout/blue-green/更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群
  • [大赛资讯] 是否可以多线程,是否可以make
    rtrtrtrtrtrtrt
  • [技术干货] Kmesh v0.1.0 版本发布!打造极致性能的流量治理体验
    Kmesh是业内首个内核级云原生流量治理引擎,通过基础软件创新帮助用户构筑云原生场景下高性能的通信基础设施。Kmesh第一个版本v0.1.0 [1]现已正式发布,用户可以在服务网格环境中使用yaml一键部署,无缝对接Istiod,通过流量治理下沉OS,实现相比 Istio Sidecar 方案转发时延降低50%+,为应用提供极致的转发性能体验。▍Kmesh 介绍Kmesh 基于 eBPF + 可编程内核技术,将流量治理下沉 OS,数据路径上无需经过代理层,实现了一个内核级 sidecarless 网格数据面。Kmesh 关键能力:高性能:内核中原生支持 L4~L7 流量治理功能,治理过程无需经过实体代理组件,网格内服务通信路径从代理架构下的三跳变为一跳,大幅提升网格数据面的转发性能;低开销:Pod 中无需部署 Sidecar 程序,大幅降低网格基础设施的资源开销;安全隔离:基于 eBPF 的运行时安全,并支持 cgroup 级治理隔离;平滑兼容:支持与 Istiod 等支持 XDS 协议的服务网格管控面对接,同时可以与现有 Sidecar 网格协同工作;Kmesh 的主要部件包括:kmesh-controller:负责生命周期管理、XDS 协议对接、观测运维等功能;kmesh-api:接口层,主要包括XDS 转换后的编排 API、观测运维通道等;kmesh-runtime:kernel 中实现的支持 L4~L7 流量编排的运行时;其中7层编排运行时能力依赖对内核的增强;kmesh-orchestration:基于 eBPF 实现 L4~L7 流量编排,如路由、灰度、负载均衡等;kmesh-probe:观测运维探针,提供端到端观测能力;▍Kmesh v0.1.0关键特性一键部署Kmesh社区发布了 Kmesh 的部署镜像[2],并支持通过 yaml 一键部署 Kmesh[3];基于namespace使能Kmesh类似Istio,Kmesh支持按namespace使能流量接管范围,如:kubectl label namespace default label istio.io/dataplane-mode=Kmesh无缝连通Istio Sidecar支持在已有sidecar形态的网格环境启用Kmesh,启用后namespace 下新创建的 Pod 流量会自动被 Kmesh 接管,而不再经过 sidecar 代理;自动对接服务网格控制面Kmesh支持与Istiod自动对接,且理论上遵循XDS协议的网格控制面都可以与Kmesh对接,可通过修改yaml中的  MESH_CONTROLLER 环境量指定;TCP/HTTP1.1基础流量治理支持TCP流量转发,支持HTTP1.1头域匹配、路由、灰度等,支持随机、轮询负载均衡算法;兼容运行模式支持根据运行环境的OS内核能力,自适应使能Kmesh特性,在无增强补丁的内核版本上,也能够以兼容模式运行Kmesh;详情参考Release Notes[1]。▍性能测试我们使用 fortio 测试了 Istio(Envoy)、Kmesh 在同等流量治理场景下的表现,同时测试了 K8s 下基于 kubeProxy 的服务通信时延作为基线参考;不同链接数下的时延对比:相同QPS下的CPU开销对比:从测试结果可以看到:Kmesh 的转发时延基本接近K8s原生转发时延,相比 Istio sidecar 模式的转发时延有明显降低;相同 qps 下,Kmesh 的 CPU 开销基本与 k8s 原生 CPU 开销一致,相比 Istio sidecar 模式有明显降低;想要了解详细的 demo 测试细节,可以观看我们的演示视频:videovideovideovideovideo  ▍Kmesh关键技术剖析内核级流量编排运行时微服务通信一般先建立链接,再发送业务报文,如果想要无感的对业务报文做编排处理,通常需要对流量进行劫持,编排完成后再基于调整后的报文继续转发,这也是现在 Proxy 代理的实现;Kmesh 考虑随流完成治理工作,将链路建立时机推迟到业务报文发送阶段,以实现更高的编排处理性能。伪建链pre_connect 流程挂载 bpf prog,若当前访问的目标地址在 xds 的 listener 范围,则调用 bpf_setsockopt 通过 TCP_ULP 将当前 socket 的 tcp proto hook重载到 kmesh_defer 的内核模块实现;延迟建链kmesh_defer 内核模块重写了 connect/send hook(在原生 hook 上做了增强):服务第一次走到 connect hook 时,会设置 bpf_defer_connect 标记,并不真正触发握手流程;send hook 中,若 sock 上设置了 bpf_defer_connect 标记,则触发connect,此时,会基于扩展的BPF_SOCK_OPS_TCP_DEFER_CONNECT_CB 调用 bpf prog,并在 bpf prog 中完成流量治理,然后基于调整后的通信五元组、报文进行建链和发送;整个治理过程大致如下图所示:XDS规则管理xds 模型是一颗层次化的树型规则表达,且不同版本模型定义可能会有调整,Kmesh 需要将模型信息转换成 eBPF map 存储,同时保持模型规则之间的层次关系;将 xds 模型转换成 eBPF map 数据具体过程:Kmesh 订阅 Istiod 的 xds 模型,并基于 protobuf-c 将 pb 模型转换成 c 数据结构风格;对于顶层模型( listener 等),Kmesh 定义了知名 map 表与之对应,且value 的数据结构复用 protobuf-c 导出的 c struct;map 更新从顶层的知名 map 表开始,对于记录中的指针成员,xds-adapter 中会创建 inner-map 表来存储指针指向的真实数据区域,并将 inner-map的map fd添加进 map-in-map表中,最后将其在map-in-map表的key(index)作为该指针成员的 value;map-in-map 解决 xds 模型层次化对于 map 记录的 value 成员,如果是指针变量(涉及引用其他数据结构),通过 inner-map 存储指向的数据区域:如果 vaule 成员是基础数据类型(int 等),则直接访问;如果 value 成员是指针类型,则指针存储的 value 是存放真实数据的 inner-map 在 map-in-map 表中的 index(注意:index 是在 kmesh-daemon 的xds-adapter 模块中更新 bpf map 时配合写入);访问时,先基于 index 找到 inner-map的map fd,再去 inner-map 表中查找真正数据,对于多级指针成员,则重复该过程,直到指针信息全部被剥离。流量治理编排实现xds 的治理规则复杂,层层匹配,超过了单个 eBPF 程序的复杂度限制;Kmesh 基于 eBPF Tail Calls 特性,将治理过程拆分成多个独立的 eBPF progs,具备较好的扩展性;▍展望Kmesh 是一种基于eBPF+可编程内核实现的高性能流量治理引擎,与业界方案相比,具有更高的转发性能和更低的资源开销;在无增强补丁的内核版本上,可以以兼容模式运行Kmesh,如果想要使用Kmesh完整的治理能力,当前 openEuler 23.03[4]版本已经原生支持,除此之外的其他操作系统需要基于增强的 patch 构建[5]。Kmesh 正在逐步完善,成为一个更受欢迎的流量治理引擎还有很多工作要做,欢迎大家试用 Kmesh v0.1.0 版本,并持续关注 Kmesh 社区,也期待您的共同参与。参考链接[1] Kmesh v0.1.0:cid:link_2[2] Kmesh的部署镜像:cid:link_3[3] 一键部署Kmesh:cid:link_1[4] openEuler 23.03版本:https://repo.openeuler.org/openEuler-23.03/[5] 基于增强的patch构建:cid:link_0[6] Kmesh社区地址:cid:link_4更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群
  • [公告] 华为联合30+伙伴发布《云端控制平台与物流自动导引车通用接口指南》,助力物流机器人集群调度!
      背景介绍  当今社会正处在一个技术飞速发展、机器人与人工智能深入应用于工业领域的时代。在物流、制造和零售等领域,自动导引车(AGV)已经成为高效生产的关键工具,正在全球范围内迅速发展并得到广泛应用。2022年,我国 AGV 销量为93000台,同比增长29.2%;销售规模为185亿元,同比增长46.8%;海外销售规模为36亿,同比增长44%。AGV 系统中的无人驾驶技术,不仅可以提高生产效率,减少人工操作失误的概率,还可以在复杂和危险的环境下保障操作人员的安全。图 1 定制化接口与统一接口下,工厂调度系统架构图尽管 AGV 技术被广泛应用,却缺乏调度系统与 AGV 之间的统一接入协议。图1(a)展示了单个工厂部署不用厂家 AGV 的软件架构图,其中 MES/WMS/ERP 代表上层业务系统,RCS 代表 AGV 调度系统或云端控制平台。由于 AGV 与 RCS 之间的接口是定制化且封闭的,因此 AGV 与 RCS 的厂家属于强耦合关系,即厂家1的 RCS 无法调度厂家2的 AGV。因此对于工厂用户来讲,为了保证不同厂家的机器人安全工作,必须划定交管区域。在同一个交管区内,同一时刻只允许同一厂家的机器人进入,显著降低了任务的执行效率和 AGV 的利用效率。因此,制定一套全面、深入、适用各种环境和物流领域的调度系统与 AGV 的协议,对于统一调度系统与设备之间对接,提升 AGV 的效率、稳定性和安全性至关重要。统一的协议标准不仅明确 AGV 供应方的责任,同时也为 AGV 需求方提供保障。图 1(b)展示了统一接口下的软件架构图,可以看到,RCS 与 AGV 之间不再存在耦合关系。总结来讲,统一接口相比于定制化的接口存在以下优势:安全性高:所有厂商的 AGV 被 RCS 当作白盒集中处理,从源头杜绝碰撞,保障安全;调度效率高:同一场地无需划定交管区,AGV 也无需在“红绿灯”前长时间等待;业务连续性强:终端用户的采购方案更加灵活,无需被单个 AGV 供应商绑定;部署运维成本低:单 RCS 部署的模式,显著降低计算资源和运维人员的成本;扩展性强:支持不同厂家的新旧设备共存,用户可以按需引入新的 AGV;为此,华为联合中外运、顺丰、龙岩烟草、海康、海柔、蓝芯、斯坦德、镭神、边缘计算产业联盟、中国物流与采购联合会等30+伙伴共同起草了《云端控制平台与物流自动导引车通用接口指南》,旨在将相关的经验贡献给行业,促进我国机器人行业的蓬勃发展。  协议内容  ▍内容简介该文件规定了 AGV 与云端控制平台的接口模型、客户端通信安全认证、通信协议结构,以及控制、传输流程接口的技术要求和检验规则。适用于物流、仓储、制造业等领域的物流自动导引车实现云端控制的系统接口设计、开发、检验等。图 2 云端控制平台与AGV报文交互示意图图 2 展示了云端控制平台与 AGV 的交互流程图,整体分成以下几步:AGV 在初始化完成后,向云端控制平台发起接入申请,可选普通模式接入和安全模式接入。在普通模式中,后续报文将直接发送至对端。在安全模式中, AGV 与云端控制平台将协商会话密钥,且后续报文以密文的形式发送。AGV 向云端控制平台发起注册请求。注册成功后,将会周期性的上报自身状态;云端控制平台配置 AGV 的全局信息,如状态上报周期、告警参数等;AGV 周期性地向云端控制平台上报自身状态,并与云端控制平台保持心跳;云端控制平台根据上层业务系统输入,下发每个 AGV 的控制报文,驱动 AGV 运动;AGV 可以根据需求向云端控制平台申请安全空间,以完成自主运动,如动态绕障。▍协议亮点图 3 协议亮点信息安全:在普通接入模式的基础上,新增了安全加密模式。AGV 与云端控制平台通过 SM2 密钥交换协议协商会话密钥,然后使用该密钥对传输的报文进行 SM4 分组密码算法进行加密后,利用 SM2 数字签名算法生成签名,再对密文和签名进行传输,从而保证整个通信过程的安全;多地图管理:为满足 AGV 跨楼层和跨楼栋搬运的需求,协议规定了 RCS 和 AGV 的地图切换流程。同时指明了 AGV 在同一场地下,在 SLAM 和二维码导航之间的切换流程;双向路径规划:协议不仅规定了 RCS 规划的路径下发给 AGV 的流程,同时支持车体在极端环境下自主规划且平台授权的轨迹形式方法,如临时性避障;通信数据:采用二进制报文,显著降低通讯的数据量,减轻了对网络的依赖。同时保留多个预留字段,便于扩展和定制化实现。▍行业推广 协议的蓬勃发展离不开行业的应用和推广。KubeEdge 是边缘计算领域的开源平台,构建在 Kubernetes 之上,为网络、应用部署和云端与边缘之间的数据同步提供基础设施的支持,其目标和应用范围与当前协议的宗旨十分契合。因此 KubeEdge 将作为协议推广的重要阵地,其功能包括但不限于文档展示、协议内容详细解读、协议代码参考实现和端到端调度系统实现等,为了广大厂商和终端用户提供了良好的交流平台。▍相关链接仓库地址:cid:link_0更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群
  • KubeEdge EdgeMesh v1.15 边缘CNI特性原理及功能详解
    作者:达益鑫 |南开大学,刘家伟、吴锟 |DaoCloud,王杰章 |华为云▍特性研发背景以及原理KubeEdge EdgeMesh 边缘 CNI 特性针对于边缘容器网络复杂异构环境提供与云上一致的容器网络体验,包括:1. 云边统一的容器网络资源管理分配2.基于分布式中继及穿透能力的 PodIP 级别跨子网流量转发服务特性开发背景EdgeMesh 致力于研究和解决边缘计算场景下网络连通、服务协同、流量治理等相关的一系列问题,其中在异构复杂的边缘网络环境内,不同物理区域的容器在面对动态变迁的网络环境以及短生命周期且跳跃变迁的服务位置,一部分服务可能需要使用 PodIP 进行跨网段通信,而主流的 CNI 方案主要针对于云上稳定且集成式的网络环境,并不支持跨子网流量的转发,致使这些 CNI 方案并不能够很好地适应边缘复杂异构的环境,最终导致容器即便在同一个集群内却没有享用一个平面的网络通信服务。针对这个需求,EdgeMesh 进行逐步的优化。首先实现的是网络底层的中继以及穿透服务功能开发,即 EdgeMesh 高可用特性。在分布式网络场景当中,该特性能够为节点提供基于 Service 的中继流量以及网络穿透服务,但还没有完全支持对 PodIP 层次流量的转发和穿透能力。换句话说在云边混合的场景当中 ,EdgeMesh 能够为跨网段的 Service 流量提供穿透服务,但并没有涉足到容器网络的资源管理和 IP 层的连通性功能,仍旧依赖于集群原本的 CNI 方案。这个局限性导致 EdgeMesh 无法为更加底层的网络 IP 流量提供服务,意味着 EdgeMesh 并不能够完全覆盖混合云边的场景需求,对于那些需要穿透和中继服务的 PodIP 流量,老版本的 EdgeMesh 爱莫能助。那么为什么主流的 CNI 方案无法兼容边缘环境,EdgeMesh 又是如何理解这个需求的呢?关键问题在于主流的 CNI 方案大多建立于至少三层可通的环境要求之下,具体来说 CNI 自身管理创建网络资源的时候,并不能够感知底层网络的状态,其管理能力高度依赖于 Kubernetes 系统提供的 Node IP 地址,而这个地址的连通性是由底层的网络设备来维持的,如果宿主机不能通过该 Node IP 访问到目标,那么容器网络的虚拟 IP 就更没有办法联通了,原理也将在下文详述。这也意味着 Kubernetes 系统所给的 Node IP 在边缘这样底层网络并不稳定的环境下无法保障稳定的底层通信服务。EdgeMesh 基于上述理解,对这个需求进行细化的分析:边缘网络拓扑结构变动性强,且物理隔离场景较多,致使容器网络环境难以呈现出云上那样稳定的底层设施特征,比如边缘环境中自动驾驶场景或者是快递运输场景等。在这样的环境中,物理节点本身并不是绑定固定地址,甚至涉及到 5G 信号核心网注册切换等通信上的流程问题,使得 IP 地址和网络拓扑并不具备完全意义上的寻址能力,通俗说某个节点可能在上一时刻在 A 区域但是过了一会他就行驶到 B 区域了,这样动态变化切换的场景是以往 CNI 架构不曾考虑的。CNI 的连通性是基于 Kubernetes 的 Node IP 维持的,更加深入理解这个结论:主流的 CNI 相信 Kubernetes 系统设置的 IP 地址是可以联通的,所以这些主流的 CNI 方案管理虚拟网络往往都使用这样的方法:宿主机操作系统中的一个切换装置,通过让自己作为虚拟网络资源和实际物理网络环境的中继;正如下图所示, CNI 只是通过 k8s 系统,在各个节点上创建了虚假的地址,通过信息协同的方式让拥有这些虚假地址的数据包可以正常在单机节点上传送给目标,但根本还是依赖于 Node IP 可以访问联通,毕竟如果数据包不能够正常到达目标节点,CNI 利用操作系统所作的虚假行为也就没有了意义。反过来说也无法超过于单机操作系统能够管理的网络连通性,多机分布式场景下完全只能够依靠 Kubernetes 系统。当然,也并非所有的主流 CNI 都只在本机的操作系统内做文章,更加深入解决连通性的 Calico 组件有提供基于 BGP 协议的跨机连接方案,但也围绕着云上数据中心架构展开的。与此相对应的边缘环境中, 节点的 IP 地址是存在着局域性、变动性、不确定性的,可以风趣地说 Kubernetes 系统被节点欺骗了。容器生命周期短暂且不确定,这个特性更像是此类问题的催化剂,使得边缘割裂场景下的网络连接更加难以使用固定的拓扑结构来进行规划管理。系统设计思路在本特性初阶段我们确定了此次项目实现的目标:是结合 EdgeMesh 已有的 P2P 功能来提供 CNI 特性, CNI 特性在目前阶段并不意味着开发出完全替代Flannel、Calico、Cilium 等已有架构的完全独立 CNI,而是作为多阶段逐步迭代实现的特性。一方面从用户角度来说,如果直接替代云上已有的 CNI 架构,会带来额外的部署成本,也无法向用户保证新的架构有足够的价值可以完全覆盖老体系的场景和功能,以项目迭代开发的方式,优先实现一些能力,再慢慢优化、敏捷开发更能符合用户的利益。因而对于云上环境,我们倾向于直接兼容已有的 CNI 架构,使用它们提供的服务,但是补足他们不能够提供的 P2P 功能。与此同时,现有的 CNI 方案并不能够为边缘复杂异构的环境提供统一的容器网络服务,所以相较于 Docker 或者是其他 CRI 提供的简单网络功能,我们更倾向于直接开发出自己的 CNI 来实现对边缘容器网络资源的管理。而在上述的 CNI 需求之外,最重要的是如何与 EdgeMesh 的 P2P 服务结合起来;目前的开源社区中实现隧道的技术有:如 VPN,包含 IPSec、Wireguard等;如 P2P,包含 LibP2P 等,结合 EdgeMesh 应对的复杂异构多变边缘环境,我们选用了 LibP2P 技术进行开发。在此之上需要判断哪些PodIP流量需要 P2P ,哪些流量仍旧使用原本的 CNI 网络服务;再来是将这两部分的功能解耦,以便后期的功能逐步迭代优化,主要的系统架构如下图所示:上述系统设计将集群内的流量分为两类:同一网段流量: 指的是底层网络 NodeIP 可通信,Pod 容器流量通过 CNI 转换即可进行通讯。跨网段流量: 指的是底层网络不可直接访问, Pod 容器流量通过 CNI 转换封装也无法到达目标节点。针对于不同的流量我们提供不同的流量传输方式:对于同一网段的流量:依旧使用主流 CNI 的方案,通过 CNI 转换地址的形式切换虚拟网络和真实网络,连通性依赖 Kubernetes 系统获取的 NodeIP。对于跨网段的流量: 将这部分流量拦截到 EdgeMesh 当中,通过中继或者是穿透的形式转发到目标的节点,此时 EdgeMesh 充当具有 P2P 功能的 CNI 插件,来完成虚拟网络的切换。这样的设计需要解决亮点重要的问题:云边集群容器网络资源统一控制管理边缘节点以及云上节点 CNI 共同管理容器网络资源,使得容器可以分配到集群唯一的 IP地址,且不论云边都可以通过这个 IP 地址进行通信。云边以及边边跨网段容器网络通信能力兼容原本 CNI 的通信方式让需要 P2P 的流量跨网段传输。系统设计的关键抉择在于,是否需要将 P2P 的功能放置到 CNI 执行的关键路径当中,或者是将 P2P 的功能与 CNI 架构解耦。针对于第一个问题,核心关键是 IPAM 插件的设计和兼容,这方面我们倾向于集成开源社区成熟的方案 Siderpool :📌 :https://github.com/spidernet-io/spiderpool Spiderpool 是一个kubernetes 的 underlay 和 RDMA 网络解决方案, 同时也是一款 CNCF Sanbox级别项目这一方案也更加契合容器网络插件化设计的理念,用户可以依据业务的需求来更改系统组件的组合,在现阶段完全满足多 CNI 统一管理集群资源的设计。针对第二个问题,核心在于为 CNI 创建的容器网络资源添加跨子网的连通性。方案设计上,如果将中继和穿透的功能放置到 CNI 执行的关键路径中,那就意味着需要在内核中实现中继和穿透的流程,否则将带来巨大的性能消耗。实际上目前 Calico 、 Flannel 、Cilium 等架构在云上使用隧道技术时候就是采用这个方法:在容器资源创建修改的时候,同步修改内核中的网络设备参数,然后对数据包进行封装或者是修改,比如 Vxlan 服务中将目标是其他节点容器的流量拦截,然后添加对协议参数。这个方式在云上运用较为普遍,但是明显无法适应边缘的环境,原因在于:CNI 执行是无状态且一次性的,只有当容器网络资源创建、修改、删除的时候, CNI 调用链会被触发并执行对应的功能;这个方式的实质是通过静态配置的方式来提供通信服务,对于云上较为稳定的网络环境以及通信条件来说,确实是合适的选择,但对于边缘环境来说,网络资源并非一成不变;如果将隧道信息配置为静态形式,再通过 CNI 调用链触发管理,就无法应对部分容器动态变化之后隧道信息变迁的情况。在上述考量的基础上,本特性将 分开 CNI 和 P2P 的功能,解耦彼此在系统运作上的依赖关系,这样也更加方便用户可以选择是否开启其中的一项功能。边缘 CNI 功能这部分设计为实现基础的 CNI 调用链功能,在边缘节点管理容器网络资源,同时通过 IPAM 组件 spiderpool 兼容云上其他的 CNI 架构,统一分配集群的容器网络资源,包括基础的 CNI 功能,其次是通过 SpiderPool 实现全局的容器 IP 地址唯一。基于以上各组件设计,当集群内每一个容器都拥有了唯一的 IP 地址,我们接下来需要做的是为需要中继穿透的流量提供服务,设计方式为: 用户配置全局容器网段文件,分为云上 CIDR 和 边缘 CIDR ,每一段 CIDR 对应一个区域网络即 三层不可通的网络, EdgeMesh 通过配置文件插入路由表规则,将目标地址于本节点 CIDR 不相同的流量都拦截到本机的Tun 设备,再传输到 EdgeMesh 的 libP2P host 通过中继或者穿透的方式传输到目标地址。▍特性启用以及功能启用 EdgeMesh 边缘 CNI 特性您可以通过以下配置的方式,在启动 EdgeMesh 时候启用 CNI 边缘 P2P 特性,配置过程中您可以依据对云边网段资源的划分需求来配置云边容器网络所处的区域:# 启用 CNI 边缘特性 helm install edgemesh --namespace kubeedge \ --set agent.relayNodes[0].nodeName=k8s-master,agent.relayNodes[0].advertiseAddress="{1.1.1.1}" \ --set agent.cloudCIDR="{10.244.1.0/24,10.244.1.0/24}",agent.edgeCIDR="{10.244.5.0/24,10.244.6.0/24}" https://raw.githubusercontent.com/kubeedge/edgemesh/main/build/helm/edgemesh.tgz上述配置的参数中 cloudCIDR 是云上容器集群分配的地址, edgeCIDR 是边缘容器集群分配的地址;EdgeMesh 会对比部署节点分配到的容器网段 CIDR 与配置文件中是否属于不同网段,属于不同网段的地址会添加对应的 ip route 规则拦截到 Tun 设备。cloudCIDR 参数是云上分配的容器网段,类型为 []string ,形式为容器 IP 地址以及其子网掩码,表示一段虚拟网络区域,在区域内的容器应当网络二层可通,如果容器不能够通过二层设备访问,请划分为不同的容器网段。edgeCIDR 参数是边缘分配的容器网段,类型为 []string ,形式为容器IP地址以及其子网掩码,表示一段虚拟网络区域,在区域内的容器应当网络二层可通,如果容器不能够通过二层设备访问,请划分为不同的容器网段。名称参数类型使用实例agent.meshCIDRConfig.cloudCIDR[]string--setagent.meshCIDRConfig.cloudCIDR="{10.244.1.0/24,10.244.1.0/24}"agent.meshCIDRConfig.edgeCIDR[]string--setagent.meshCIDRConfig.edgeCIDR="{10.244.1.0/24,10.244.1.0/24}"需要注意的是设置的地址必须为 CIDR 形式 ,同时需要您依据云边网络情况划分出对应的网段;另一方面本特性需要同时启动高可用特性,为跨网段的流量提供中继和穿透服务。更多的安装配置信息请详见:helm安装 : https://edgemesh.netlify.app/zh/guide/#helm手动安装:https://edgemesh.netlify.app/zh/guide/项目功能特性介绍依据系统的设计,边缘 CNI 特性提供以下具体的功能:云边集群容器网络资源控制管理📌 :现版本推荐集群云上节点使用 calico/flannel/cilium 等 CNI 插件,同时边缘集群节点使用 EdgeMesh CNI 插件,整个集群配置 SpiderPool 作为统一的地址管理插件来提供服务。针对于边缘网络复杂异构的情况,EdgeMesh 提供了边缘 CNI 插件来创建和管理边缘节点容器的地址资源,同时通过配合 IPAM 插件 spiderpool 协调云上节点的其他 CNI 插件来实现 整个集群的容器地址唯一,云边节点都可以通过唯一的地址进行通讯。如下图所示,该项功能的主要特性在于屏蔽了云边复杂的网络集群拓扑,实现了云边集群统一的容器资源管理,使得云边的容器可以体验如同在一个局域网内的通信服务,而不必考虑边缘集群节点容器地址重复或者是云边集群底层地址不通的问题。云边以及边边容器网络通信能力针对于边缘环境中云边和边缘通信问题,EdgeMesh CNI 特性集成了 P2P 的功能,为跨网络集群的容器流量提供中继和穿透服务。该 P2P 特性现版本主要通过 TUN 设备在 IP 层拦截需要中继和穿透服务的流量实现,能够为应用网络通信提供底层连接的服务,而不受到 IP 层以上网络协议的影响。系统功能运行如下图所示,在每个节点上的 EdgeMesh 会通过修改 IP Route 的形式拦截流量到 TUN 设备,再传输到 EdgeMesh 的 libP2P host 通过中继或者穿透的方式传输到目标地址。这个过程中 EdgeMesh 并不会拦截所有的流量而是通过用户在启动时候设置的网络区域参数来区别哪些流量是跨网段,哪些流量是同局域网访问的,并不会干扰到正常同网段流量的通信。后续计划以及未来设想在项目开发的初期阶段,系统设计基础实现了最初的需求,但是在边缘容器网络环境当中,由于网路部署和设备架构的使用情况多样复杂,对于容器网络提出了三方面重点的需求:可观测具体指的是对于云边以及边边流量的去向,包含在节点内操作系统处理的过程以及节点外多节点之间转发传输的流程可观测性。这类需求对于运维人员以及应用开发人员有着非常重要的价值和意义,可以快速定位网络流量问题出现的位置和导致的原因,并快速得出性能优化的方案和解决问题的办法。高性能与纯云部署的容器集群相似,云边混杂集群同样也面临着性能堪忧的问题,在网络层面主要指的是节点内对网络数据包在操作系统处理路径上的优化,减少其处理的逻辑和相关资源的消耗。强稳定相较于纯云上集群的部署,云边混杂集群的状态往往难以稳定,需要服务能够应对环境变化同时在出现问题时候较快地将流量卸载到正常的服务当中。针对于这些需求, 容器网络 CNI 功能是重点开发和创新的系统组件, EdgeMesh 将在接下来的系统开发中结合 eBPF 等内核优化技术,同时以实现一款泛用的边缘 CNI 插件为目标,推出应对这三点需求的特性和功能,期待能够为用户带来更加丰富和稳定的网络服务体验。附:KubeEdge社区贡献和技术交流地址[1] 网站: https://kubeedge.io[2] Github地址: cid:link_0[3] Slack地址: https://kubeedge.slack.com[4] 每周社区例会: https://zoom.us/j/4167237304[5] Twitter: https://twitter.com/KubeEdge[6] 文档地址: https://docs.kubeedge.io/en/latest/更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群
总条数:356 到第
上滑加载中