更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群

CloudVison在设计之初，只是通过XMPP把交换机EOS上的状态数据同步到一个集color:中的全局数据库中，然后通过Portal把全局视图提供出来。这实际上可以看作一个偏向于网管的入口，除了一些ZTP功能用于配置自动化以外，并没有过多的控制逻辑，因此 CloudVison最初的定位并不是作为SDNController，而是Network Wide Enhanced EOS。随着这几年的发展，CloudVison逐渐增加了对虚拟网络进行直接控制的能力和对全局数据的监测分析能力，因此CloudVison现在可以看作Arista的SDN 控制器。CloudVison分为CloudVison Portal (CVP)和CloudVison eXchange(CVX)两个部分， CVP和CVX可以采用分布式部署，各自可以支持3个节点的集群。其中，CVP是一个 Web平台，是网络的管理入口，负责提供网络的配置以及全局数据的可视化，其主要功能包括以下几点。用户安全，支持RBAC。基于JSON 的 RESTful API。口设备的镜像、快照、智能升级。□设备自动上线、管理与配置、配置回滚。□网络的实时状态与历史状态、大数据分析。CVX是增强的EOS 环境，它相当于网络中的控制器，负责业务到网络下行的自动化控制，其主要功能包括以下几点:口提供EOS 的 CLI、API以及基于JSON-RPC的eAPI。 OVSDB 接口协议。□物理网络的拓扑发现。VxLAN控制逻辑(VCS，VxLAN Control Service，基于Arista的私有协议)。 Vmware NSX与OpenStack，对VLAN和VxLAN两种组网模式提供支持。口宏分段(Macro-Segmentation Services)，实现虚拟机和裸机间东西向流量的安全。 Arista一直主打的是 Underlay Fabric上的SDN，这种 SDN应该理解为软件驱动网络,主要功能包括自动化和遥测两大类。自动化即为对Fabric进行自动的维护，主要包括:配置、回滚与智能升级等。遥测即为网络的可视化，主要包括数据流量分析、时延分析、网络追踪等，这些数据可以通过gRPC实时地推送给CloudVison进行呈现，以及后续的分析与处理。

VSs交换机的市场份额上升得非常快，在Gartener近三年的Magic Quadrant中与Cisco并列第相比 Cisco 和 Juniper,Arista算是网络圈子的“新兵”，不过近几年Arista在数据中心机级的一象限。高速上涨的背后是Arista对于数据中心的专注，其交换机的两点核心竞争力一以及安低延时和开放性，成为Arista在云数据中心网络领域脱颖而出的基础。先来看低延时。某些特定领域的应用，如超算和高频交易，对延时的要求十分苛刻。对于低延时应用来说，InfiniteBand在技术上是最好的网络选择，不过以太网正在靠着简单性、低成本和40GE/100GE端口不断地进行着渗透，低延时以太网+RoCE正在获得低延时网络的市场份额。低延时对以太网要求的不仅是带宽的NonOver-Subscribe，还需综合考虑设备的转发架构、端口的buffer深度、链路的负载均衡、精细的拥塞可视化以及完整来实的网络数据审计，来构成一整套的低延时解决方案。Arista凭借着直通式转发、大buffer、用于 ECMP+M-LAG以及其LANZ和DANZ技术，在低延时以太网市场上形成了独特的竞争优间 势，在金融圈子内拥有大量的客户。随着大数据和其他分布式计算应用的大规模爆发，低延时的需求被引入了云计算数据中心，Arista也得以借这股东风找到了新的市场爆发点。再来谈开放性。Arista做设备秉承的理念是“Merchant Silicon+Open Protocol >> Vendors Proprietary Fabrics”，即通过通用的芯片和标准的协议来组盒子，通过开放性和低成本来抗衡Cisco。“通用的芯片”意味着 Arista不会自己玩芯片，而是会选择Broadcom专业芯片公司的产品，以降低高昂的芯片研发成本，如果对ASIC有特殊需要(如LANZ)、也是我芯片公司进行定制。“标准的协议”意味着Arista的组网通常依赖着的都是标准的L2/L3协议，如STP、OSPF、BGP、ECMP等，少数Arista私有的协议，如M-LAG和VARP,也是参照开放协议进行修改的。因此，和Cisco的FabricPath以及Juniper的 QFabric 不同，Arista在2010年前后面对着即将爆发的数据中心虚拟化时，并没有选择自己搞一套大二层的专用Fabric，而是联合VMware和Microsoft 推出了 VxLAN和NvGRE,希望把二层 Overlay在现有设备上。搭上了VMware对于VxLAN生态建设的便车，Arista又一次在网络虚拟化领域占据了有利的位置。当然，光占据市场位置是没有用的，把技术的内功修炼到位才是产品能够持续卖出去的根本。如果自己不做芯片和协议，技术上想要出彩，就要在软件平台上花心思。Arista显然很早就搞清楚了这个道理，于是在其交换机软件平台EOS上下了很大的工夫。EOS是完全基于开源Linux来做的，相比于WindRiver提供的专用网络操作系统，其开放性和可维护性有着本质上的提升。恰逢其时，EOS的技术路线正好契合了SDN所提倡“把盒子开放出来”的理念，Arista作为传统的设备厂商，得以在SDN的大时代中站稳了脚跟。自家数据中心的盒子年增长率惊人，Arista就没有动vSwitch的心思，虽然自己也做SDN控制器但也没有大张旗鼓地去宣传，而是主力在推动自己的Underlay SDN。这注意,Underlay SDN是为了补充Overlay SDN的，这与CiscoACI“以硬件为中心”HUAWEI 订了战略合作关系，图4-63是两家合作的路标。 SDN理念有着本质的不同，虽然Arista自己也支持纯硬件的方案，但是并没有在市场上 VMware NSX直接竞争。

NSX-V数据平面的组件包括NSXvSwitch和NSX Edge。NSX vSwitch在VDS 的基础上添加了3个内核模块:VxLAN(VTEP),DLR(分布式逻辑路由器)和DFW(分布式防火墙)。 NSX Edge则为NSX网络提供了L2GW以及L3-L7的高级网络服务，如集中式路由/NAT集中式防火墙、负载均衡、VPN等。先来看NSXvSwitch。VDS负责租户的二层转发，VM连接在VDS上。VxLAN模块对目的地位于其他ESXi主机的L2帧封装VxLANHeader.DLR模块负责租户的三层转发，包括东西向流量和南北向流量。DFW与VM的vNIC相关联，能够per VM的细粒度、定制化、带状态的安全防护。由于这些模块都是分布式的，不存在单点故障的问题，因此 NSX vSwitch本身就具备了很高的可用性，不需要再设计额外的HA机制。NSXEdge可以理解为NSX-V提供的NFV产品套件。L2Gateway用来实现NSX租户网络和物理主机的二层连通，L3Router负责集中式的路由和NAT，用于连接NSX-V租户网络与 Internet。除了二层和三层网关外，NSXEdge还提供了诸多的高级网络服务:防火墙用来提供per VDC级别的安全防护，负载均衡既可以集成在三层网关上，又可以独立于三层网关部署，高版本的NSX-V还支持DLB(Distributed Load Balancer)，VPN既可以部署L2VPN又可以部署L3 VPN,L2VPN采用私有封装实现跨域二层互通，L3VPN支持 IPSEC和 SSL两种。NSXEdge通常放在NFV POD下面采用集中式部署，以连接NSX-V网络与外界网络，因此需要为NSXEdge设计HA机制，以保证其可用性。对于上述不同的 NSX Edge功能，它们的HA机制都不尽相同，此处不进行详细的分析。在vSphere 环境中，除了VxLAN所承载的VM通信的数据流量以外，VDS上还通过 VMkernel 接口承载了很多其他类型的流量，如管理流量、vMotion流量和存储流量，这些流量的特征和优先级截然不同，对物理网络的需求自然也有很大的区别。因此，这4种类型的流量在上联时可以采用不同的VLAN ID，并在上联口使用VLANTrunking，以便进行复用、隔离和 QoS 规划。

  NSX-V用于在纯VMware vSphere环境对网络进行虚拟化，并不支持KVM、XEN等开源服务器虚拟化技术。虽然NSX-V面向的是VMware自家的产品，但还是保留了NVP的大部分SDN技术特征，并提供了强大的NSXEdge以支持更为丰富的NFV组件,为 NSX-V的组网提供了更多的可能性。NSX-V的微分段技术中实现了分布式防火墙，能够支持更为灵活、立体的网络安全策略。另外，NSX-V还提供了网络管理平面，方便用户进行集中式的管理。  NSX-V的产品架构由上到下分为三个平面:管理、控制与数据。管理平面的主要组件为NSXManager，它通过UI提供虚拟化网络的视图呈现与集中式的单点配置与管理，通过RESTfulAPI与VMware的管理平台交互、通过RESTfulAPI/私有协议对控制平面/数据平面进行配置与管理。控制平面组件主要为NSXController，它向上通过 RESTful API接收NSXManager的配置与管理，向下通过私有协议来管控数据平面的转发，另外DLR(Distributed Logic Router) ControlVM也是NSXController的一个组件，它接受 NSX Manager的配置与管理，并运行传统的路由协议，作为分布式逻辑路由器的控制平面与下一跳路由器(通常为NSXEdge)交换路由信息，以处理南北向流量。数据平面的组件主要包括NSXvSwitch和NSXEdge，通过私有的协议与控制平面进行通信，并根据控制平面提供的全局信息进行转发。可以看到，NSX-V的这套架构是一套纯软的方案，也就是说，从管理到控制再到设备全是软件实现的，将虚拟网络透明地Overlay在物理网络之上。对于纯软的方案来说，功能从来都不是问题，性能与高可用才是软件产品能否成功的关键，NSX-V作为生产级别的网络虚拟化平台，自然也少不了对这些方面的考虑。

还在为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▼▼▼

全球顶级开源组织云原生计算基金会(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进入技术群

前言随着技术以前所未有的速度发展，移动计算的未来有望实现变革性的进步。从增强的连接性到突破性的硬件创新，下一代移动计算将重新定义我们与数字世界互动的方式。本文将探讨预测移动计算发展轨迹的预测，并提供一些令人兴奋的可能性。预测5G革命性的连接无处不在的高速连接：5G网络的广泛实施有望通过提供无处不在的高速连接来彻底改变移动计算。这将为无缝流媒体、低延迟应用和沉浸式增强现实(AR)体验铺平道路。可折叠和灵活的显示重新定义形式因素：下一代移动设备可能会以可折叠和柔性显示屏为特色，为用户提供多种形式因素。这些创新可能会导致设备无缝地从传统智能手机转变为更大的平板电脑，甚至可以折叠成更紧凑的尺寸，以方便携带。个性化体验的AI集成智能和自适应助手：人工智能(AI)将在塑造移动计算的未来方面发挥关键作用。由人工智能驱动的智能和自适应助手将了解用户偏好，预测需求，并提供个性化体验，使与设备的交互更加直观和高效。扩展现实(XR)成为主流AR和VR集成：扩展现实(XR)，包括增强现实(AR)和虚拟现实(VR)，预计将成为移动计算的主流。从交互式AR应用到沉浸式VR体验，移动设备将成为数字参与新维度的门户。量子计算对移动安全的影响增强的安全协议：量子计算的出现可能会对移动安全产生重大影响。将实施抗量子算法和加密技术，以加强移动设备抵御新出现的威胁，确保用户数据的隐私和安全。设备设计中的环境可持续性环保材料和实践：下一代移动设备将在设计中优先考虑环境的可持续性。从使用环保材料到节能组件，制造商将越来越关注减少移动计算的生态足迹。生物识别认证的进步安全和无缝访问：面部识别和指纹扫描等生物识别身份验证将在准确性和速度方面取得进步。这些技术将为用户提供安全而无缝的设备和敏感信息访问。总结下一个移动计算时代即将迎来一波创新浪潮，这将重新定义我们连接、互动和体验数字世界的方式。从5G革命到人工智能和XR的集成，对移动计算未来的预测描绘了一个技术丰富和互联的未来。随着这些进步的展开，用户可以期待一种超越当前限制的移动体验，并开辟新的可能性领域。转载链接：cid:link_0

作者：本文由华为云客户迷你玩投稿背景迷你玩旗下《迷你世界》是一款国产沙盒创意平台，拥有全球数千万创作者进行去中心化内容创作，通过方块组合自由创造等方式，引导用户在平台上创作虚拟作品。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容器上。

Ncutron有个子项目叫作TaaS (Tap as a Service)，它能够把流量镜像到特定的、运行有流量分析软件的虚拟机中，以实现流量的可视化。TaaS在Neutron中仍然属于比较新的子项目，目前还没有正式纳入Ncutron的标准 API中。不过，鉴于流量可视化对于OpenStack网络运维和安全的重要性，本次会对TaaS进行介绍。 在TaaS 的设计中，有几个主要的概念:Destination Port是镜像流量的目的地，即运行有流量分析软件的虚拟机;Source Port是指镜像的流量源，通常是租户的某台虚拟机;Tap Service是指一个镜像流量服务的实例;TapFlow是指一个流量镜像服务的规则。在0版的 TaaS 中，一个Tap Service需要关联一个 Destination Port，一个Tap Service可以包含一个或多个Tap Flow，每个TapFlow需要关联一个Source Port。因此，租户开通一个TaaS需要两个步骤。 1)创建一个 Tap Service并指定一个虚拟机作为Destination Port。 2)然后创建一个 Tap Flow，关联上一步中创建的Tap Service并指定一个虚拟机作为 Source Port。为了防止租户间的流量泄露，一个Tap Service只能属于一个租户，相应的 Destination Port 和 Source Port也都必须属于该租户。 从架构上来看，TaaS Plugin负责处理TaaS AP1,分析其合法性并通过RPC分发给相应的 TaaS Agent,TaaS Agent控制本地的Driver对流量镜像进行底层实现。0版中TaaS的 Driver 只有OVS，br-int和br-tun中的流水线均进行了相应的扩展，另外TaaS 还设计了一个hr-tap,中在br-int和br-tun中间，便于提供更为灵活的镜像策略。TunS所涉及的流表很多，流水线画起来比较复杂，下面概括地介绍一下其实现思路，首先要明确的是，Source Port和 Destination Port在分布位置上并没有必然的联系，可能位于同一个host中,不过更多的时候位于不同的host中。针对两种不同的情况，数据的流向分别如下所示。(1)第一种情况 Source Port 和Destination Port位于同一个host中，此时镜像流量不需要经过hbt-tun 处理 Source Port 的流量流入 br-int之后: 1)br-int 识别出这是某个Source Port的流量，于是将其镜像到br-tap中，同时为镜像流量标记其所属Tap Service的专用VLAN。 2)由于Destination Port 就在本地，因此br-tap 在收到从br-int 发过来的镜像流量后，直接通过in_port 将其反射回br-int。 3)br-int 发现这是从 br-tap发送过来的流量，去掉Tap Service的VLAN.并将流量送给本地的 Destination Port。 (2)第二种情况 Source Port和Destination Port位于不同host，此时镜像流量需要经过br-tun在不同的 host间进行传输。Source Port的流量流人br-int之后。 1)br-int识别出这是某个SourcePort的流量，于是将其镜像到br-tup中，同时为镜像流量标记其所属Tap Service的专用VLAN。 2)由于 Destination Por 不在本地，因此br-tap在收到从br-int 发送过来的镜像流量后，将其传送给br-tun。 3) br-tun 发现这是从 br-tap发送过来的流量，知道要将其送到远端的Destination Port,不过 br-tun此时并不知道Destination Port位于那个host中，因此只能进行隧道泛洪， tunnel_id标记为Tap Service的专用VNI以便和业务流量进行区分。4) Destination Port所在host的br-tun收到该镜像流量后，去掉封装并标记Tap Service的 VLAN，然后将其发送给本地的br-tap。其他host的br-tun收到该镜像流量后会直接丢弃。5)br-tap从br-tun上收到镜像流量后，得知Destination Port就在本地，于是透传给本地的 br-int。6)br-int 发现这是从br-tap送过来的流量，去掉TapService的VLAN，并将流量送给 本地的 Destination Port。 对于第二种情况:在3)中第一次处理镜像流量的时候需要经过隧道泛洪，为了能够在处理后续流量时避免泛洪，因此4)中Destination Port所在host的br-tun收到该镜像流量后，在送给本地br-tap的同时，还会复制一次并通过in_port反射回给Source Pont所在host的 br-tun。 Source Port所在host的 br-tun收到这个反射回来的流量后，即可得知 Destination Port所在的host，于是后续的镜像流量就可以直接进行隧道单播了。 ThaS支持将Source Port的入向流量和出向流量都导向DestinationPort。由于Taas是实现在OVS上的，因此它和虚拟机间还隔着Linux Bridge上的Security Group，对于 Destination Port而言需要禁止其人向G规则而放的镜像流量。对于Source Port而言、目前TaaS对人向流量的处理发生在人向G规之前，对出向流量的处理发生在出向SG之后。与之反，想状态下对人向流量的处理应该发生在人向SG规则之后，出向流量的处理应该发生在出向SG规则之前。目前社区正在OVS中集成SG功能，完成后这 -顺序问题即可得到解决。 TaaS对于生产环境来说是个非常好的功能，不过由于TaaS 的设计是基于In-Band 的，因此镜像流量会占据业务流量的带宽，而且将多个Source Port的流量都镜像到一个Destination Port 上，Destination Port的压力也太大了，这些都需要TaaS进行优化，比如通过QoS 做镜像流量限速，通过PolicyFiltering筛选流量，或者通过Quota 做Source Port的配额。

负载均衡是实际生产环境中不可或缺的一个环节。从G版本开始，Neutron通过子项目 LBaaS 来提供负载均衡的服务，默认使用HAProxy作为backend driver。这一阶段的 LBaaS称为LBaaS v1，从功能和可扩展性上来讲，LBaaSv1存在着很大的局限。因此从K版本开始，社区推进了LBaaS v2，在Liberty版中将LBaaSv1标记为Depreciated，并在Newton版本中下架了LBaaS v1。本节先来介绍一下LBaaS v1和LBaaSv2、最后再简单地看一看 OpenStack 中负载均衡的新势力Octavia。 5.9.1 LBaaS v1 LBaaS v1的设计架构其中包括4个基础性的概念。VIP是业务对外表现的IP地址，一般来说VIP对于Client是公网可见的。Pool可以看作业务实例所形成的资源池，一个Pool只能对应一个VIP，一个Pool对应一个独立的HAProxy(默认)进程。 HAProxy进程存在于网络节点独立的namespace中并拥有VIP，它收到目的地址为VIP的流量后会分配给后端不同的业务实例，可支持的算法包括ROUND_ROBIN、LEAST_ CONNECTIONS、SOURCE_IP 3种，支持基于cookie的会话保持。业务实例称为Member,一个Member只能属于一个Pool，一个Pool 中会有 多个 Member，一个Member只能监听一个业务端口，    Client     同一个虚拟机的不同业务端口属于不同的Member。 Health-Monitor用来监测Pool中不同 Member 的状态，多次轮询后没有响应即认为Member处于不可 VIP 用状态，HAProxy将不再向该Member分配流量，    Member Member  Pool Member恢复响应后置为可用状态，之后HAProxy 分 Member) 配流量时会重新考虑该Member，一个Pool中可以没有/有一个/多个Health-Monitor。LBaaS的后端通常是通过专用的负载均衡软件来实现的，开源的主要有HAProxy、   Nginx以及LVS,OpenDaylight的Netvirt项目中通过OVS contrack简单地实LBaaS  LBaaS v1的架构很清晰，但是存在以下几个问题: 1)HAProxy的 namespace部署在网络节点上，会出现绕路、单点等通用的问题。 3)不支持应用层的负载均衡，若如URL重定向。    2)一个VIP只能绑定一个端口号，无法同时对多种业务流量进行负载均衡。     4)无法支持 TLS Termination。 为解决上述问题，LBaaSv2重构了 LBaaS v1的数据结构LBaaSv1 的 VIP结设计架构。Pool/Member/Health-Monitor 的 Listener Listener M 构中IP和端口号解耦合为LoadBalancer 和    Health    Default     Listener，一个LoadBalancer对应一个虚    Monitor    Pool     拟IP地址，一个LoadBalancer可以有一    Member l    Member N     个或多个Listener，每个Listener对应一个 HAProxy进程，负责监听一个业务端口。另    图5-18LBaaSv2的设计架构     外，Listener 还可以通过绑定容器来终结TLS，一个Listener可以绑定多个 L7Policy 来实现 L7的负载均衡。一个L7Policy可以有多个L7Rule,L7Rule 支持与hostname/path/file type/ header/cookie 进行比较。 不过，无论数据结构怎么变化，都无法改善HAProxy部署在网络节点上所产生的问题。解决的思路就是将HAProxy从网络节点中拿出来，将其放到独立的虚拟机里面，一方面位置上不再受到限制，另一方面可以在多个HAProxy虚拟机实例间实现高可用。 

关于网络安全、OpenStack的实现有Nova-Security-Group、Neutron-Security-Cna Neutron-FWanS。其中，Nova-Security-Group的作用点在虚拟机内部，是虚拟机内容销火墙。Neutron-Security-Group的作用点在虚拟机的接入设备上，是一组虚拟机的火家 Neutron-FWaaS 分为v1 和v2两个版本，v1作用于租户的router，为租户网络提供集中去级护:v2可作用于所有Neutron Port,为网络中的各类端口提供保护。这些不同粮度的安全领略为OpenStack网络提供了多层次的防护体系.在G版本之前，OpenStack只能提供Nova-Security-Group,而Nova-Security-Gron存在几个问题，如只能处理人向的流量，只能作用于一个虚拟机实例，在实现上对Ip Overlapping 的支持也有一些问题。在G版本中，OpenStack开始同时支持Nova-Security. Group 和 Quantum-Sccurity-Group,Quantum-Security-Group 可独立地实现安全组功能，够处理人向和出向的流量，而且能够作用于一组虚拟机。随着Quantum 迁移到Neutron Quantum-Security-Group延续下来自然就成为了Neutron-Security-Group。 一个Neutron-Security-Group 中包含1或多条规则，可以匹配流向和5元组，允许多个虚拟机端口关联到该Neutron-Security-Group中，也允许一个虚拟机端口同时关联多个 Neutron-Security-Group。安全组中的规则会在虚拟机启动时生效，启动后更改的规则也能够动态地生效，能够匹配某条规则的数据包允许通过，不能匹配任何规则的数据包将被丢弃。在默认情况下，每个虚拟机端口都会自动地受到一个Default Security Group 的保护，其中包含如下规则。 1)对于虚拟机发出的出向流量--允许通过DHCP 请求IP 地址，不允许对外提供 DHCP服务，只允许以虚拟机自身的MAC和IP作为源地址(防止欺骗攻击)，允许状态为已建立连接的数据包，禁止状态为无效连接的数据包。 2)对于发向虚拟机的人向流量-允许DHCP Server返回流量，允许状态为已建立连接的数据包，禁止状态为无效连接的数据包。 在Neutron-Security-Group的实现中，通常使用LinuxBridge作为provider,即使在使用Open vSwitch进行转发时，虚拟机端口和OVS端口间往往也会接入一个Linux Bridge 作为过渡。这是因为Neutron-Security-Group需要进行带状态的防护，而早期版本的OVS中流表并不支持带状态，想要实现带状态的规则只能由PacketIn给控制器，这在性能上存在很大问题，因此要以LinuxBridge作为过渡，通过Iptables来实现带状态规则。 后面随着OVS对 conntrack 的支持，社区中有人提出通过OVS来直接实现带状态规则，从而去掉LinuxBridge，以简化组网结构。这种思路无疑是正确的，但是现在的成熟度和性能都有待验证。目前来说，仍然有必要保留LinuxBridge作为安全组的实现。在本书 从H版本开始，Neutron提供了FWaaSv1服务，其默认的实现是在网络节点上的 router namespace 中部署Iptables规则，对进出租户网络的流量进行过滤。FWaaSv1中有3个主要的概念:firewall rule是防火墙规则，能够匹配五元组，支持allow/deny/reject3个动作:firewall policy是一组firewall rule的集合，可提供策略的审计功能;fitewall是防火墙的逻辑概念，一个firewall只能有一个firewall policy.一个租户只能有一个firewall.不同租户可以共用一个 firewall(即一个firewall可以关联多个router)。 可以看到，FWaaSv1的设计是从传统网络中借鉴过来的，它主要提供的是网络级别的防护。不过在虚拟化环境中，这种级别的防护是不够的，比如租户内部的东西向流量不会走到router上，因此FWaaSv1无法提供对东西向流量的保护。Neutron-Security-Group 能够为虚拟机提供保护，但是它的设计初衷是为了保护虚拟机上的应用，因此它匹配的通常是源IP+目的端口(对于ingress方向)，或者目的IP+目的端口(对于egress 方向)，而不支持同时匹配五元组。 从M版本开始，Neutron提供了 FWaaS v2。FWaaS v2将FWaaS v1和Neutron-Security- Group 两者的功能和特点综合到了一起，既能提供灵活的匹配规则，又能提供虚拟机级别的防护。从设计上来看，FWaaSv2引入firewall_group的概念代替了FWaaS vI中的 firewall，一个firewall_group中包含ingress 和egress两条firewall policy，一个 firewall_ group可以关联多个Port(而FWaaS v1中firewall要关联的是router)。而firewall rule和 firewall policy的概念并没有大的变化，只是在firewall rule中去掉了reject这个动作。 FWaaS v2的上述设计，提供了一种通用的安全策略描述，连带着把FWaaS v1和 Neutron-Security-Group中一些其他的限制也都解决掉了。FWaaS v2相比于FWaaS v1，增强了如下特点。 1)提供了端口级别的安全策略，可作用于router端口、虚拟机端口或者VNF端口等。2)一个策略中可以为ingress和egress两个方向关联不同的规则。3)一个Neutron Port可以关联多个firewall_group。 4)有计划地引入address group 和 service group,将IP地址和端口号解耦合。 FWaaS v2相比于Neutron-Security-Group,增强了如下特点。1)支持显式的deny 操作，rule的组合可以更加灵活。2)可以同时匹配五元组。 3) firewall policy 可以在firewall_group间复用。 4)有计划地引入address group 和 service group,将IP地址和端口号解耦合。5)未来 service group可能会支持L7的语义。 

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进入技术群

作者：达益鑫 |南开大学，刘家伟、吴锟 |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进入技术群

自2024年1月1日起，云推官通过华为云奖励推广计划成功推荐所得返利金额的相关个人所得税由云推官自行承担，华为云将依据《中华人民共和国个人所得税法》及其他相关税务法律法规规定，为云推官代扣代缴税费。计算方式如下：举例说明：a) 当月收益为65000元预扣劳务报酬个人所得税：65000*(1-20%)*40%-7000=13800元b) 当月收益为62500元预扣劳务报酬个人所得税：62500*(1-20%)*30%-2000=13000元c) 当月收益为25000元预扣劳务报酬个人所得税：25000*(1-20%)*20%=4000元d) 当月收益为4000元预扣劳务报酬个人所得税：(4000-800)*20%=640元e) 当月结算收益为800元，无需缴纳个人所得税。感谢您的理解与支持。相关问题FAQ1、当月收益是指什么？当月收益是指已扣除代征的增值税和附加税费（如有）后的金额，增值税及各类附加税金额以增值税发票、附加税完税凭证记录金额为准。2、什么时间开始的推荐会受影响？2024年1月1日开始，云推官通过华为云奖励推广计划成功推荐所得返利金额，采用新规则执行代扣代缴，2024年1月1日之前成功推荐的返利金额将不受影响。