好吧 我们要开始了 非常感谢各位的参与欢迎参加今天的SINCEF网络研讨会如何让你的Windows应用运行在Kubernetes平台我是今天的主持人VivianSINCEF云元生的大使同时我是京东的产品经理负责开源相关的工作今天的网络研讨会由我来主持让我这里欢迎今天的演讲者杨宇 Alex Yang 和张文默Lair Zhang他们分别都是来自于Marinthins的解决方案架构式在我们开始之前我要先介绍一些注意事项在网络研讨会期间一会折是无法参与交谈的但是屏幕底部有一个问答框你可以随时在框中提交问题在问答环节我们会尽可能地回答大家的问题外面之后会提供视频和相关材料现在让我欢迎今天的演讲者杨宇张文默开始今天的演讲大家好欢迎参加今天的外面我们今天演讲的主题是如果让你的Windows C1U运行在Kubernetes平台上我是主帐人Lair Zhang 郑义然后的话还有我的同事 Alex Yang杨宇那么杨宇会为大家讲解Demo的部分然后这个是我们今天的一个异程第一部分我们会讲出为什么我们需要Windows容器然后基于容器的使用场景来聊为什么我们要容器化然后最后如果你想用Windows的容器的话需要基于那些现实的考量然后如何能更高效的把容器应用到Windows上那么这是我们今天这三部分的一个异程如果讲完之后有时间的话后面是一个QA的一个时间OK我们来讲第一部分为什么我们要需要Windows容器很多人包括客户还有我们这个问题容器是Linux的一个东西比如Name SpaceC Group都是基于Linux的Colonel的一个技术那我们为什么要聊Windows呢那么很多人可能注意到了从Windows Server 2016开始微软就引入了这个容器的概念那么在Windows Server上实现了和Linux容器上相似的功能这样我们就能把传统的Dernet业务包括一些Windows的业务嵌移到容器里跑到Windows Server上这样也能使得这种Dernet的业务获得容器化的一个优势那么这几年我们在项目中各个机构的统计结构中都会发现在服务端仍然有大量的Windows应用左边那个图大家可以看到2017年IDC机构统计了有70%以上的应用程序通过各种各样的形式跑在Windows Server上不管是12、16还是08、03而且很长一段时间都是如此要拿18、19年的统计书也差不多的那么目前在我们的行业中实际上大部分的声音都在讨论就是微服务啊或者Node.js然后GoLang啊或者Python这些的话题那么实际上我们全球存在了大量的Windows应用他们可以用这种容器的优势来进行一个优化那么这个是从业务应用的角度来看那么从右面这个图从业人员的角度来看可以看到很多的开发者仍然在大量使用C上Stackle Flow做过一个最流行开发源的调查那么调查结构显示三分之一的开发者仍然在大量使用C上而C上的大部分都与Windows Server基于Windows Server以及Diarnet业务相关这个比重这些年有所下降但是可以看仍然有很多C上的应用那么谈到这个框架呢我们可以看到在Stackle Flow上的另一个调查中ASP.NET和Diarnet仍然是框架使用率上接近绑手的一个位置这说明Diarnet仍然是业界的优质选择所以所有的统计数据都能表明我们将Windows上的应用容器化非常地必要这可以让Windows上的应用享受到容器上的好处包括可依至性、可深缩性还有一些Kubernetes的一些优势那么从整个用力的角度来看我们也看到容器包括Kubernetes的很多价值那么大概分这五点那么第一点就是我们讲的Constituent Operation就是一致性操作一致性运萎一致性运营这一致性的问题那么之前我们构建包括预行应用都是大多数都相互独立也不兼容的尤其是Linux和Windows那么两个平台上构建这个应用是包括跑起来是完全不同一种方式那么我们把它都容器化之后Kubernetes包括容器给了我们一个标准方式来应用不论是Linux or Windows的都可以用一种方式容器化的方式来跑起来这样就大大地降低了整个运萎运营的复杂性而且对于一些比较相同性质定用我们可以设置应用比如说一组方向规则或者一组AirBike规则然后统一地把这个应用管起来而不是像之前的LinuxLinux设置Windows一个个来设置那么这种一致性可以在Kubernetes使得这个容器化带来非常大的好处那么另一点就是传统的刀耐业务我们刚刚提到这些应用非常需要进行容器化因为现在还有很多公司在维护这些传统的刀耐应用维护包括Build包括跑起来这些应用大多数都要写很多的构建脚本有大量的手工工作在里面所以我们把它容器化之后我们就把容器的这种先进的框架的优点引入到了刀耐填应用中可以通过容器进行自动化的部署自动化的构建获得更好的体验那么第三个就是节省成本我觉得这是这五个里面最大的一个优点尤其是在本地的应用上那么现在技术加购云化之后我们有大量的虚拟机大多数这些虚拟机的使用率非常低也就40%-30%左右那么使用的容器化之后我们可以把容器我看VM里的业务有一些VM的业务拿出来放在容器里然后通过容器来使得整体的使用率变高那么无论是管理角度还是基础设施角度那成本都有很大幅度的一个节省那么第四个是云迁移那么云迁移现在是很多公司的关注一个焦点那么这个大家可能比较熟悉的容器本身就是一种非常优雅的方式你把整个业务容器化之后那它可以轻松的从你的本地或者从私有云迁移到官员云上或者说从当然你可以从官员云把业务迁回来那这些都是非常自由的那这个是这个容器化的一个固有优点那么最后是DiWops的Practice那么过去几年我们从这个DiWops包括DiWops的应用获得了很大的收益因为它能持续开发 持续集成 持续部署一些都会自动化那么从这个DiWops角度来看那么容器化也使得所有应用有一个非常一致的Pipeline非常一致的管道这样就使得很多的传统应用能享受到这个DiWops的优点所以这个就是我们为什么要将Windows容器化并使用Kubernetes的5个点然后我们这些年实际方面另一个最大的动力就是因为Windows 2008因为大家可能从各种渠道都了解到了Windows 2008从2020年1月14日开始就EOL了那么意味着就是微软不会再给它任何安全补丁或者修补程序因为直至期限已经到了但是目前我们了解到当然有大量的Windows 2008的系统在运行上面有大量的业务而且很多是关键业务那么这些业务目前来说从安全运萎还是管理等等角度来讲都会是很大的问题尤其是1月14号之后发现了漏洞那么对上级业务来说都是致命的所以这两年针对08的话题有很多逃进热潮比如怎么把企业把业务从08迁移到1619上一直是这几年热门话题那么现在业界主流有这么几种选择第一个也是我们听到最主流的声音就是重过和升机应用就是我们将之前的Doughnut应用拆开然后改一部分代码然后移植到全新的Doughnut Core或者Doughnut Framework上然后把业务整体的签到Windows 2019这样整个工作就完成了那么按照路线图来看这个是一个挺好的方法但实际上可操作性不是很强因为我们如果公司就有一两个应用或者几个应用我觉得这种方法还可以但是如果有成百上千或者上万个应用那这种方式基本无法实现因为首先它需要重组每个应用都需要重组或者改一些很多代码那么就需要大量的人力来完成很多公司不能接受这一点就算是有这么多人力的公司也不见得会去做这件事情因为这件事情看起来没有任何收益尤其是从ROI上来讲它仅仅是把之前的EPP给重建了没有任何新的东西在里面而且如果选择这个路线如果下一次2019EOL了那么我们还要再来一遍那么所以这样就收好大量的成本所以这个的可倒性不强那么第二个也是微软提出的一个方案就是和微软签一个定制化的合同然后来微软来提供定制化的这种服务包括补定那首先这个合同一般情况下非常的贵基本上可以达到75%你买license的费用而且关键是这个方法只是一个权益之计因为说到底这个2008已经过时了总有一天你会把它抛弃总有一天你一定要做这个升级这个是必须要面对的一个现实所以说不仅贵而且后续还是会有问题那么第三个方法和第二方法比较相似那只不过是第三个相当于一些云厂商会为你提供这个服务一些云厂商会游戏供云厂商会说它会帮你打补定帮你来看安全那么实际的情况是一样的你第一个问题就供云商会比较贵因为之前的你的成本已经发生了然后你还要把它签到供云上那么第二个就是总有一天你还是会要升级所以我们就来到了最后的方法就是我们发现解决这个问题最好的办法就是容器化那么我们现在很多的业务都跑在VM或者跑在本地那我们可以把这应用从VM里拿出来用它现有的配置进行一些容器化那么这样就使得我们整个的刀耐应用与底层的操作系统就解有了因为它已经容器化了那么一旦容器跑起来之后之前的操作系统就没什么用了然后我们直接再把整个应用直接移植到Windows 12.0.19里面而且我们以前经过评估这些操作大多数不会涉及到代码的改变而只要更改一些配置文件配置文件链条包括一些web的配置就能够实现有一些需要改一下代码但是对比第一种方法来说这个量也会小非常多而且我们容器化之后就会用到Kubernetes那么Kubernetes就是我们不需要大量的开发就能享受到Kubernetes带来的很多好处而且放长远来看就算是2019它也EOL了那么我们只需要再用容器化的方式再需要改一下DockerFile然后重新把BaseImage改一下重新打包一下镜像那么整个过程就结束了所以对未来来说这个也是一个非常好的解决办法所以第四种容器化的方法不论从现在还是长远来看都是我们前108业务上面的一个最优点那之前我们讲了为什么要容器化的原因那么我们后面来讲一下如何来做容器化一些把Windows容器化需要考虑的一些事情然后第一步我们先来看一下操作系统首先我们要选择就是我们选择用哪个办法进行容器化来运行容器那么之前我们讲过从2016开始微软就引入了对容器的知识但是实际上包括2016 包括2019还有其他很多的Windows Server的系统的版本分支需要我们去选择那么这些分支主要分为两类一类上面叫LTSC就是长期支持版本那么长期支持版本就是我们大家都比较耳熟能详的Windows Server 2016 2019这些都是LTSC的版本两到三年一个新版本然后5加5年的支持一共10年其中5年mainstream的5年extended那么这个类型的版本完完全全的专注在稳定性和预色性上所以一般情况下微软不会放一些超级新的特性在LTSC上因为不想砸自己的招牌所以我们在上面一般跑也非常重要的业务那么从2016年开始的微软开放了另一个操作系统分支叫SAC 就是半年版本如果我们看到Windows Server后面跟着一个比如1903 1809 1709这样的版本号那这个就是SAC版本那么1903就是版本编号的一种方式19年是年份 零三是月份目前我们买License的时候或者买服务的时候只能买这两个其中一种而且买完之后也不能随意转换那么微软通常SAC版本是每六个月发布一次通常在春季和秋季那么1909刚刚发布几个月那么所有这半年开发出来的新功能都会放在上面因此对于很多新兴技术包括我们的容器和Kubernetes那么微软首先会将最新的功能包括最新的特性都放在SAC里面那么预讯一段时间OK之后那么会再放回到RTAC的分支中那么对于SAC不利的一个消息就是SAC版本通常只有18个月的支持那么对于很多公司来说这个时间可能比较短尤其是比较大的比如说国企的企业对操作性能神秘比较严格那么可能刚卖了一套2016然后又要搞一套SAC这个不是很现实这个是可以理解的但是一般情况下不论是微软官方还是我们的美国S都建议大家把容器和Kubernetes跑在SAC版本上因为对Kubernetes来说这是一个比较新的技术包括bugfix 包括一些feature它会第一时间推送到SAC上那么使用SAC的体验会比RTAC上好很多那么实在有困难的在RTAC上比如Windows 3019跑Kubernetes的容器也是完全没问题的OK这个就是一个操作系统层面的一个考量那么下一个方面我们做经向的一个Base image的选择也非常的重要那么大家都知道在容器的世界里基本上我们用的是一个层解构那么就Layers这种解构那么一切镜像都是有很多个Layers有很多个层级来构建的它不是一个单纯的大耳耳音质的文件那么每个镜像都包含很多层那在Layers里大家可能很习惯用Basebox或者基于iopin或者Scratch来做这个镜像或者干脆从Docker Hub里拉成千三万的Base image那么在Windows里我们所有的Base image都源于这三种Base image第一个是Nano Server这个是1909上能使用的最小的一个镜像整个镜像只有100多兆但是如果你换了其他版本比如说1803它的大小可能就会有一些差异那么Nano Server非常适合这种云烟声的或者比较轻量级的应用如果你想只想构建一个Downed Core或者Node.js应用并且在Windows上跑起来那么Nano Server一般是首选或者你有一些PowerShell的脚本合计或者某些自动化测试工具那么也可以用Nano Server来构建那这样可以做到整个工具非常的轻量非常的小那么如果你需要的不仅仅是Downed Core而是整个Downed Framework那么你就需要下一个Based Image就是我们的SolarCore Image它包含了完整的Downed Framework所以它的主要目标就是把之前的五年十年前开发的这种传统的应用来做这种容器镜像让他们来容器化的一个镜像那么如果你在用SolarCore的镜像构建的时候发现那么这个应用还需要某些特定的Windows组件那么我们就需要第三种就是这种完整的Windows形象它包含了绝大多数Windows的一些组件另外如果你用了大量的Windows 32 API那么用这个镜像的话也是最好的选择那么这三个镜像的选择原则如果你可以发现如果一个应用可以在Nano Server上运行那么它一定可以在SolarCore运行但是我们的建议是尽量使用最小的经常来完成容器化这样也可是整个容器化过程边的灵魂高效刚才讨论了很多速主机操作系统包括基本镜像的问题那么根本原因是在Linux里面我们只要有速主机和容器我们其实不太相当于Windows来说不是那么需要关注速主机和容器的操作系统本身因为我们有本身的我们有这种独立的Continual Runtime来做这个隔离那么这在Linux中其实没什么问题那么在Windows上我们其实必须要关心这两者的一个兼容性那么这个就是图中的这个就是一个图表这个是基于Windows微软官方的一个简化版本完整的版本可以在下面连接里找到那么我们知道Linux的容器采用的是一种进程方式的进行自愿隔离那么在Windows实际上有两种隔离方式那么第一种和Linux一样也是进程隔离那么在进程隔离中那么Windows的接容性要求是非常严格的要求速主机的操作系统与容器的操作系统版本必须一致我们可以看到横轴是House device version就是速主机的一个版本那么这个纵轴就是我们这个容器的OS的一个Version那么可以看到必须要保持版本一致才可以被支持那么如果一个这个容器的OS跑到2019那么速主机也要跑2019那么如果这个版本不一致那系统会阻止我们实际用是没办法跑起来的那么这是为什么呢因为过去几年的Windows Server我刚才说过分支版本的非常多不仅是版本非常多实际上整个的API包括内核一直发生变化所以确保容器内外部分一致就可以保证我们在这个容器的运行的时候不会因为内核API出现各种奇奇怪怪的问题但是我们有这种Windows出现了第二种选项叫这种HyperVay的隔离那么它的原理就是允许我们容器跑在一个非常轻的虚拟机里那么在这个虚拟机里跑的是Conditional OS需要的特定的内核版本所以说这个接容性比较友好只要素主机的系统版本高于或等于容器的操作性版本就可以实现那么目前这个版本功能在一个Alpha的阶段我们也在Ginomi股的开发中那么预计会在2020年也就是今年的晚些时候会推出这个功能那么HyperVay隔离可以使Windows的容器生态系统的灵活性大大增强那么如果有一个1903的素主机二的镜像是G2019的那么基于这种HyperVay的隔离就可以完美的在1903上把镜像跑起来OK这个就是一个兼容性的一个考量OK那接下来如果让这个Kubernetes集群兼容这个Windows Server那么这个头大家可能比较熟悉这个是比较基础的一个这个Kubernetes架构吧我们有三个Masters作为这个集群的大脑然后我们然后呢我们有这个下面两个Workers那么目前呢我们现在只支持Windows节点作为这个Worker的节点那么如果我们想让Windows做Masters那这个目前来说还实现不了而且呢这里面需要注意的一点就是我们如果用传统的方法来进行容器的调度比如说我我给一个IS的应用IS的应用容器要跑起来那么这个Masters会尝试在这个Linux和Windows容器时间调度也就是说它调度的时候有可能会把这个东西放在Linux的Worker里面那么一跑肯定会包错包错之后呢这个Masters就会重视一直重设到这个容器被分配到这个Windows的这个Worker上那才算成功那么显然这个东西是不是很智能的所以我们引用了一个功能叫这个Node Sector那么Node Sector实际上是一个这个自断里面有一个标签那么我们可以在这个POD这个配置念里面把这个标签加进去有一个可以看到标黄的地方这个βCoupons iOS给的写成Windows那么六面是三个速度机那同样的我们在这个三个速度机上面也可以标这个Labels那可以标成Linux和Windows包括这种Labels那么标完Labels之后呢我们在这个Masters在调度的时候就会精准的匹配这个Labels这样我们就免去了这种错误调度的这种烦恼可以直接的把我们的容器调度精准的调度在这个Windows的这个Worker上面ok这是一些需要这个这个注意的另外一些需要注意的点那么刚才我们聊了关于很多这个2019那么2019确实是实Cognitis的最低版本那么但是如果我们的业务一代2016的话那么也可以做一些容器化但是呢我们可以只只能做这种独立的容器化比如一台服务器独立的跑这种容器后来我们用采用其他的一种编排方式那么如果要使用这个Cognitis就必须要使用这个2019或者1809以上的这个ICC版本那第二个Node Stactor我们啊刚刚讲过这个这个非常重要那第三个就是特权容器那么Ledix呢总有一个特权容器的概念那么这些容器对着这个速辱机有着很高的权限能够对速辱机型一些操作对于有些这个代理的代理程序啊包括一些这个业务场景啊那么这种容器会很好的满足这些场景那么在Windows的世界中呢没有类似的一种类似的概念那么如果你想用这个容器来操作这个注册表那么速辱机会阻止它因为Windows的安全边界和这个界定的严格都更加严格啊和明显这个是和Ledix不一样的地方那么下面这个Ledix Masters我们刚刚提到过只能用Ledix Masters那么最后一个有资源消耗的问题那在Ledix中呢很多镜像很小很轻那么在Windows中刚才我们可以也看到了那么最小的镜像也是100兆包括它使用的CPU包括内存也都要多于这个Ledix的这个这个这个容器啊所以我们在规划的时候一定要不要用Ledix这种惯性的思维来给POD做资源限制一定要这个把这个资源给大一点ok 那让我们来简单回顾一下这个历史那么Windows最早对容器的支持还是2016年是2017年呢这个CNI的这个容器的开发开始展开那么Kubernetes可以联网那么这工作一直持续到19年3月的发布那3月的版本这个是非常稳定的那么后面有很多公司参与到这个社区里面来相对面啊Docker也就是现在面这次啊不断不断停下新功能那么1.15版本我们就用了这个gimsa那这个是非常重要的一点呢后面我们会聊到那么在1.16我们加入了这个CSI的一些支持那么1.17我们在做这个Rise username的研究那么后面的发布1.18 1.19那么会有更多的使用功能来添加起来那为什么要看这个历史呢那这个就是为大家展示一点就是Windows Server的k8s处于一个初始的阶段而且Kubernetes本身呢也在不断的计划所以以后每一个Windows Server的版本发布呢都会有很多特性新功能包括Fix发布包括对于这个到内业务也会支持越来越好所以这个也是我们为什么推荐这个SAC作为这个SRG版本的一个包括这个ConditionalS版本的一个原因ok 那么我们啊要真正的让这个容器就让这个传统业务容器化呢我们碰到了一个最大的问题我们现在目前的可能很多客户在问的就是这个身份认证的问题近十年大多数的Windows应用使用的身份认证都会涉及到这个IWA包括这个AD那么在这个容器中这个AD或者IW的概念就会有一些问题因为Windows容器本身不能加入这个ADU所以呢我们就要引入这个GMSA包括这个Domainjohn这个概念非常非常重要也就是我们这个Windows容器要加入AD所必须的那么我们每一个容器并不需要加入一个ADU了这样我们只要每个速度机通过这个Domainjohn加入这个ADU然后呢速度机通过这个GMSA来管理整个速度机对于容器这个AD人称的所有需求这样就完美的实现了容器跟这个AD的一个对接那么具体的流程是这样的可以看到左面我发了一个创建炮的性求那么我们要带一个credential spec这个是个json文件里面包含了一些需要加入ADU的一个信息OK 我带这个东西发给我们的worker之后我的worker就知道这个并不是一个普通的容器它是一个需要AD认证的泡的所以呢我们通过这个容器内部的一个另外一个组件叫continuous credential guard会跟这个ADU进行交互那么会让这个ADU来这个分发这个科博斯的tickets包括维护整个的这个AD这个认证信息然后这个获得这些信息之后呢我们的worker就会用这个这个这个把这个容器创建起来并且这个GMSA里把这个负物账号叫ServiceCon的创建好那么后面我们所有的认证呢就会在这个数据库里用这个GMSA的账号进行AD的这个认证这不是一个简单的认证方式那这样呢整个这个ADU的这个在容器的实现链条呢就就就完整了OK那这块就是一个我们这个身份认证的一个考量那么第二考量就是我们的这个日治方面那么日治呢我们那个我们正常的nix啊都会把这个日治输入到这个容器的日会输入到standout那么我们跑这个docker run啊或者docker logs啊都是这个拿standout里面的一个log可以很轻松的看到这些log那么windows这个机制就完全不太一样那么可以看到我们跑这个docker run只看到一个很简单的一句话是因为这个windows默认会把整个的这个log打到ew和这个一些自定义的一些文件中那么不是在standout中那么这个标准出现的不一致会给我们造成很多的困惑那么这里我们引入了一个叫log monitor的一个概念那么他的作用呢就是加了一个log monitor那么使得我们windows的这个容器发出来的日治也发到这个standout那么可以使得我们获得一种lay links的体验是两面的标准一致那么这样我们在跑docker logs啊或者cobacity logs啊也会获得相同的一个结果那么这样的话就避免了这个之前这个原因那么这个是我们log monitor tool的一些road map那么它也是一个开源的项目我们在github上能看到那么另外呢它也在不断的加一些support的进取包括这个支持一些环境灭量啊包括支持config map那么我们也有很多的这种docker第三方log的手机工具那么也也在加入这些的支持包括它的这个这个performance也越来越好啊所以这个是log monitor一个总体的一个状况呃ok啊那么讲完log方面呢这这个就是我们一个存储的一些考量那么我们在选择存储方面在kubernetes上的存储windows or linux上也不是特别的一样那么csi在linux的容器里几乎已经变成一个存储规范但在windows里呢我们现在目前还是在用flex volume这个plugin这种方式那么它主要支持一些smb啊scassi啊像图中像这个ppt里面这些存储那么当然我们目前也在引入这个csi或者加入各种external provisioners后面呢会逐渐的把csi引入到windows中但是现在如果我们选择上云的话我们必须要考虑啊如何来使用flex volume包括smb啊或者这个scassi啊这一套东西ok那么这个就是刚才就是我们讲的这个这三部分那么下面有我同事Alex 杨洋宇来为大家讲这个demo的演示部分大家好Hi Alex那我和你先停止共享屏幕我来共享一下Hello 大家好我是Mirantys 杨宇那今天我会给大家带来一个demo也是就是新增一个Cubinux的一个Cubinux walker节点然后我们再把我们相应的应用把它创建然后调度到那个节点运行同时再去讲解一下它的网络方面的一些注意事项那么现在大家可以看到的就是我现在有一个Cubinux的机群那有一个master节点然后有三个linux walker节点其中有两个是运行在Cubinux模式下的然后我们可以先看一下我们的master节点的一个版本那么我们master节点现在运行的是Docker的一个19.03.8的一个版本然后上面也运行了一些我们的一些基础的Cubinux的一些master的一些组件然后我们再可以看一下我们Windows的节点而为了方便的演示我Windows的节点我也事先装好了Docker然后也导入了一些镜像那我们可以看一下它的版本那现在我Windows运行的是一个2019的Windows Server然后在上面的话我们也是有相应的这种driver然后有相应的image就是我也提前导入了在这边我们可以看一下我们Cubinux的版本我们Cubinux的版本是1.17的版本那我们Cubinux机群也正常的运行者然后现在的话我们只有一个default Linux base然后有Cube Assistant上面运行的一些我们Cubinux的一些master service然后这个时候我们可以去演示增加一个Docker的所有我们的节点Windows的节点我们可以选择Windows然后选择工作节点然后我们可以复制一下这个命运那么在增加之前我们可以看到在网络上现在我们安装完成以后Docker会去有一个ETH0的网口然后他现在也建立了一个HyperVid Vswitch那就是一个NAT的然后我们在创建的过程中他会去再创建一个把我们的ETH0瞧接到我们的稍等一下他现在在瞧接网络的中段OK 现在还恢复了他又新建了一个网络接口VTH然后它是相当于是我们Municus的一个bridge但是在Windows里面它是一个HyperVid Bridge把我们的ETH0网卡瞧接到了我们的一个HyperVid Vswitch上面那么现在我们的IP是配置在这个网卡上面的那我们可以看一下现在正在现在运行了一个Agent来帮我们去做一些自动化的去做一些我们CubeNet相关的一些安装比如说像CubeNet像我们的一些网络的组件Cannibal的FelixCannibal的一个Controller等等那么我可以回到这个界面上可以看一下它的状态这可能就要花一些时间那我们在等它加入完之前我们可以演示一下那个在我们先可以创建一个Ninux的一个容器我们可以创建一个Lame SpaceLame Space很简单就是一个Lame SpaceTableLame Space好看创建Lame Space然后我们可以再创建一个Ninux的Web Server那这个Web Server主要就是有一个ServiceAnodePortService组成然后其中的话会有一个Replica的一个Depriment然后是两个然后这一块的话是一个就是我们的一个Affinity策略就防止我们的就比如说我们在做一些高可用的应用那么这个应用是无状态的那么如果说你要保证高可用你是需要这个这些应用能被调度到不同的节点上去所以说我们可以配置一个Anti Affinity的策略然后的话我们我们使用的是NinuxAirPan的迹象我们可以看一下我们的现在逻辑的情况那现在我们看现在我们在温度节点已经已经加进来了那么现在的话我们是有三个Ninux节点其中这个是运行在另外一个SWARM继续的模式下另外这两个是运行在Quebenet继续模式下那按这个情况的话就是我们的这个调度策略的话它应该会被调度到02和03上Ninux的容器我们可以创建一下OK那现在它这个很快已经运行起来了那我们可以加一个GunAll Wide我们可以看到这两个Port就是我们有一个Department然后它是一个Replica Set两份然后对应的这两个Port那它都被调度到了02、03上然后我们现在可以去访问一下我们也可以访问它Port的IPOK这个就是已经可以正常提供服务了那值得注意的是其实就说我们在这个选择选择的这个过程中就是说它为什么会选择在这个节点上去Ninux节点去创建了就是说我们会增加了一个Node Selector让它再指定了一个就是它的OS是Ninux那么我们也可以去看一下这个节点它的一个具体的情况那我们也可以看到在这个节点上其实它的Level上面也有这个比如它的BetaQuebenet iOS是Ninux然后Quebenet iOSOS等于Ninux所以说它这样它就会去选择到这个它的Port就会调入到这个节点那么同样的我们可以看一下我们现在的那个Windows的一个容器Windows的这个节点那在这个节点上它也会有相应的去Label就比如说它的一个OS是Windows这样的话我们再创建Windows的那个Ninux的时候其实它就可以调入到Windows的节点那我们先看一下我们的节点现在我们的Windows继续已经正常了已经加入进来的那我们再看一下在上面的一些跑车的容器在上面现在我们跑车的一些我们这边是管理的Agent同时呢就重要的就是说如果说你自己在部署Quebenet的时候那其实你会部署像Quebenet然后还有我们的Tegra这个是我们Cannibal的一个一个出现然后还有Quebupoxy以及我们一个那个Cannibal的一个FatFelix的一个数据平面出现那么这些其实现在还没有还没有我们的Port运行在上面那么我现在可以去创建一个我可以看一下我们的Windows Server的一个文件那么这个其实和原来的那个Ninux差不多就是一个Noteport Service同时呢那么使用的是一个我们刚刚看到的一个Core Server经向这个经向大概有四个G左右那么在上面我们会起一个Web Server然后Web Server的话就是会显示的一个IP和它的Count访问的次数然后在这一块最重要的就是说也会加一个Notes Select然后选择说Windows接点因为这个经向比较大所以说它会慢一点我们可以看一下现在这个服务的话也是RunningPort也Running说明它创建起来了那么我们可以回到这个这个我们的Windows里面可以看一下那我们现在可以看到一个Windows的Port和它的一个Content有运行起来了他就说我们适合去访问一下这个服务他第一次访问会慢一点那现在也能正常访问了那我们也可以去直接访问它的一个Port IPPort IP是这个OK 那也是正常的那我们也可以就说像传统的应用一样就说传统的Cuban S Port一样我们也可以通过Cuban DSGC我们可以登录到那个节点上去看一下它的一个情况那我们选择Port然后这边的话我们就不是用Share是用Windows的PowerShell那现在我们就将于是attached到一个Windows的PowerShell那它的话我们可以看一下它的IP正好就是我们刚才用看到的那个Windows的Port IP让我们也登到这个Windows的这个机器类的Port里面那么在这里面的话其实你也可以就说和我们的NinuxPort去通信NinuxPort的一个IP我们NinuxPort的一个IP比如说是110这个现在通信都是互通的那么其实这一块的话我想在着重介绍一下就是说有一个顾虑点就是说其实刚才那个哪里张提到了在我们做Windows的那些我们说要把我们的Windows应用迁移到容器环境那么其实在镜像考虑以及Hypervisor的OS版本的考虑以及镜像和Hypervisor还有OS兼容性还要穿住这块的考虑的前提下呢我们还要去考虑网络这一块那么现在Windows这一块输出的一些网络方式主要是像Flight Flannel还有我们的Kentical那么Kentical其实我们也支持两种模式Kentical支持IP in IP的就是我们穿的我们可以很简单地解就是BGP的一个IP的一个路由的一个SDN的方式另外一个就是一个VXLAN的方式VXLAN的方式那么现在由于Windows这一边并不支持IP in IP的这种方式所以说如果您是需要去搭建一个Windows的Walkano的然后你需要和另一个世界面去通信而且使用同一个Kentical的控制器的话包括同一个Kentical的机群那你能选择的Kentical下面就能是VXLAN的一个方式来作为通信那么我们也可以在登录到一些Low的界限上我们可以看到一些我们的一些路由比如说一些到刚才我们到Windows的界限路由我们可以看到它最后是通过一个VXLAN的隧道去转发的OK那今天我的这个demo就到这结束了谢谢大家那Larry请你跟共享一下并幕咱们所有的演讲和demo都结束了是吧Larry最后有一个summaryOKOK 最后来做一个简短的总结OK 那我们总结今天讲的大概就有这三点第一个就是我们需要把传统的传统的这个Doughnet的业务容器化来获得灵活的扩展并且可以缩点成本那么第二个就是我们建议客户从一个小的机群开始然后呢当我们的这个机群当我们通过这个小的机群对Windows的容器有了更好的理解包括更好理解它跟Linux的差异用的比较熟的之后然后再把大量业务切上去这是一个比较好的方法那么第三个就是我们在这个容器化的或者这个容器化的时候必须要考虑这个提草规划比如说这个容器比如说这个生命验证怎么弄包括AD啊包括存储怎么弄也包括刚才这个网络我们想想要怎么弄OK 然后这有一些资源这个包括SakeWindows的包括这个KubernetesWindowsDevelopmentCampus还有一些微软的光红温档还有一些KPRS的光红温档这些都是链接这个大家不用抄然后我们后面这个slides会分享出来直接复制就可以了然后呢我们实际上也有一个白皮书然后的话可以给大家这个这个大家可以去去大概看一下这个十一八年九月份也算是比较新的一个白皮书OK 那到这儿今天所有的这个演讲都就结束了嗯好的喂 太棒了非常感谢今天的演讲嘉宾杨宇和文默的精彩演讲下面我们将进入问答环节如果你有任何问题请在那个屏幕底部的答庞中心提交我们在时间允许的范围之内可能帮大家回答更多的问题下面我们可以看到微大框中期中有五个问题看看我们的演讲嘉宾是不是要回答一下不过我们所剩的时间也是不是很多了要不然我们选择几个问题回答一下那行 我选择几个问题回答一下吧那第一个问题呢是多个点点爱它版本的在一个Windows的操作系统上目前是支持的吗那这个的话目前的话点亮它就在同一个Windows上面如果说有多少点亮的版本它是需要有一个有MultiTarget的功能来支持的但是对于容器环境的话我们这边的一个建议就是说如果说你是一个容器环境那么就因为容器带来的好处就是一个环境的一致性从你的开发环境到你的部署环境那其实尽量保持在同样的一个点亮的版本然后如果说你有不同点亮的版本的那个应用那其实你可以分开部署在不同的容器里面去解决这个问题然后第二个问题是一个张小老师他说的一个S8进向S8进向频繁更新那么应用使用的基础性向怎么与织同步更新比较具有可行性呢这个的话我们可以首先强调的就是说我刚才提到S8进向主要是一个hypervisor的进向就是一个我们的我们的处组机的一个操作系统版本那么对于容器里面的一个版本的话其实就是说它是我们可以使用core as 或是用nano server那么对于容器里面这个操作系统如果说它要更新的话那其实就是说和我们传统的开发一个应用一样其实就是说实际上你依赖的更新是你需要去有一个完善的CSD邮程去对你的这个更新进行重新的这种测试然后做一些bug的修复做验证最后你才能去确保你应用没有问题然后再发不到你的生产环境那么对于对于操作系统的更新其实也是一样的我们也需要一个环境去做一些更新的验证最后才能在生产环境去做应用然后同时那个还有张晓也提出了就是说现在特学现在我们的这个最新的1.18版本里面其实我们可以不用使用loader select使用round time class来解决其实这是一个很好的一个方式就说因为现在如果说我们在现在刚刚实际上这是1.17版本如果说使用loader select其实会有一些问题那主要就是有些我们现在有些HELM的包卡其实里面并没有说能指定我们的loaderselect一个选项那其实就会有问题就是说你是没法去使用像客户的话他是没法去指定loaderselect来选择我要运行的机器那么另外一个设计就是用round time class在1.18版本里面那其实就通过管理员来指定什么样的进向需要装在什么样的我们的HELM weather节点上面去然后最后一个问题吧那就是刚刚的演示也有Swarm和QBNS的激情混合部署对这个是Murentis搜购的Doc Enterprise的一个特性因为原来Doc Enterprise它的一个主要的激情方式是Doc Swarm但是这QBNS是这个社区的包括整个技术包括它的生态的一个发展其实后面Doc Enterprise也支持了KBNS那为了兼顾兼顾Swarm的客户以及未来QBNS的客户那其实在Doc Enterprise里面它是支持Swarm和KBNS激情混合部署然后同意管理的然后最后的话一个观众也提到了能否介绍一下WaterLet其实WaterLet这个其实也是Murentis在开源的一个组件那WaterLet它的作用是什么呢其实就是说我们在原来传统的这种虚拟机的业务里面其实有很多OpenStack业务了那其实我们现在也有部分OpenStack客户要向容序化像KBNS平台迁移那么但有些应用它是没办法一下子就说很快的就从一个单级的应用改造成我们这种cognitive的应用那么其实Murentis就开发了WaterLet这个功能就是一个我们的叫做应该是叫CRI的组件就是一个container runtime interface那它能和KBNS的虽然就是把一个虚拟机KBNS虚拟机作为一个KBNS port来管理那这样的话就可以让我们使用统一的KBNS平台既管理我们的虚拟机的复杂也可以管理我们容器的复杂当这个项目现在是开源的如果说感兴趣我们后续可以有专题的这种针对WaterLet的一个介绍好 谢谢大家我们今天就只能回答这些问题了由于时间有限非常感谢各位的激进参与网络研讨会的录像和幻动片将会于今天晚点的时候上线期待在未来的生产和网络研讨会中再次与您见面让大家每次都能满载而归Hi KristyWe are good to stop the recording