欢迎大家参加此次酷不抗的分论坛然后呢 本次有我跟我的同事给大家带来的议题是HyperNight让OVERLAY跟Android网络在你的KBS集团当中完美共存然后首先先做一下自我介绍我来自蚂蚁集团然后我叫马文君然后我是CIA社区的Maternal然后也是此次演讲的这个项目HyperNight的Owner然后呢 同时我也是一些开人项目像KBS酷不抗的一些项目的Member在整个开人社区我也是有一定的积极的贡献然后呢 在马蚁集团的商业化部门我是负责了那个应用PASSFailouts 还有混布等产品的商业化然后下面是我个人的联系方式如果大家有容器网络相关的问题可以直接找我大家好 我是方亮然后我也是来自蚂蚁集团的研发工人师然后我在蚂蚁主要从事的是应用PASSFailouts还有混布相关的一些项目和产品的建设然后下面是我的联系方式大家欢迎大家一起交流首先今天我们分享的内容大概分为四个方面第一个方面是在混合云的场景下我们容器网络面临的一些挑战然后第二部分我们会介绍HyperNet这个项目为了解决这些挑战然后我们介绍的这样一些内容然后从一个比较宏观的视角先给大家介绍一下然后后面第三部分呢我们我的同事会给大家介绍HyperLate这个HyperLate比较独特的混合网络平面的这样一个feature的一些设计和实现的细节最后也会介绍HyperNet在其他的一些诸如IPM这些相关的一些高阶的特性首先关于HyperNet的背景是这样子的我们大家都知道在单一厂商的公用云或者大型的专用云底座上容器网络的方案一般是比较跟底座的能力是有紧密的偶和的因为这样可以利用到底座的一些虚拟化的网络的能力来极致地去提升网络发言的性能比如像AWS的AWSCNI或者阿里云的特位然后这样一些弹性网卡的这种方案但是在混合云的这个基础设施上问题就不一样了首先就是我们在异购的这种混合云的这种基础设施之上我们还要保证一致性的功能然后去适配底座然后其次在比较复杂的这种网络环境下我们还要去保证比较敏捷和稳定的交付的能力第三部分是在混合云这种场景上我们还比较强调用户视角是比较统一的运萎的这种能力最后高性能也是绕不开的话题不管在什么场景下我们都希望网络的平面是具有一个比较高的性能根据上面我们所采说的这种挑战在混合云的场景下我们可能需要的容器网络的方案它需要具备这样一些能力首先它需要为用户提供一个统一的网络模型来降低用户它使用你这个方案的认知和维护的成本这样的话也可以变于你这个方案的长期的眼睛第二部分是我们需要把依购的这个基础设施的复杂性从用户层面给它屏蔽掉这样的话可以保证这个用户使用的这种便捷性第三部分是高性能我们很多用户都希望一个高性能的网络直通方案既可以与存量的这个网络去打通然后也具备比较高的转发性能为了实现上面的这些能力我们还不希望引入比较复杂的这个外部组件这样的话会进一步提高这种混合云的这种复杂场景的这种复杂性所以我们希望最小化对底层网络技术的依赖比如我们不希望引入一些高版本的内核或者SDN的这样一些这种能力那最后呢比较基础的我们需要与K8S做这个深度的集成为用户提供双占、IP Retain 这样一些iPad的能力那这个也是要保证用户的使用习惯不变那我们刚刚上面讲到的这些需求其实有些是相互是存在着某种衣裳的矛盾的就是你既要屏蔽底层的易购基础设施快速地交付部署又要去提供高性能的网络直通来网络直通那这两者似乎是比较矛盾的那我们都知道容器网络主要分成Underlay和OverlayUnderlay的话是原封不动地把容器网络的报文然后转发到这个底层的这个速度级网络然后在依赖底层的这个网络通讯的能力把这个转发的这个数据转发面打通那Overlay的这种网络放一般是依赖IPIP或者为Channel这种隧道通讯的协议然后去屏蔽底层的易购的这种基础设施但是Underlay它的高性能的同时又带来了于底层的技术设施偶和的这种复杂性Overlay它虽然屏蔽的底层这个技术设施它又因为风暴解暴带来了这种性能的下降所以我们在混合运的这种场景下想要同时满足两种似乎必须要同时引入Underlay和Overlay所以我们在思考我们是不是可以在一个集群里面既引入Underlay的网络又引入Overlay的网络我们在交付的初始阶段我们通过Overlay的网络来保证整个集群的拉起基本网络的通讯这些使用是非常快捷非常敏捷并且很稳定的那在拉起整个集群以后我们可以通过白屏的方式再去配置一个相对比较复杂的Underlay的网络那这样的话就似乎实现了既满足了屏蔽底层基础设施的复杂性然后又能够提供高线的网络指导方案的这种满足了这两个相对比较矛盾的这个需求所以根据我们以上的这种思考就是我们整个的目标就定义为我们需要去建设一个容器网络方案它不基于一些复杂的外部的这种组件或者说底层的网络技术我们希望用比较成熟的底层网络技术然后来构建一个在Q8自己中共存的Underlay和Overlay的这种混合网络平面它具备并且针对这两种类型的网络都有比较灵活的并且可以扩展的iPad这样一些能力那面向这个混合运的这个场景我们整个HyperNet的容器网络的权局的设计约束是这样子的首先在节点级别我们需要同时支持Underlay和Overlay两种模式的网络第二方面Overlay的POD跟Underlay的POD是完全互通的并且可以原生地支持Q8s的Service和Network Policy第三部分是Overlay和Underlay是共享一套网络模型的同时具备高阶的iPad能力比如说网络的调度或者说IP的保持IP的指定等等那关于Underlay和Overlay本身的一些网络特性它是也有一些约束的比如说Underlay的网络它是具备比较高的网络性能也可以与外部互通支持基于节点的标签的调度等等那Overlay的网络它是权局唯一的不需要调度IP可以在全集群内任意的飘移同时也可以与Underlay的网络互通但是也要满足一个条件是Underlay和Overlay的网段是不能冲突的并且与在跟客户的存量的网段就是客户环境的这种存量网段也不能冲突那关于Hebronite的项目本身大概给大家介绍这样一些信息吧Hebronite它是已经被一些阿里或者蚂蚁的商量产品在使用的比如说阿里原的SKD以及蚂蚁的SofaStack然后Hebronite目前已经在接近100多个占点在使用了那Hebronite它整个组件整个网络解决方案本身具体可以抽象为两个比较大的方面一方面我们可以看到在节点利路上有个habsdn那你可以把它理解为它是构建整个数据面的这样一个组件当然这是个抽象的组件它可能底下还包括了一些更细节的一些组件那在集群利度它有一个hab components在图里面所展示的它会去负责集群级别的一些ipam然后基于Hebronite定义的一些网络模型比如说network subnetipinsense这样一些东西去做一些调和以及泡达ip分配reserve这样一些事情然后我们hab components它所管理的这样一些网络模型主要是这三个首先我们network它是一个调度域的它是一个pod的调度域并且它是就是每个pod它是属于哪个network的它一定会被调度到这个network所在的调度域每个network它实际上会跟一组的k8s节点所关联一般来说这样的一组k8s节点它是具备着一些相同的网络特性的比如说他们的vlan tag是一样的那subnet它是属于一个network的它其实就是一个ipadress的range那每个ip instance每个ip都是从一个subnet里面分配出来的每个ip也会对应一个叫ip instance的这样一个模型它是属于一个pod的当然了在一些比较特殊的场景比如说ip reserve的场景下它可能会属于work load的级别那ip instance它是一个命名空间力度的资源那刚刚讲的network跟subnet它是一个集群力度的资源这是一个network subnet和ip instance的一个势力network的话它比较核心的特性比如说net id比如说一些vlan tag然后它也会指定一组节点那就是一个node selector它的status里面会显示属于这个network的一组节点并且会有一些整个network下面所有的subnet组合起来的就是统计出来的整个ipam的一些统计的结果那subnet它就对应一个ip range所以这里面它主要就定一个cdr或者在status里面也会展示当前已被分配的ip或者说也有些这种比如说我在subnet的创建的时候就result的一些不给随便分配的让一下ip的信息那ip instance这个ip instance它其实就是属于一个staff set的一个ip instance它是它也对应着这个staff set下面的一个pod那这里面就主要是一些ip的信息它会被数据面的组件去使用消费然后去为这个pod setup一个network相关的一些转发的这个比如说规则路由规则之类的信息下面会介绍一下这个hypernet它整个component大概有哪些它主要分为四个吧一个是manager它是一个controller然后它主要负责两方面内容一个是ipam刚刚讲到的这些网络模型的管理然后还有一个功能是多级群的连接性的原数据的同步这个多级群的能力待会在后面会讲到然后web hook的话就是常见的validatingmutating的这样一些事情比如说我们刚刚讲到的基于node的调度域的调度如果你的pod指定了一个network去创建的话那hypernet的web hook会帮你去打上对应的node selector保证你调度到对应的调度域里面然后demon组件的话它主要分为两个小组件一个是server它是被hypernet的CNI这个bannerway调用的还有一个syncer它会去watch整个级群里面的app instance然后属于当前demon的节点的app instance会被demon处理去帮助作为这种local的这种数据面的打通CNN的话就是一个标准的CNN bannerway的文件那我们以一个pod创建的流程去讲一下这些组件之间的协同用户第一步创建了一个pod然后它会经过hypernetweb hook去给大家打上对应的node selector然后第三步hypernet manager会去调和pod然后它会去watch到pod并且给pod去分配或者说使用一个reserved IP然后去创建一个app instance这个app instance它会绑定到pod或者说它的workload那第四步就是cublate它会去callCNN的add command然后hypernetCNN就会去为pod setup network是根据刚刚它被分配到的IP instance的信息去实现的network setup那后面的内容就交由我的同事给大家介绍一下整个数据面的一些实现非常感谢我的同事在刚才为大家带来了hypernet整体的设计的背景以及它核心的模型还有相关的一些组件刚才介绍的部分其实大部分都是从控制面出发的对于一个容器网络解决方案来讲其实它的数据面也非常重要它决定了这个数据网络解决方案到底能支撑多复杂的场景那这里我主要讲的就是hypernet其实大家可以发现在我们的项目的名字就叫hypernet那hypernet这个东西其实不但代表了我们的容器网络解决方案在处理混合云场景下的一些eGoS物理级的一些复杂场景还代表了我们会构建一个混合的网络平面这个网络平面是通过这个统一的模型来约束不同的网络模式包括安德雷跟欧雷这也是我们在做设计的第一步就是确定我们的约束然后第二步根据我们既往多年的在容器网络设计和实现上面的经验我们把这个抽象大概分成两步第一步就是我们要确定跨节点访问的数据链路那基本上图是一个逻辑的图就是大家可以看到是对称的就是其实容器网络所能负责到的部分大部分是集中在node里面大概分成三部分第一部分就是容器要以可查把的方式接入素乳机的网络第二部分在素乳机网络要针对不同的网络模型做合适的分发第三步依赖于底层的安德雷的路径去完成真正的数据通信大概抽象为这三步然后我们整体的结构也是围绕着这三步来组织完成的那有了这三步之后第二步我们就要明确这三步在单一的节点当中如何实现那右边这张也是一个逻辑的图就是大概要有三个比较抽象的能力第一部分就是我要同时处理安德雷跟欧欧雷的流量第二部分我要因为安德雷跟欧欧雷对于底层基础网络的需求而管控一些微烂或者是微差烂的一些设备第三部分因为安德雷网络它有一个二层和三层的区分在这种三层的模型下二层网络需要做一些ARP相关的代理才能够完成通讯所以我们把整体的步骤拆成了第一步跟第二步去设计了或者抽象了跨几点的通讯以及几点内的通讯有了刚才的设计接下来就是我们的使人格实现在这个实现的图像中大家可以清晰的看到所有的欧欧雷和安德雷的通讯链路以及欧欧雷访网安德雷和安德雷访网欧雷的链路大概可以分成四步第一步就是流量要从安德雷或者欧欧雷的破损当中出来同时进入到素主级的命名空间当中第二步根据IP的原跟网段的匹配性决定它的类型第三步根据类型选择合适的网络设备第四步基于物理网络设备进行通讯那在这里其实整个网络方案用到了内核里面的像IPTables、IPside和这个策略路由相关的一些能力其中最核心的点就是我们的策略路由的能力那我们其实在设计完约束之后做技术选型的时候也是纠结了很久就是到底选什么样的解决方案来做这个转发其实业界有一些方案比如说选了这种OVN或者相关这些SDN的方案它会在解决问题的同时带来问题就是SDN本身的维护或者OpenVSV是本身的维护是一个痛点那么我们选了这个在内核2.2就已经成熟的一个策略路由的方案是解决了这个依赖就相当于在很低的版本我们也可以把容器网络打起来并且具备所有的能力那有了数据链路的设计跟实现接下来我们可以看到基于这个设计跟实现我们能完成什么我们在设计之处就把这张表格拉出来了就是为什么叫它混合网络平面就是我们在设计之处就必须把Android跟OVN的通讯统一考虑那这个图也是在还没有做网络实现的时候就已经确定了OVN跟所有的网络通讯都是双向隧道的方式并且只有一个特殊的点就是它访问外部的时候可能要做一定的SNET然后Android跟Node还有外部的访问走的是Android的通讯链路这个图也一直约束着我们做后面的所有的技术实现接下来我会通过AndroidAndroid加OVNOVN三个场景来具体的给大家展示一下这个网络的量在底层是如何通讯的以及我们设计上的一些小的点首先第一张图就是这个Android那Android在我们的整个设计方案当中是一个大融合的方案因为Android这个词相比OVN来讲它更复杂因为像我们通常在今天网络遇到的VLAN的场景Bridge的场景还有这个BGP的场景都属于Android那Android是否要再做区分呢我们认为不需要在一个网络当中在一个机群当中所有的容器都可以选择自由的选择不同的Android的模式在左边这张图像中可以看到左边这个机群当中BGPOVN类和VLAN的POD都是共存并且可以互相完成通讯的它通讯的技术就是依赖于刚才列到的广播路由和BGP一些底层的基础的能力第二块就是Android跟OVN类的访问这里需要提到的一点就是刚才那张图的约束我们在设计之初就确定了Android跟OVN类之间的互访不论是正向还是逆向的都不许走双向隧道的方式所以在这个图像中可以看到我们的BGP的POD访问OVN类和OVN类访问BGP的POD都是经过了VCHLAN的设备来进行互访的这样的互访有一个好处就是第一点它可以保证IP的可见性就是业界的很多方案其实基本上都是先有OVN类再有Android或者是先有Android再有OVN类那这种设计的劣势在于在Android跟OVN类通讯的过程当中很多的解决方案都遵循着可用进行并没有从最开始就设计这两边的通讯类是否合理所以就会导致这种情况的产生就是OVN类在访问Android的时候大多数的解决方案虽然它声称两个是可以互通的但大多数的解决方案OVN类都会在本节点做一次Android再去访问Android这就丢失了它原有的IP因为它做了一次地质转换在一些场景比如说对原IP有不可辨性的依赖的场景这种网络解决方案是会带来一些困扰的第二块就是路径的一致性然后我刚才说的就是OVN类访问Android的时候是走Android再走Android那Android访问OVN类的时候大部分解决方案都是走隧道的方式所以一个是走地质转换加Android一个是走隧道所以正向跟另一向的路径不一致也会跟问题的排查和网络的复杂性带来一定的困扰最后一块就是存OVN类的部分那这里就会涉及到跨集群的部分因为Android大部分基础设施可以保证Android是可以互相通讯的多集群并不是问题那OVN类带来便利的同时也带来了限制就是大部分的解决方案的OVN类其实是局限于单个集群的那在混混运场景其实有很多的业务场景要求我们去做跨集群的网络通讯那这里第一个能力我们的OVN类特色能力就是我们可以支持跨集群的连接这个在后面有一个专题会介绍我们是点着点通讯的也有一些高口用能力上的提升第二个就是在单集群的OVN类来讲我们使用的微差弹的这个技术相对来说比较老但是也比较稳定第二点就是OVN类的方案里面不可要过的一个问题就是寻职OVN类正常的寻职是走广播方案然后节点越多这个规模越大就越来越不可控制这种流量的稳定性那我们这里是采用了两层的方式去兜底这个寻职第一块因为我们的整个构建起的体系里面是包含了所有的原数据所以ARP和NDP的寻职可以通过用户空间的一个代理去完成快速的寻职这是一个基于效率的保证那第二点当控制面挂掉的时候这个OVN类还能不能继续通讯我们认为是可以的那怎么可以就是相当于我们不但在第一层做了拦截同时还允许它降级到广播的方式去做寻职这样的话即使在控制层面出现了故障整个网络通讯依然不会受到影响介绍了HybridLate这个混合网络平面的能力之后接下来我会介绍我们在长期的眼睛工业当中遇到的一些问题以及产生出的一些高阶的方案第一块就是多级群的网络通讯这块主要是针对OVN类来量这块我会分成两个方面来讲第一个就是数据面的控制面的多级群第二个就是数据面的多级群控制面的多级群我们称它为ClusterMesh的方案业界也有做多级群网络打通的更多的是选择了一个中心的节点去完成原数据在多级群的同步然后分发到多个级群这个带来的问题就是中心节点的平静会限制到和它的高口用会限制到整个系统的稳定性在我们的方案当中可以看到每一个级群都会跟不同的级群建联并且同步原数据缓存在本地这样的话任何一个APS側挂掉了只会影响其他级群跟它的同寻并不会影响对于剩下级群的一些同寻的稳定性第二个点点第二个问题第二个带来的好处就是我们全部通过KBS内置的扩展性的方式来实现的没有依赖于任何的外部的存储自然也不会带来多级群打通的成本第二个就是在数据列入上多级群的方案我们也有一定的特色这里可以看到左边的图跟右边的图的一个对比我们是左边的方案就是当跨级群访问的时候我们是直接通过节点寻执到另外一个节点完成通讯然后业界的一些方案大部分都是右边这个方案就是我先通过一个网关确定我的网络的对外可见性然后通过两个网关之间的打通完成多级群之间的打通这个带会带来几个问题第一个就是网关节点虽然可以通过一些网络学义理论上做无线扩展但是这部分的维护成本和它带来的网络的抖动基本上是对剩下的完全来讲不太能接受的然后第二点就是它的整个跳出回动度可以看到这里面发生了一 二 三大概三段的通讯但是在左边只有一段对欧欧类来讲这种本来通讯效率就不高的网络模型左边的方案会带来更大的优势那带来的好处也分成两块第一块就是在混合云场景的多级群打通第二块就是我们也内置了一个能力就是我们为什么要做欧欧类的多级群其实也是为了做这个事情就是多级群的service就是多级群service的能力其实更多的出现在多级群的场景我要做双级房的高口用或者是多级群的高口用的时候我可以通过一个级群的service访问到两个级群的后弹服务endpoints这个我们是通过多级群之间的endpointsless模型的同步来实现的然后IPM层面的一些高级的特性这里也有两个第一个就是IP保持第二个就是指定IPIP保持这里重点讲一下就是seed for workload其实解决的是有状态运用上云的一个迁移的问题它重点解决的是发布的稳态性跟存储的稳定性因为它用的是这个PV存储但它没有解决的是IP的稳定性就是它还是遵从的一个敏态就是IP是可以敏态变化的但是很多系统在刚上云的时候它其实摆脱不了对于IP固定的依赖所以在这里我们做了对于seed for workload的通用模型的一个支持不仅仅限于seed for set然后第二点就是我们在IP保持的同时同时要保证你调度上的一些参数的叠加最后一点就是对于社区现在的一个容器虚拟化的方案couple world我们也做了支持指定IP的话主要是三个层面network subnetwork IP同时我们还支持reserve的能力然后接下来要聊的话题就是高性能这个高性能其实说的不是数据链路的高性能数据链路的高性能其实通过Android的选型就已经可以解决了这里提到的高性能主要是我们遇到了两个业务场景所衍生出来的对于容器网络解决方案本身的高性能第一个就是边缘场景边缘场景带来的是低带宽的问题就是它带宽甚至照级别都不能够提供可能只是只能局限在k级别那如何在k级别的带宽当中我们依然完成一个稳定的网络管控这是一个问题第二个问题就是混布混布场景因为离线业务的调度屏字是远高于在线场景的所以高屏的调度也会给我们带来问题解决这个问题我们只要从两个层面来解决第一个就是为了解决低带宽的问题我们需要减少对API server的网络请求这里我们是去掉了node跟poud两个client cache的依赖对于poud的依赖我们是通过对于API直接读写的方式去解决因为我们认为其实cubelet在主张网络的时候也是触发式的所以我们通过这种触发式的方式来解决对于node client的cache我们分析出来其实主要是因为staters跟adaptation的变化带来一些高屏的数据的同步是无效的其实我们只需要node上面的一些部分的信息右边这个模型其实我们是做了一个转换先把node转换成node音符只保留我们有效的信息然后通过这个模型的同步来减少整体带宽的使用通过这个方案我们最后把带宽下降了大概两到三个数量级这是在我们1000个节点的生产矩形上做过实际验证的第二个就是IP的分配效率的提升第一块就是我们通过重构我们的IP instances的模型来保证了一次调度当中的核心更新只有一次剩下的全是异部更新这样就跟调度器的更新保证了在API请求上面是开销是一致的然后第二点就是我们通过client cache加本地缓存的方式既避免了对一个API的请求又保证了本地数据的一致性不会导致IP充值的方式发生那基于这两点我们是把IP分配的效率从数十个每秒提升到了1000个每秒基本仅怎么说呢比调度器稍微低一点基本可以满足大规模的离线应用的调度我们现在在混布解决方案当中用的也是这套的解决方案然后就要提到的就是双栈我们在双栈当中除了这个它是内置能力支持IPV4 ONLAYV6 ONLAYDeuxStack双栈这些能力之外这里有一点要提升的就是我们的双栈其实是在单网卡上做的我们认为单网卡对于用户的对于IPV6的迁移和使用成本是比较低的因为你给它搞多张网卡IPV4 V6它还要去十秒网卡这个对于业务层来讲是比较难的所以在单网卡当中我们更多的是在容器内部去做了一个单网卡的V4和V6地址的一致性然后在外部的话经过我们的逻辑的SDN之后它就会转发到不同的底层列入去进行通信所以在容器层面是内具的方便你使用在外面是比较自由的然后接下来就给大家介绍的就是我们在严禁的过程当中也是逐步支持了安德雷的不同的模式这里刚才也提到了对于VLAN, QG, BGP都是支持的那VLAN and Bridge就略过了这里主要提的就是BGPBGP目前我们主要支持的模式类似于Kalico社区的Downworld Default Mode就是每一个交换域交换机下面接入层交换机下面是一个跟交换机不同的通过EBGP方式连接的一个自制域你可以看到底层的100还有101跟交换机是不一样的然后第二点就是我们可以通过这个模型我们支持在接入层交换机层面的IP保持最后要提到的一点就是我们相比Kalico做的一个优化就是路由的聚合路由的聚合其实是BGP里面一个非常大的问题就是其实我一个子网其实是分配给了这样一个红色的框或者是蓝色的框但是在它同步的工程当中它其实只会同步我已经分配出去的IP那你已经分配出的IP如果你是跳着分配的话其实在BGP协议层面做路由聚合就非常困难那我们是怎么做的我们是通过BGP协议上的一些参数控制让它保证在单个IP的对外宣告的工程当中只会宣告到接入层交换机但是在Subnet就是子网层面会宣告到接入层交换机并由接入层交换机继续宣告到Subnet交换机这样就保证了我们的IP的复杂性以及不可聚合性只会保留在接入层交换机对于顶层的核心交换机不会带来过多的冲击然后路由收敛问题自然而然也就会解决然后介绍好了我们的高级能力之后最后还是希望因为我们是一个开源项目希望大家能够多多参与到这个开源项目然后最近我们在规划的几个能力就是第一个就是多安卡的能力第二个就是虽然我们说我们在class-to-match的方案里面是点着点通信的当然在某些特定的场景下在通信受限的场景下指定网关节点的能力是非常重要的最后一个就是BGP刚才说了只支持一种模式后面我们逐步拓展到多种多模特的BGP模式的支持来适应更多的场景那我们在怎么样加入我们呢就是在slag上面我们有一个Hebronite的channel虽然里面人现在不多但是大家可以加入进去我们会在那里面去解答问题第二个就是我们刚才也分享了speaker的一些私人联系方式大家可以联系我们最后参与开始说去的一个通用方式就是直接在开源仓库里面提取或者是tpr我们会最高优先继续处理这个问题好的那今天我们整体的给大家带来的议题就讲到这里了大家有问题吗你好我想问一下这是一个CNN的解决方案吗对是CNN协议的解决方案那它的主要应用的业务场景是啥就是说安德勒和OVERLAY就是说我们OVERLAY比如说OVERLAY我们可以自己指定那个方案吗比如说使用VXLAN还是使用GNIV就是这种OVERLAY的方案可以自选吗还是说就是OVERLAY的方案目前底层的协议都是用VXLAN来支持的没有协议上的自选那它那个业务的应用场景是什么就是说那OVERLAY和安德勒比如说两个炮的之间通信它具体是走OVERLAY和走安德勒这个是怎么定的这个是你在创建的过程当中要指定你使用OVERLAY还是安德勒通过安德勒的方式去感知那比如说两个炮的之间一个属于OVERLAY的区域一个属于安德勒的区域那就是为什么会有这种场景呢我举个例子吧比如说我们在做一些能力的对外交付的过程当中其实交付的第一场景就是我们要把核心的系统拉起来如果这个时候你选择了安德勒的方案的话你会浪费很多的时间在安德勒的交付和配置上其实这个东西是一个异部的过程你可以先通过OVERLAY的方式在这个机型当中快速拉起核心的系统然后通过核心系统白平化的方式再去管控或者配置这个机型把它的安德勒能力补齐安德勒的能力可以在这个业务系统其他的业务系统起来的时候把一些网关类的用用部署的安德勒的能力上让它具备对外的可见性又具备高特性然后内部系统的一些对于性能要求不是很强的一些交付就走OVERLAY这样的话也不会对外部有过多的一些技術设施的要求那这样的话OVERLAY和安德勒之间他们两个之间的交付并不频繁 是吧可以频繁在整合机型当中OVERLAY跟安德勒的交付没有网络瓶颈OK然后还要再举一个场景比如在混布的场景就是对于可能离线任务会许非常多有些需要依赖于独立的IP在任务场景下我们会推荐用户的混布的一些任务使用OVERLAY的IP因为它只需要访问别人并不需要别人访问它那对于这里面的在性业务我们会推荐安德勒的方式通过对外可见性已经高性能的方式保证在性业务的稳定性好 谢谢你好 我看到你们为了混合安德勒和OVERLAY引用了一个模块就是它可以让安德勒的同性走这个过程然后到OVERLAY然后我想问一下引用这个模块它是运行在用户态还是内核态它会引入什么性能损失吗你们有Bentchmark过吗我们做过Bentchmark就是是这样的就是对于安德勒来讲能力不应该损耗超过10%引入了不同的技术之外引入了内核的技术以后然后你刚才说到的整个技术我刚才也列到了我们用了内核里面的IP Tables策略路由然后包括IP Side相关的一些能力这些能力都是在地版本内核经过大规模验证的所以其实你看到的是一个SDN的整体的解决方案但是里面其实是由比较稳定的内核级别的规则来实现的谢谢我还都想问一下刚才那个产品的问题你刚才的产品我觉得还挺有意思的我就确定一点就是说你刚讲就是OVERLAY和安德勒的这个混布这个事儿实际上是讲就是说在这个物理机上我直接去用它在安德勒对吧然后在安德勒可能是不是就用了类似HOST的网络这种就是直接用物理机的IP地址然后类似于用一个网桥的然后这样把容器跑起来然后因为然后它没有用到Wi-Fi的产品所以说你这个产品里面需要有这两层的东西要互通是吧是的其实OVERLAY其实有很多种你刚才说的桥接是一种然后VLAN也是一种然后BGP也是一种其实它本质上都是利用了这个底层其实它都是用到了底层的一些网络通信的技术只是在那个素主机层面稍加组装而已好其实我对这个场景还蛮感兴趣就是为什么会有这样的这个场景因为一般我们在那个容器里边其实如果是对外要访问的话一般是走比方说四层或者七层网关比方说在云上可能是走一些这个叫做Low Balance比方说二里叫什么AOB对吧就是这个好像是直接在这个素主机上跑些这种高性能的这种混布场景这个要么就是一个集群对吧如果是针对这个集群里边它有这个高性能的话就是直接画一个K8S集群来搞这个好像很少见到这种两个混布所以说这个场景是怎么来的是这样的就是不是所有的业务体系都适合用网关的点对点通信是某一些高性能场景的一个很基础的方案我举个例子比如说大部分的中间的解决方案都是有一个寻止系统然后这个寻止系统它可以寻止到后面所有的server而跟任何一个server见脸然后保证它整个server的横向扩展性那如果你在这里建一个网关不是不可以但是整个的横向扩展性会被你这个网关限制住所以在业务场景上来看是存在着点对点通信的那点对点通信就不可以通过刚才您说的这种网关的方式解决那点对点通信的一个基础的要求就是我的IP起码要能被别人访问到那被别人访问到就基本上就代表着你需要选择安德类的方案对我问一个问题啊就是现在不是BPF很活吗然后你们有没有考虑去用BPF方式去实现有的有的其实在我们的解决方案里面我们已经跟业界的一些EBP方案做过集成做过验证就是我举个例子比如说现在有一些通过EBP实现Service或者Network Policy的方案可以跟我们的模型直接集成这也是我刚才提到的就是我们在做网络设计的过程当中没有直接用巧接方案而逼迫着所有的安德类跟欧尔类链路第一条一定要走到素书记内核因为它只有到素书记内核它才能跟社区的一些Cooproxy或者Network Policy或者是EBPF做得很好的兼容对 我想问就是下面那个底层的比如说像什么比查链封装啊或者说那种BGP这种路由这种对 有没有考虑用BPF这种方式这个应该暂时没有对OK我想问一下还有一个就是刚才想问一下就是那个一个集群内它是可以同时布安德类OVERLAY的 是吧可以的你好我是想问一下刚才您说就是关于低带宽的那个场景就是我们是什么场景下遇到这种低带宽的这种问题我刚才提到的大的场景是边缘边缘其实就是像Open Yard之类的几个方案其实通过一个代理的方式让你的节点能够访问到中书的API Server但是这个代理的方式它基本上走的就是一些类似公网就是不太稳定而且带宽受限的一些场景不像我们正常组网我们是拉一条专线这个专线的带宽非常高所以在这种网络受限的情况下你一丁点的网络带宽都很珍贵所以其实是从性能上来讲但是不能有一点的浪费否则就会对这个网络环境的整体的管控带来影响假如是有一种场景它带宽是非常低的就是我们只是通过传输的数据减少传输数据量这样的方式解决的是的有考虑过通过在网络层面比如就是网络上的荣誉或者之内发包的这种方式有考虑过吗当时你们针对这个场景有做过其他方面的调研和设计的这种考虑吗对 您说的思路是一个非常好的思路但是其实对于边缘节点来讲对于云产品来讲它管控的更多的是占点内部的一些东西网络其实这部分更多受限于我们首要实施的客户它所能提供的能力然后正是因为这段网络提升带宽的成本过稿所以我们才选了降低带宽的方式如果提升带宽很容易的话其实大部分客户都会选择提升带宽的方式因为是确实我们也一直在考虑热网就带宽的这种环境就是我们会考虑一些比如就是蒸发或者热鱼但是不会在因为我们数据量可能还是会属于比较大它指节点它会和中心节点比如做通信的时候我还是去需要发很多数据我们只是在解决了网络层面上面在NLK IP或者内这种上面的这种这种信息上面的这种解决方案就比如我实际上面的数据就是发送业务数据的时候有过这种考虑吗对于边缘来讲您刚才说的是其实是云跟边之间的通讯是吗我没有理解错的对 那是于这种其实云边的场景我们遇到的大部分产品都是边注重的是管理它上面的业务是独立对外提供服务的除了一些像包分发之类的一些非实实的业务会通过这条云到边的链路分发给边之外边产品更多的是独立提供服务的它并不依赖于中心给它提供的一些服务我不知道我表说清楚了没有大部分边是自制的它的不自制的部分就是体现在它跟APS over或者整个集群之间的连接OK了解如果是云跟边之间有重度的通讯的话我依赖可能不是我们认为的标准的云边的场景好 谢谢我还是想follow up问一下刚刚那个场景的问题就是在underlay的情况下说是比如说在一个note上有多个pod需要使用underlay的网络的话你们是怎么分配IP或者interface的首先刚才也提到了就是我们的网络是分了几个模型的networknetwork是个大的调度域它其实代表了一堆的机器然后在接下来里面是有subnet的subnet其实它有两个信息第一个是它的网段第二个是它的网络类型也就是说在一个underlay的network下面你可以创建BGP的字网也可以创建VLAN的字网也可以创建乔街的字网那你最后在pod的androtation上面生命你要使用哪一个网络类型比如说你生命的BGP那你就会使用BGP刚刚的场景的字网从那里面分一个IP出来比如说在同一台host上会可以分配多个比如说underlay的pod上去吗可以的就看你本身底层的underlay的实现是吧是好的然后还是想问一下那个场景的问题就比如说你们这个我不知道这个场景是不是你们混合云是在onpremise的data center里面那如果说我是用cloud provider的一些场景的话可能我本身并不能控制说它怎么分配这个网络模型的我举个例子比如说在Adebase上那个Celium它有ENI的这个模式它其实本身就已经拉平了这个网络就并不存在这种场景了是不是是的所以就是这里正好到这一眼这里我第二个能力就是指定网关节点其实也是为了这个考虑就是虽然我们希望所有的混合云当中的占点或者kbs都有我们来维护但是肯定会遇到某些场景就是用户有一个机型它希望跟我们创建的一个进行点打通那打通的话刚才我提到的这种多机型网络打通的这种点对点的方案就不太适用了可能更多的是我现在要把它集中到一个网关节点通过我们暴露出来的网关节点跟云上的一个网关节点之间的打通来保证这两个环境之间的糊涂OK所以像这个情况还是需要有一个getaway的是的好的那位先生刚才那个已经问了我就是也是同样的问题吧就是这个跟因为我们现在云上都是vpc的这个网络也是一个ovelia嘛对吧就这块的打通包括性能会怎么样嘛无论在云上云下其实都有云下有混合云混合云输出也是整个都一般都会挨死的输出嘛都会有vpc啊这些这些东西但你这个东西是不是跟它是一个平行的一个环境还是说也可以在vpc内部去使用这个东西对就是vpc上我们其实更推荐大家使用vpc native的网络解决方案比如说在awc党有awcni然后在阿里云上有特位我们其实更推荐这种的然后至于网络打通的话其实我刚才说的可能我们如果真的是要把我们的网络解决方案跟云上的网络方案解决打通的话可能需要一些底层链路的配置这个可能我们看过不了我们能看过的了就是我们把我们的出入口标明好然后其实我知道现在很多这个混合云其实并不是puzz层面单独的事情刚才您提到的有可能艾斯也在做混合云解决方案的时候那艾斯不可避免的就是他自己会有对于vpc内的机讯的管理以及他要管理单方的机讯那这个时候的一些打通的链路我理解是在艾斯层面的打通跟这里提到的我们说的这个puzz层的混合云的方案是不太一样的切入点不太一样就你这个第二个就紧接着就这个东西也可以比如说我在vpc里面我申请了一堆虚以及虚机对吧也可以用你这个hybrid net这个方式可以的但是目前仅能用overlay仅能用overlay的是吗对因为就 underlay的话就相当于我们如果做这个事情的话从模型上来讲是没问题的对network其实就是子网就是那个比如说阿铝云里面的这个交换机对是模型上是对得上的然后底层了也对上但是做这个事情跟比如说云上的网络插件其实就冲突了ok好的谢谢