喂喂大家好应该人差不多了吧那我们先开始吧就是非常高兴今天可以站在这块跟大家分享一下我们OPIO社区这边做的一些事情然后主要沟通内容呢是在我们在社区日常沟通交流中跟客户的一些问题和一些解决方案然后我们希望可以把这些解决方案分享出来给大家做一些经验的分享然后也希望可以受到大家的一些反馈然后我们可以碰撞出一些新的一些思维的一些火花然后看看有什么创新的点是这样子的对然后我们本次分享的标题内容是呢就是K8S原编写统去优化大规模智慧园区的一个管理本次分享的内容有一下几个方面第一个方面是我们这一次分享的一个产品背景然后我们在这个分享过程中就是这个产品过程中发现的一些问题和挑战以及我们使用open out的这样一个架构设计然后open out这边的一些核心特性最后是一个问答环节然后本次分享呢是由我和来自阿里云的这个何林波同学那个我叫何林波对然后接下来先由我这边来做一下这个产品的一个背景介绍因为我们这次是做智慧园区的一个改造的一个项目那么在传统的环境下其实我们可以看到我们的园区和园区之间它其实是一个相互隔离的一个状态并且我们的园区它们的之间的距离也是可远可进的那么在园区的一些基本的一些设施管理方面我们可以看到这些边缘的服务器它基本上分成两种形态一种就是会离我们的中端设备会比较靠近的一点另外一方面是在各个园区它自己独立的机房内进行一个部署那么这样子就会带来的一些问题那么第一点问题就是我们的边缘服务器因为分布比较广泛我们的传统运为同学它需要去发布一个应用的时候它经常会需要使用传统的方式去登入到这个节点上面然后去进行一个应用的部署那么这个节点的分布又很广泛它需要重复操作很多次这是第一个问题那么第二个问题就是我们的每一个园区它可能会部署十几套应用那么我们有多套园区那么它还是需要重复去操作这样一个事同样也是非常烦的一个事情非常烦悚的一个事情那第三点呢因为我们的传统的客户它可能它的技术架构能力不是很高那它一开始在做一些事情的时候比如说一些服务IP的手它可能会固定写死那么一旦它发生了服务IP的变化它需要重新去生成并且发布这样一个应用又会陷入到前面两个的一个循环当中去非常的麻烦那第四点呢就是我们的云端和边端的网络没有打通那在这种情况下云边业务的护访是一个很麻烦的问题那么第五点呢就是说在传统的环境下我们的主机包括我们的应用因为没有接入上云它的一些监控管理也是一个很大的问题和挑战那么最后一点呢就是在传统的环境下我们的客户的一些使用场景的应用部署还使用传统的二斤制甚至是Docker Run的方式去做它没有接入上云它也是一个很难的管理的过程那么基于此呢客户一开始这边会有两套解决方案来去进行一个选择第一套呢就是使用多几群架构的管理那也就是说也就是说我们在每一个圆区里面去搭建一套K8S那么我多个圆区我会搭建多个K8S那这样带来的好处呢第一个就是我可以保证我这个圆区的可用性也就是说一个圆区如果出现了故障那我的别的圆区是不受干扰的这是它带来的第一个优点那么第二个点呢就是说我可以去独立地管理我当前这个圆区的一个资源那么我就可以去更好的去做我的那个运用产品的一个优化那么第三点呢就是说我们的这个第三点呢就是说它可以更好的去使用这个产品的一些那个抱歉我看一下不好意思就是第三点呢它可以更好的去使用这个产品的那个对它每一个产品的圆区它可以更好的去有自己的独立的管理员或者管理团队去进行负责那它们的分工会非常明确不会出现一些调的问题那最后一点呢就是每个每个圆区的每个集群它可以有自己独立的一个安全策略保障外部的一个安全防范攻击这是一个多级勤加购的一个方案那么第二个呢就是它的一个使用采用单级勤加购的方案设计来使用它的那个智慧源区改造那这里带来的一个好处就是它会把云端的控制面放在它放在云上面然后每一个圆区的独立的企业可以作为一个节点接入上云那么这样带来的好处就是第一个我只需要一个管理员来管理多个远区的事情它可以提高它自己的管理效率那么第二点呢就是我不同远区内我其实是可以去共享整个集群的一些节点包括网络存储的一个资源提高我们的资源的一个利用率那么第三点呢就是我每一个圆区可以去自己独立的使用我的一个命名空间包括我的服务包括我的容器等等自己的那个资源的隔离独立性那最后一点也是最重要的一边就是它可以去减少我们的硬件和软件的支出成本这个是客户这边会比较重点关注的一个东西那么基于以上两个方案呢客户这边会优先会选择使用单个集群加购的方式来进行它的支援去改造那么我们在使用传统K8S的时候它会发现一些目前已有的问题是需要去解决的那么这些解决的问题这边会有说一下第一个是关于边缘节点自制的一个问题因为我们都知道在K8S正常的那个环境下如果一个边缘节点它跟云端的网络发生了故障那如果边缘节点它的心跳默认情况是五分钟如果没有上报的话那么云端会对这个节点的容器会进行一个驱逐操作那么有时候可能真的就是边端和云端它的网络出现了斗动或者说什么样子但是我边端服务器还是在正常运行的那我边端业务也是在正常工作这个时候云端对这个POD进行那个驱逐操作那其实等这个网络恢复之后会对业务产生一个中断效果这个是客户不希望看到的这是带来的第一个问题第二个问题就是也是在这种云边断网的情况下我们都知道我们的很多的数据它其实是存储在内存当中的一旦这个容器发生了重启它需要在重启之后跟云建立连接才能拿到一些相关的数据那这个时候因为云边网络是断开的它拿不到这个数据那就意味着它的容器重启失败那它的业务也会产生中断这是第二点第三点就是我们知道每一次不管是你在线还是离线情况下每次的容器的重启Qubelit会重新调新i的插件给它生成一个新的容器IP那如果这个时候因为网络中断你新生生的IP没有办法通知到别的节点上面那么别的节点还是用老的IP给你进行业务访问那么此时还是会带来业务中断那个效果因为这个是在网络断开的情况下那第四点就是一个高可用的情况就是我们在正常的情况下如果一个节点发生了故障我们没有办法完全得知这个节点是真正的异常挂掉了还是说因为网络斗动导致的云边的网络通信异常挂掉的这个办法我们没有办法就是有一个很好的方案去把它探测到这是第四个问题然后最后一个问题就是在实际业务场景中我们比如说像一些IoT设备像一些AI设备我们需要把这个算法或者服务部署在固定的节点上因为我们的边合端是在异体的我需要做一个节点绑定那么在这种情况下即使出现异常或者说需要迁移的时候这种场景下我们是不希望业务进行一个迁移改造的所以我们希望业务和这个节点进行一个强绑定关系这是发现对于边缘节点自治这种情况下带来的一些问题和挑战这是第一个方向那么第二个方向是关于工作负载的一些挑战和需求也就是说在整个边缘场景下我们的节点可能会很多那我们的客户我们希望是说我有一个统一的地方去维护同一类的边缘节点应用而不是说我独立的去给每一个人去每一个应用去做不同的达巴赛特这样的一个部署他是希望有同一个地方去管理这是第一点那么第二点他也就是希望说我部署的这个应用我可以做一些差异化的配置也就是说我可能只是做一些比如说副本术或者说镜像术的但是大体是一样的我希望做这种差异化的管理然后第三点可能客户他希望我边缘端在升级过程中是和云端独立开的就是我边端可以自主去选择我需要升级哪些服务而不是说而不是说通过云端统一的进行调控和管理他希望边缘云和他的升级是独立分开的那么第四点就是他希望有一个恢度发布的过程也就是说我可以在一开始选择部分节点进行或发布而不说权量的发布可以保证它业务的一个可用性这是关于工作负载这边的一个需求和挑战下一个是关于网络这边的挑战这边我大概列了三点第一点是关于服务托普也就是说我可能有不同的原区我希望在云端一次性部署同一个服务但是我希望我在不同的原区内我获取到的这个容器的一个访问节点是我在这个原区内自洽的也就是说我自己访问自己原区的我不希望跨原区访问这是我需要的一个服务托普的一个能力第二个能力是关于流量附用的能力也就是说我同样的一个上云那我可能就是比如说正常做一个节点的更新我的npoint会发生变化破dip发生变化npoint发生变化那么这样的更新我如果整个节点时会很多的话每个节点很多的话那我可能会产生大量的流量往每个节点去更新然后我们这里是云和边它的债宽是非常有限很像昂贵的所以客户希望去减少这部分的成本支出这是第二点然后第三点因为我们都知道正常的边端是在一个独立的私网环境下面的然后客户有时候如果你要用k8s去管理的话他希望可以打通云和边的网络可以做到运为命令的操作比如正常的查看日治包括exec登陆到这个容器内去做一些法问他是希望可以正常地进行云边运为操作的那么基于以上这些东西客户最终他是决定使用k8s加openout的这方案来解决智慧远区的这样一个改造那么我们先看一下它改造之后的一个效果那我们这个客户它目前可以做到就是不同的远区的每一个企业作为一个节点来进行介入那么可以达到目前它的远区内以后有500多个边界点来进行一个法问这是第一个然后第二个就是它可以已经部署了1000家里的一个工作负担来进行不同远区的业务的升级包括部署那最终呢还有一个效果就是它可以通过我们的流量呼应的功能去节约它云和边的这样一个流量带宽的省流模式省流的效果目前是可以达到80%的当然这个东西是一个平均值我们是根据每一个企业区内的节点的数量来做一个统计的你节点数量越多那你省流的效果会越好因为我们是只有一份的那么具体我们openout的是怎么样解决这些问题它的结构方案是什么样子就要给我大当和林某同学来继续进行的分享OK好的谢谢谢谢赵正OK 接下来我会针对赵正前面讲的这些背景以及这些挑战问题吧然后讲一下openout的一个具体的一些细节结束细节首先openout的是一个什么样的东西就是说当时定的那个slogan就是说它是想所以它首先其实还是就是说它没有去改Kubernetes就是说它是把Kubernetes应用在这种云边端协同的场景因为我们知道Kubernetes原生是说它其实初创还是面向一个数据中心里面来运行的那么在云边端这种协同的场景的话其实是刚才说的赵正也介绍了有面临很多很多挑战是吧有边自制的有网络的有工作负载管理的等等的一些挑战OK那我们这边的话是openout的要解决这些问题那它我们现在主要两个的这个design那个principles就是说我们的一个一个设计的一个设计的一个原则就是两个第一个是我们对Kubernetes我们没有没有做任何修改我们是一个build-inKubernetes就是说它还是就是说可以跟Kubernetes生态做一个非常非常好的一个那个一个集成第二个就是说它是比较抑郁级集成的就是说我们可以很好的集成别的系统比如说我们跟Edge Xfinery社区其实有很好的合作我们可以把很好的把IoT的这种解决方案给集成进来第二个它本身也可以比很好的比别的系统去集成比如说在一些IoT的场景一些西天的场景他们可能都集成OpenR的来做比如说我们这个案例的话是智慧园区里面他们就很好的把这个OpenR的集成进去了那个集成进去了然后我这个左边左下方这边列了一下keyfeature然后比如说很强大的这种边缘自制的能力有很好很标准化的这种跨地域网络通信的能力也就有多地域的这个工作负载管理能力以及也有这种匀原生的这种匀原生的这种边缘设备管理能力这块主要是跟Edge Xfinery社区做了一个很好的合作然后Edge Xfinery社区这边目前只要有新版本发布的话我们可能就社区这边它有一道自动化的一道工具然后可能就是10分钟左右的话就可以把Edge Xfinery这个社区的新版本集成过来所以然后这边也是Opian社区LTC他们同学做了一些工作所以跟这种成熟的LT解决方案也是有非常好的一个合作好 接下来我们看一下Opian的架构架构的还是云边端一体化或者是云边端协同的架构然后在这个图里面我们可以看到就是说在云上的话就是说我们新增的一个组建叫Yallimanger这个就是它是跟主要是集成了我们在这种云边端协同里面需要的一些Controller以及一些WebHook的组建然后在边缘的话或者说我们在边缘的话一个圆区一个圆区我们首先抽象了一个叫NordPort的一个概念就是一个节点分组它一个圆区那么有一批节点那么这个节点可以组成一个NordPort然后每个NordPort里面可能有很多个节点这些EdgeNord里面除了原生的CoopedProxy以及其他的一些EdgeOwn之后我们新增了两个组建一个叫YallHub一个叫ReverAgent这是节点上我们先新增这两个组建另外我们在NordPort就是一个圆区里面我们也新增了两个一个叫就是圆区维度我们新增的一个叫Yallocordinator一个叫YallotDockerYallocordinator主要是做一些协调就是它做一些KV存储以及分布式锁的能力主要提供这两块的能力然后YallotDocker主要是和IoT解决方案EdgeXFoundry这种解决方案去对接的就是把IoT的一些解决方案然后跟原生的这种这种解决方案给集成起来然后大概就是这样就是整个架构可能就是一个反正是非侵入的一个架构然后所有的OPNR组建也都是以这种EdO的形式以及一种这种旁路的形式然后介入到这个系统里面OK然后我们接下来会来讲各个KV Foundry首先我们首先讲一下那个边缘姿势的这个能力首先的话我们就是当这个其实云鹅边之间它是通过这种公网去一般是通过公网就是我们这种WiFi网络或者说4G5G网络去连的就是边缘可能是离生长现场比较近比如说我在一个园区内部对吧那么它中心机房可能是在在另外一个地方然后它们是通过公网去连接那公网连接的话其实很有可能会因为一些这可能未知的原因它这个网络出现断连比如说我这边的话我就有一个Ed之诺的我就我画了一个light off的一个就是它这个网络断开了那么网络断开的情况下比如说我们这个节点要是rebo的一下它重启的话那么在原生Coopnetis里面它其实这个节点重启之后它这个节点上的这些Port是没有办法恢复的对吧因为它这个Coopnet它重启之后Coopnet需要到API server这边去拉取这些Port的这些原数据但是因为你现在是网络断连的那你显然就拉不到拉不到的话那这个节点上这些Port的你就肯定就没有办法启动所以在在这种云边协动的场景上那么原生Coopnetis就是没有办法解决这种问题那么我们怎么来解这个问题呢就是我们肯定要在边缘节点上我们要存储要缓存这种Port的这种原数据对吧那我们怎么来缓存呢我不知道大家有没有什么想法比如说要你来设计这个问题你来怎么来解决比如说在边缘你怎么去把这些Port数换存下来比如说Coopnet要了这些Port数据或者Coopproxy它们自己的这些网络相关的资源那怎么去缓存呢那首先其实可能大家首先想到的是说我是不是可以改一下CoopnetCoopnet的改一下让Coopnet来把这个缓存的能力加上去对吧我让它把这个数据Port的数据缓存在本地那这样的话当然网络锻炼我重启的话那Coopnet可以把这些数据给把本地缓存的数据然后提取出来然后把这个Port起动起来对吧当然这是一个解决方案但是在Opnetis我们的想法还是不太一样就是我们因为是一个非进入的没有去改KBS的东西那我们做的呢是这个方案是这样的就是其实在我们程序员其实有一句非常非常著名的一句话就是说没有任何问题是解决不了的就是你要就是通过加一层的方式是没有任何问题解决不了就是说你当这个当这个系统的时候你发现要解决一个问题的时候你不太好在原有系统上你不太好解那我们就加一层那我们这边其实就是用了这个方式我们在边缘界里面我们加了一个组件压了HUB组件就是每个边缘界的上我们都有一个压了HUB组件它会接管所有的这种原生KBS的组件跟云的那种通信跟APS所有这种通信比如说CoupeletteCoupelette这些组件都是无感知的它所有访问APS所有的流量都会自动进过压了HUB同时压了HUB从APS所有反过来这种response这种反过来的这种 metadata管控数据它都会在本地cash这样的话当云边网络断开的情况那么它就可以利用这些组件联络压了HUB那么压了HUB可以利用本地缓存然后给每一个人返回所以它这个方案这个方案就是有一个好处就是说那我首先不用改KBSCoupelette的Coupelette这些组件都可以无缝继用而且是无感知的第二个是说比如说你原先你要去改Coupelette那你改了Coupelette那Coupelette怎么办你Coupelette也改吗或者以后你其他的组件你也要访问APS所有那这个扩展性就会成问题那么通过这种我们加一层的方式加一个组件的方式把这个就是我加了一个结定的一个sale card这样的方式那么这个问题就是扩性的问题对吧然后这个地方我们其实大家可能也知道就是边缘的这个就是说你断网的情况下边缘自己缓速能力解决之后那么在云端的话其实有一个就是说我们KBS里面有一个Node Life Cycle Control它会对这个Port做一些驱逐操作的对吧因为你这个节点这个网络断开这个心跳不上报那么即使在这个心跳这个断连心跳丢失之后其实云端40秒的时间它会把这个节点的这个状态制成那个Node Ready然后5分钟之后就开始做Port驱逐了那这个显然是在这种云边协同的场景是不符合不符合这个这个用过的期待的因为你边缘这个节点是OK的只是说因为这个网络可能有一些斗动或者有一些超时的那你就把这个Port驱逐了那肯定是有问题那这个问题怎么来解呢那OK那我们其实还是要继续用这种非惊讶的方式那我们的解决方案是这样的就是我们使用了一种心跳代理机制就是说我首先裤备着的这个心跳上报到压的Hub之后一个是继续会上报到Apple Server这边的心跳另外一个呢我们是节点指令里面因为有压的CodeNet这个组件压的CodeNet呢它会这个心跳也会上报一份给压的CodeNet就是这个心跳它会在压的Hub这边做一个复制一份是原封不动报给云端一份是报给自己NodePort里面这个压的CodeNet那同时呢我们每个节点上的压的Hub呢它可以基于压的CodeNet这个分布式锁的能力做一个选举的操作那么选举的这个节点它会成为LeaderLeader当然Leader它有一个条件就是它必须跟云端的网络是联通的那OK那当比如说某个节点比如说我们最左边假设最左边这个节点它网络端开的情况下那么它上报到云端那个心跳就上报不上去了但是它因为它是在同一个同一个圆区里面它是在同一个内网的环境它报个压的CodeNet其实是没有问题的那么它心跳那么另外一个第二中间这个节点它是Leader对吧它就会发现心跳那边左边这个节点心跳报不上去了但是它已经在压的CodeNet这边有一份那么Leader的压的HUB它就会替它就是我们中间这个红线它就替它把这个心跳上报给云端所以这样的话虽然是有一些节点你可能是因为网络有延迟或者有抖动或者有可能就是网络端连那你上报不了那么我们由其他的这种Leader的方式就是你同一个组里面同一个园区里面其他的健康节点帮你把这个心跳匪报给云端然后解决这种心跳丢失的问题然后从而就是让这种边缘可以业务保证一个持续稳定的一个运行OK 这个是OK 我们这个边缘自治大概其实边缘自治也非常复杂但是我们也没办法每一个系列就介绍就把一些重要的点可能介绍一下介绍来我们我们讲一下就是多地域的工作负载多地域的工作负载刚刚讲到就是我们有各个圆区有多个not a pool比如说我们这个图里面有两个比如说杭州 北京那其实我们每个圆区部署的应用其实都比较类似的比如说我都是要一个工厂或者说我一个圆区我不说的都是这种比如说监控类的或者什么样的业务部署上去那我们怎么把同一个这种同一个应用部署到不同的圆区呢首先大家想到原生Kubernetes里面的解法就是说你就创建每个圆区给它比如说我要是五状态的那你就创建Department有状态的你可能创建Set of Set那这样带来的比如说我们左边这个图比如说你都是同样的Department可能名字不一样然后not a selector可能不一样然后就给每一个比如说杭州这个圆区创了一个pool北京那个圆区也创了个poolOK 创出来了但这样的话带来一个问题就是这个复杂性等于你比如说一个集群里面你要有很多个圆区你管理的话那你就可能就要管理同一个应用Department的比如说假设我们举个例子比如说你一个圆区有20个应用对吧然后一共有比如说有10个圆区那么你其实你就一共要管理有20乘以10乘管理200个Department的那你可想而知那你这个管理的这个成本其实是很高的比如说你要做一些发布或者做一些升级那你去做的话其实是非常困难第二个就是说比如说假设这个应用还是还是通过service来访问它比如说这个应用是其实还使用了service的话你可能还需要为因为你要每个圆区就布一个Department那你可能还要为这个每个圆区的这个应用去布一个service对吧那这个就更麻烦了因为service大家就直接互相访问啊这个service可能这个名字已经固定了如果是你要是可能还要设计到一个青融式的就改代嘛才能让这个业务在这个圆区跑起来OK 那我们看一下这种这个问题这样有有这个问题那我们在欧比亚的里面是怎么解决的呢我们是这么解决的就是我们其实新建就是新我们新增了两个CRD一个叫Appset一个叫Appdemo其实看这个名字就能看能看出来就是Appset的话就是说我们是其实是管理多个接影池或者多个圆区的应用的那么这边我们左边这个图上就是我们可能只要你把这个WorkloadTemperate的弄好比如说我们现在支持Department也支持Department你把它Temperate里面填好另外Porse你一填你可以选比如说选好杭州北京那么就正常这个CRD你就写好了这个模板就写好了然后提交给集群就可以了集群里面它这个Appset的Control就会自动往每一个往杭州和北京的接近池里面去部署它要的Department那么这样我们看这个图上北京和杭州就是你写一份CRD你就可以在北京和杭州这两个接近池里面各自创建一个Port对吧OK那这个就解决了这个多地域的同一类型的这种工作负载的一个部署那这样带来又有另外一个问题就是说这边的话用的是继续同一个模板对吧那么等于每一个地方部署的这个应用都是同一个就是实力数是一样镜像是一样甚至其他的Coffee跟Map或者说其他的一些WalliumWallium Mount等等其他的东西全部都是一样的那比如说我们每个元气其实是有一些个性化配置的需求比如说我的实力数可能就需要不一样比如说我杭州这边两个节点其实是一个实力不够我可能需要两个实力那我们怎么去解决这种问题呢OK在Openya里面我们是其实这个灵感是来自于这个Kabs的RBAC这么一个想法RBAC的话就是说它是其余那个Classroom Bidding把这个用户跟它的这个全线Classroom这个东西做一个绑定那我们这边的话其实也是个这样的想法就是我多地域工作负载那么它是一个这种静态的一个Static的一个模板那它的配置呢是一个动态的可能是用户需要去修改的那我动态的那个信息我是不是也可以利用一个这种这种东西就可以把那个配置跟它这个模板去做一个绑定呢那这个就是我们我们这边做的就是说我们我们自己我们又定义了一个叫YataAppAllRider的一个资源然后这个里面去用户就可以写这种它到底跟stop jack的它是绑定在哪一个overload这个workload上面然后同时可以去写它自己的一些每一个接电池的就可以写它的配置那我们看一下这个这个YataAppAllRider的一个它的一个CRD定义我们可以从下面往上看就是最下是YataAppAllRider的一个结构就是说当然正常前面有TypeMatterObjectMatter这是正常的这个就是Object的一个定义然后接下来有SubjectSubject它其实是我们可以看到它其实是指定就是你到底跟哪一个workload就是哪一个YataAppSet就关联的然后第二个字段就是EntrisEntris当然这边可以是可以是Entris可以是多个是一个slice的一个结构那么Entris里面有PausePause就是你到底这个Entris你这个cofiguration是应用在哪几个接电池上面就是你这个接电池这边是你可以配置所有的可以配置部分这个是你按你的一个需求就配置比如说配置然后另外是Items的话然后接下来就是Items和PatchItems里面就是它是做一个一个基础的一个渲染对针对这些接领值里面做比如说我镜像或者Replicant数我可以做一个基础的一个渲染然后比如说你要做一些高级的配置比如说我要做一些比如说我Volume的修改比如说我在或者说我做一些cofig map其他的一些就是任意自当的修改吧那你就可以经过这个Patch来做Patch就是说比如说这边定义了可以去增加可以去移除可以去replace等等这些动作都可以然后你就正常去可以对这个对你这个指定的源区里面的做任何的修改它的这个实现是这样的就是说比如说我这边写了一个App reset然后同时呢我写了一个App overrider那个杭州的Replicant数我就写成二了然后这两个资源提交给API申为之后呢然后那边那个Deployment的外部户口就会做这个Deployment的拦截拦截之后它会根据这个App overrider里面的这个信息然后把这个Deployment这个Replicant数做一个调整然后这样的话Deployment我们就可以看到下面这个杭州这边就出来了两个破的然后北京还是一个所以它这个其实是一个把动态跟静态分开而且整个这个设计的话是一个这种非偶和的而且它是可以做任何自然的一个修改的一个东西这么一个能力所以它整个对这个多地域的一个配置管理是非常非常强的就是多地域工作负载的配置管理是一个可以提供一个非常非常强大的能力而且整个整个扩展性后续你要新增其他的一些Workload那么这个AppAll Rather也可以做很好的一个那个一个适配OK 这个是多地域工作负载配置配置渲染的这么一个能力然后我们接下来看一下OTA的就刚刚提到就是说我们在很多场景其实它很多这种源区里面的工作负载升级它其实不想去由中兴去控制中兴你可以做版本发布对吧但是你边缘界列山这个东西到底要不要这个破的边缘的这个这个源区的管理人员他自己来决定我不希望就是你云能可以发布新版本对吧但是我整个升级我是在边缘这一侧来执行的那么这其实有点像我们现在的这种新能源汽车里面做这种OTA一样就说你可能新能源厂商我可能发布了新版本对吧但是这个车要不要升级肯定不是发布了版本之后马上就升的而是说这个车主自己决定什么时候去做升级那这边我们其实在源区里面也是一样的能力Democent 为例Democent 首先的话它是就说你要加了一个Ontation就是OTA的一个这个up-date-strategy现在OTA当然它另外它原生的那个strategy是必须的on-delete然后这个比如说你首先第一步发布了一个新版本发布了一个新版本之后它就会把这个upgrade这个available的这个信息它会写到这个Port里面然后就这样边缘的话它就知道有一个Port其实是可以做一个升级的状态就是可以做升级然后在边缘这边比如说这个操作者他属于是在我们youtube里面提供了这种rest API他属于可以去query就是说我看看是不是可以升级啊比如说他get说目前可以升级那么就可以第三步去做up-dateup-date的话它的操作youtube这边它就发起了一个delete port的请求这个portdelete完之后那么云端的democent这种control的话它就会开始做这个新的port创建然后quart通过port的sync然后把port创建出来所以整个流程的话可能就是大概这样就是整个应用的发布是云端集军管理者去做但是应用的升级是由边缘资源的所有者去做所以它就整个发布或者说以及这个升级这个操作也是分开的然后提供那种边缘应用的一个OTA升级的能力OK然后这边的话我们刚刚就是多地域工作复杂的这个能力完了就工作复杂这边的一些需求然后接下来我们讲一下网络网络的话首先我们讲一下福托普的一个能力福托普刚刚其实讲的就是说比如说我这个应用这个port我部署在了杭州和那个就是比如说port B我不说了在杭州和北京那port A要去访问port B比如说它是通过service就访问我那个右边那边写了port A通过访问port B的service要是在原生cubanitis里面它这个肯定是它这个流量应该是均匀打到后端两个实力上对吧但是在我们这种智慧圆区的场景它其实是说我是需要这个A访问B的这个流量就是在自己同一个圆区上面而不需要跨圆区对吧那么我们这个在这用户的期待既然我们原生cubanitis没有办法满足那我们在OPR怎么就满足呢我们又不想改cubanitis那我们怎么做呢大家比如说考虑一下思考一下这个我们怎么去实现这个东西会比较优雅一点在电路上我们已经加了压了hub这个组件对吧这个比如说cube process是通过压了hub来访问API server的那当然我们可以在压了hub里面我们把这个我们加了一个在压了hub里面我们类似的一个叫datafaring framework它是一个可编成的一个数据过滤框架所有从云端返回的这种response我们都可以做修改做这种无感知的就是用户无感知然后非侵略的一种修改比如说这边的话比较只要你给service打了这种annotation浮脱補的这种annotation它们它就可以来触发这个当然这个请求这个annotation这个请求经过这个压了hub返回的时候它就会触发这个我们叫service-tablet的一个filter那么它就可以重组这个annotation这样的话cube process输到了这个annotation这些数据就是满足这个service上面这个浮脱補的这个配置所以这样的话就也是非常优雅的解决了这个就是说它的一个浮脱補的一个需求ok 接下来我们继续看网络问题就是说关于这个跨地域的一个跨地域的一个网络访问的一个能力然后我们在其实这个首先看这个架构图就说首先我们在云端的话可能这个节点它其实是有公网IP的有public IP的因为它是中心机房对吧它要提供它部署的这些master在里面比如APL software这些东西在上面所以它其实要有个公网IP那么在边缘在这个智慧各个智慧圆区里面它们其实各个节点都在那在后面就是它是在防火墙后面的它可能可以出公网去访问云端这个master但是云端这个流量肯定是流不进来的你肯定没有办法主动的访问边缘的因为你边缘在防火墙内部对吧那这个肯定是没有办法访问所以说我们原生的比如说这种CNR容器网络方案比如说你Fnano这种方案那你部署上去的话那你边缘内部就是一个圆区内部这些破了之间互相访问那是没有问题的其实Fnano是可以OK的但是比如说你要跨圆区去访问比如说我云和边之间访问或者边和边之间访问那肯定Fnano肯定就解决不了对吧同时比如说我我边和边之间要访问那其实这个这种其实有的时候也是会有这种需求的嘛那我们怎么去解决呢在我们属于圆区内部可以解决那么我们跨圆区怎么去解决这种访问而且我们又不想去又不想去改开白色的东西就意思说我们先按的东西还是可以在圆区内部发挥作用但是跨圆区的东西我希望有一种解决方案来解决这个问题那这边我们是有一个方案我们叫RevonRevon的一个方案这个Revon这个词其实是当时也是社区讨论出来的一个词叫它是从那个权力的游戏叫度压里面这个就是传递信息那就跨低于传递信息这么一个名字所以这个名字然后大家投票最后选择了这个名字然后这个Revon这个组件我们看到每个这个框里面除了Flanl之后我们也布了一个Revon Agenda的一个组件这个Revon Agenda的组件它是在每个节点上都有一个的那首先每一个节点词内部每一个Nordeport每个圆区内部有一个Revon Agenda它会被选择会被Cleg的成为这种Galewin节点这Galewin节点选择之后它就会跟其他的Galewin跟其他的圆区之间建立这个微偏隧道因为他们比如说我边缘就可以跟云端这个建立一个微偏隧道那这个隧道的话它其实是我们现在是支持IPsec和Wild guard两种协议的那么这个隧道建立了之后那么就跨远去之间这个网络就通了对吧OK然后我们在每个节点上这个比如说我不是Galewin节点上的这个Revon Agenda呢它就会在本地配置一些路由规则它配置路由规则我是可以根据这支PortCRTR来配置的比如说我发现Port的这个访问流量是需要跨远区的那么我这个流量我就拦解掉把这个流量转发给Galewin节点对吧要是这个流量是自己圆区内部的比如说我是Port这个圆区内部的Port访问的话它就不拦解那么就继续走的是CNi的那一套路由规则所以说它这个路由规则这个优先级比CNi那一套高一点它会先拦解这种跨远区访问的这种流量如果是那种流量它就会转发给Galewin节点有Galewin节点再转发到其他的Galewin那Galewin再转发到对应的Port所以我们可以看到比如说我边要访问云端或者云端要访问边那么我们就可以通过这个隧道以及这个节点配置的这些路由规则然后把这个流量转发到对应的节点上去甚至我们两个边缘两个边缘节点池之间我们要访问的话这个流量也可以经过云端做一个转发过去就是我两个圆区之间它们的这个流量也可以通过云端转发对OK但是其实这边可能大家想到比如说我两个圆区之间可不可以直接互相之间之间之间之间东西就是我不经过云端因为经过云端的话首先这个公网成本还是非常高的而且这个延迟也非常大但是这两个节点是我们看到它所有的节点都是在内的后面他们之间都没有公网IP那怎么去建立连接呢我们这边其实是把这个也实现了就是它利用了一个S2一个打动的一个能力就是说它首先建立比如说我这个比如说这个节点池首先跟云端建立连接之后它是会把它自己的一个S2的那个协议就是说它自己的它出公网的那个设备比如说那个路由器的一个比如说它的一个端口信息以及它的一个IP信息它会注册到集群里面去那么另外的边缘的那个节点池它就会感知到集群里面这些信息之后它会主动跟它打一个就是根据这种S2的协议跟它建立一个VPN隧道就是我们这个橙色的这个隧道建立了之后所有边缘之间互相通信的链路这个流量就不需要经过云端了它们之间可以互相通信这个就是我们我们正常那个就是大家正常今天因为SSH就打动的这个这个就是其实就是类似的所以它边缘之间虽然都是在内网在防瓦墙后面我们也可以经过这种VPN以及S2的能力然后把这个直接可以把这个隧道构建出来然后可以直接通信然后它这个通信的效率我们其实实测的效果是比通过云端转发大概能提升一个30%到50%的这么一个效率所以我们可以看到整个这个解决方案其实也是非常优雅的它每个接近池里面就是说它首先跟CNI是文静兼容的就是跟Flandr跟Catical这种原生的CNI容器网络方案是兼容的同时它又解决了这种跨云和边或者边缘之间这种网络通信的需求OK 这是Reven的这种多低的这种多低的这网络通信的一个标准的一个解决方案OK 接下来我们看一下这个网络带宽的一个问题就刚刚说到就是说比如说我们就是我们我们可以看这个团就是我们在云边云边这个这种场景上面首先我们云和边之间因为它走的公网其实很多时候这个带宽是有限制的因为这个公网代表什么也非常高有的时候在很多场景下它这个公网其实这个带宽也做不了太大就是它有一些网络设备的一些限制或者有一些这种立即的设备其实这个带宽其实是有限制的所以说但是在我们KBS这个系统里面比如说我们要是其实我们自己也经过了测试下面我有一个测试报告这个链接放到下面要有兴趣的东西可以看就是它这个测试我们这么测试的时候就是当用户要做一些应用的大规模发布的时候它会这个云端这个APS这边这个出口流量就突然有一个就是它这个流量会增长非常快就是很容易产生那个就是带宽带宽用塞的这么一个现象它这个原因是这样的就是说你当这个Port做生机发布的时候其实就是说有Port的创建和删除对吧Port创建删除其实最硬的这个Endpoint Slice就是有一个变化那么Endpoint Slice这个资源又需要推送到节点上每一个节点上的Coop Policy对吧那你这个权量的Endpoint Slice都要推给每一个Coop Policy可想而知这个数据量就非常大所以我这边中间画了一个特别粗的线就是这个带宽跟每个节点上的带宽它其实是有一个叠加的一个作用就是说它带宽就会形成一个这种暴增的一个效果因为每一个节点都要拿这些权量的数据OK 那我这个问题怎么来解决比如大家想你要解这个问题怎么解决比如说比如说它的这个生长现场它就是因为带宽这个问题我就没有办法上你这套系统那我而且它它就是这个带宽它就有限制那我们怎么来解我们又不想改KBS的吧我们不想改那我们怎么来解这个东西呢因为我们首先这边有一个背景就是大家知道就是Coop Policy每一个节点上的Coop Policy或者Coop Policy它拿到的Endpoint Slice都是整个集群所有的就是每个人对吧那既然是拿到一样的那我不可不可以就由一个人去拿不要每个人都去拿其他人去用它拿到就可以了那其实这边的话我们是有一个这样的叫流量附用的一套解决方案就是首先我们基于压力产生的一个分布式分布式所的一个选举能力那么压力亚伯是可以把这个Leader给选出来每个比如说节点池内部这个源区内部压力亚伯每个节点上压力亚伯可以把这个Leader选出来来Leader选出来之后压力亚伯他发起这个数据的一个请求就是中间这个蓝线他会就是你压力亚伯有变化的时候就有Leader去获取就好了Leader获取之后写到KV存储的这个压力亚伯就是这个压力亚伯就是提供KV存储提供分布式所的能力然后把这个数据写进去了那么这个Leader这个设计就做完了然后同时比如说每个节点上的他要去访问他这个请求因为我们知道他会经过压力亚伯那么压力亚伯他会把这个请求就是他会做一个这种转发他转发不是到云端他现在转发可以转发到压力亚伯就好了所以最后所有的人每个边界的KV存储访问到的压力亚伯其实是从压力亚伯里面拿到的所以这样的话我们可以看到他所有的通信就是整个一个节点比如说要访问这种权量的压力亚伯他其实只需要只需要一份只需要用那个Leader去拿取一份就好了而且这是一个实施的他随时可以随时可以实施去更新的然后其他的人也是可以直接就可以共享这一份数据通过这个压力亚伯这个协调的这个能力然后来分享这个数据然后这样达到一个流量附用的能力所以以前我们可能是比如说一个圆区那边可能有10-20分几十分那么我们这边就OK了所以这个通过这个流量附用的能力可以大大的降低云边通信的一个成本以及整个这个方案也是一个非常好的方案就是而且对这种网络设备也没有任何要求因为它是一个七层的一个能力OK好我然后网络的能力也完了然后最后就是我们的一个社区的一个情况首先欢迎大家来start我们的这个这个这个项目吧第二个是我们的一个slag的一个就是一个信息接下来下面是我们一个微信群然后有信息同时可以加一下然后订信群的话可能信息回得会快一点然后现在是一号群已经有一千人然后也满了然后二号群大家可以加一下然后微信的话是可以加的但是微信因为可能有时候平时上班看得比较少然后大家可能但是也会有其他的社区的东西招致他们这边也都会继续继续来就是也会很快的回复的OK 我这边大概就是这样OK然后大家大家有没有什么问题像你刚刚提到的就是带宽是一个很受限制的问题像婆婆米修师现在的一个格式她可能会有很多无用的数据就是数据笼语比较高对于带宽的利用以及说日治像我们用分闭的试试打过去的话这些问题像我一样你们有没有去解决方案去减少监控方面的带宽对不过你说的这个问题跟我们现在目前这个解决方案我们这个解决方案其实是主要是给APS Server这间通信的带宽所以是跟你监控的那个数据还不是同一个当然那个你说的这个普隆米修师如果是你假设是部署在云端的话其实你这个带宽是没有办法审的如果你有这个有这个限制的话其实建议就是你每个园区就部一个普隆米修师它最后处理的一个汇聚的一个结果再上报到云端就好了不要再中心就部署可能这样会解决你的问题OK对吧刚刚看到就是在每个NotePro里面他们都是有一个内网去互通的你说有一个什么内网内网因为我看到有很多H&Node然后还有一个coordinator他们之间是好像就保证他们之间的网络是稳定的对 他因为他在一个园区内部了他可能都接到一台交换机后面的对吧还有就是因为我刚刚看到一个就只有一个coordinator在上面而且很多东西都依赖他会不会有一些单点故障的问题比如说哪一个比如说就是有就是coordinator录过coordinator挂了之后呢比如说最后一个吧对比如说这一coordinator它不影响它要挂了就挂了挂了没有一定的影响那其他的H&Node它不是要通过coordinator去跟一边因为它这个请求是这样的因为它这个请求经过压了hub如果压了hub发现coordinator挂了它这个请求就转发给云端就好了这个是一个它是自动挑选的过程正常我们这边我们这边有很多细节有很多策略就是我们它首先不要挂了它也是一个容器它所有的数据全部存在内存在它没有高可用的需求它不需要做高可用它就是它挂了的话它自动起来就好了自动起来的话因为利用本地这些缓存的数据又可以把它的数据全部可以恢复出来所以你跟云端但网也没有关系它整个内部它是完全一个自动协调的一个过程但是像其他的H&Node它怎么知道原来是立的已经不算是立的了就是coordinator已经挂了这些感觉这是就是它当我们这边有一些健康检查的一些机制来防止这块的问题谢谢你好我请问一下就是你前面介绍VPN的那一页我问一下你们有意介绍对我想你们就是说现在H&Node上面是所有的控制面和用户面访问云侧的都会走你的VPN吗还是说你们只建议比方说业务是走VPN控制还是比如说走另外的那个大网通道现在是就是监控数据和业务数据走这个然后控制面还是直接走走的一个公网然后亚拉哈布那边出去那亚拉哈布也可以走也可以走这个VPN也可以也没有问题这个就是看你的一个具体场景的一个需求比如说你要是对这个安全有非常非常高的需求就是也可以走这个VPN就所有的数据都可以走这个VPN也没有问题就是我们那边现在亚拉哈布那边是支持这种多链路的就是说你这个链路比如说一条链路换了之后可以走另外一条链路然后你可以链路可以优先级指定就是你当然那个能力没有在这里说来介绍亚拉哈布这边比如说他们有专线也有公网的就是你可以选择多条链路配置上去然后他会首先就给你走专线比如说专线发现有出问题的时候他会这个流量自动走公网那比如说你可以把这个VPN的这个链路指定上去那么也可以走VPN也没有问题好 谢谢那你的意思就是说现在你们已经实现了就是一个节点和云之间那个亚拉哈布吗对对还是那个Raven的VPN可以有多条云边之间是多条VPN通道吗比如说你有VPN通道也有公网的通道对就是这样的链路比如说一个VPN当然VPN本身这个链路也是在公网上面对就是你可以选择走VPN也可以选择直接走公网都可以的谢谢有支持的那我咱们另一个问题就是你之前提到K8就是那几个优先级比如说有了Raven的VPN以后你会优先级最高的就会选走VPN 是吧就是云边之间优先走VPN那现在就是云边之间像那种法位云色K8 API所有的那种就会默认优先级最高的都会走VPN如果要想不走你的VPN找那个大网是哪里可配吗没有首先这两个链路是可以选就是你当你选的哪个优先级高是自己选可配可选对 可配可选好 谢谢其他东西还有什么问题吗好 要没有那我们就谢谢大家了谢谢