上海网站建设设计,上海市中心,网站建设的目的意义,惠州做棋牌网站建设9 月 7 日下午#xff0c;在深圳南山软件产业基地#xff0c;腾讯云 K8S 云原生技术开放日成功落幕#xff0c;来自腾讯、灵雀云、超参数科技、虎牙等资深技术专家与现场开发者共同探讨企业落地 K8S 的过程中遇到的难点以及解决问题的方法。K8S 逐渐成为容器编排的标准… 9 月 7 日下午在深圳南山软件产业基地腾讯云 K8S 云原生技术开放日成功落幕来自腾讯、灵雀云、超参数科技、虎牙等资深技术专家与现场开发者共同探讨企业落地 K8S 的过程中遇到的难点以及解决问题的方法。K8S 逐渐成为容器编排的标准越来越多的实现方式和使用方式已经成为了标准化的流程但是在应用容器化、DevOps、监控、性能调优、发布方式等方面仍存在一些技术难点。在学习和实施容器交付的时候我们对于 K8S 的认知和理解多少会存在一些偏差在一些项目落地实施时开发者经常会对 K8S 本身没有包含的问题或者是没有解决的问题而感到束手无策。腾讯云 K8S 云原生技术开放日邀请多位技术专家就和大家聊聊在 K8S 中存在哪些问题以及如何解决这些问题。以下内容摘选自部分演讲速记完整速记、音频和 PPT 请扫描文末二维码获取。灵雀云微服务架构师 贺洪龙为什么要上云原生这是灵雀云微服务架构师贺洪龙老师在演讲开始时问大家的问题。其实传统的架构转向 DevOps 的架构有点像以前 C/S 架构转向 B/S 架构这是一个必然的趋势。不只是互联网公司适合用云原生其实传统企业一样适用像中石油、海关总署、一些央企或者是大型的部委他们现在也非常关心整个核心系统的更新换代这个需求并不是来源于业务或者技术的角度部分是出于管理的角度。实现云原生要做到两点一是能够统一企业所有内部的应用架构包括中间件都可以统一二是要做旧系统的迁移。比如一个部委的核心系统可能是 10 年前开发的而如果开发一个新的核心系统要上线的话开发周期有可能要两年。那么迁移的时候原系统下有几百个子系统如果还是采用单体结构实现难度非常大。而且现在政府的系统其实对于互联网的需求很多以前一套系统可以跑 10 年不用更新现在的系统分分钟要修改、要迭代。因此对云原生架构的需求就变得非常强烈。DevOps 的价值体现在哪里一是可以快速投放市场。有多快每天迭代 N 个版本贺洪龙提到「我记得是 2016 年某银行信用卡中心一周时间迭代了 183 次每天差不多有几十次的小版本迭代用蓝绿版本迭代这样频繁的发布也只有通过 DevOps 才能实现。因为这个银行信用卡中心的运维服务器开发得很早从 2014 年就开始做了最开始是跑虚拟机。据我所知做发布的兄弟们三个月走一批人经常需要通宵他们都受不了相反用容器来做基本上可以不用加班用两套环境一套蓝、一套绿下午做好部署晚上一切网络就可以了。」二是降低成本。有 DevOps 工具之后可以减少人工投入进而减少因停机时间带来的损失。以手机制造厂商为例他们的应用要发布中间如果要停机停一个小时损失 300 万。如果发布要 4 个小时那就是 1200 万。而手机制造厂商的 IT 部门一年的投入也就一个亿。所以通过 DevOps 基本上可以把 IT 的投入赚回来这就是 DevOps 的价值体现。三是 DevOps 可以让开发者不用做一些低价值的事情包括安装、部署、配置都可以用工具来做。DevOps 可以让运维人员做一些更高端的事情类似于运维架构师的角色。DevOps 平台可以满足整个生命周期管理的需求从最早的项目管理、需求再到构建、代码到最后运维。腾讯高级工程师 卢承山腾讯高级工程师卢承山从实践的角度重点介绍了云智中枢 AI 中台的建设思路该平台要打通设备、数据、上层的应用让应用开发者基于该平台通过服务编排减少用户的开发量。云智中枢 AI 平台是从 0 到 1 构建是思路是(1)技术选型比如用什么微服务框架用什么容器平台。(2)算法算法可能有上百种如何接入并且发布成一个应用。(3)AI 产品怎么落地。还有一个持续交付的问题。很明确的是用容器、微服务已经是一个趋势了。在架构选型方面腾讯云容器服务 TKE 基于其强大的 K8S 的原生能力同时对整个交付集成有一套完整的体系。腾讯云最新推出的企业级容器云平台 TKE(Tencent Kubernetes Engine )基于成熟的 Kubernetes 技术和生态能够帮助企业快速构建自身的私有化容器管理平台。TKE 企业版在架构设计过程中作了针对性优化通过采用与腾讯公有云容器服务一致的架构和管理模式可以帮助企业在私有化管理容器服务的同时便捷地打通云上的容器服务并获得一致的管理体验实现混合云部署。另外TKE 企业版还充分利用了腾讯内部微信、QQ、游戏等重量级业务在容器使用方面的经验例如 GPU 虚拟化用于解决 GPU 共享问题 ;TAPP 应用管理用于让服务管理更加精细化、发布过程更加可控 ; 在离线混部技术提升资源利用率降低成本等。腾讯自己开发的服务包括算法服务都能接到 K8S 里面去其实这个已经比较成熟了但是有些组件包括一些存储性的东西分布式文件存储或者 MySQL 存储等等业界也有相关的方案但是从整个的稳定性来说存储目前还是用的物理机的方式除了服务以外的存储还是用的物理机。那怎么接入算法最原始的方式可能是让它提供二进制包或者类似的方式来帮它做。我们最终提供的就是镜像制作的方式最终都是通过镜像。如果用户提供了一个二进制包怎么帮他们做镜像这里其实有两种对接方式第一种直接对接其镜像。这是最简单的也有容器平台。第二种是自动构建镜像。比如说它还是物理机或者是虚拟机的方式它提供的可能是一些包我们帮它自动做镜像。我们把每个环境抽象成一个组件比如说你需要 JDK、OpenSL 等等环境我们把它抽象成一些组件你只需要把包选出来在你的页面上这里就是一个可视化的操作你可以在我们的平台构成完做成你的镜像把你的二进制包上传。这里有个难点怎么缩短镜像制作的耗时一个原始的 GCC 编译可能需要一个小时CUDA 的安装也需要 20 分钟做一个镜像如果环境变复杂是不是需要一两个小时才能做一个镜像。那怎么缩短时间思路是第一次制作有可能确实需要花这么长时间。另外腾讯也抽象了几点把 GCC、CUDA 和镜像的版本做了绑定因为是常用的所以会做成基础镜像每个用户制作的内容都会在后台分析用户最耗时的以及最频繁使用的可以在后台帮你分析做成一个模板镜像下次做的时候不会基于 Linux 来做它可以基于镜像模板机来做它的耗时明显就会减少。卢承山也介绍了 GPU 虚拟化的难点并具体解释了腾讯和英伟达在 GPU 虚拟化上的不同。怎么在容器内使用 CUDA容器可以做到 CPU 内存和 CPU 核的隔离包括细分到 0.01。GPU 的最底层是 GPU 的设备上面是 GPU 运行的环境。腾讯是做法是一、最底层的两层是在物理机层面的需要把它挂到容器上最上层的 CUDA 是在镜像层面做的。二、解决在使用容器过程中 License 的问题。算法服务和普通服务不同的地方在于算法厂商不希望这个服务你拿去就用它有一些鉴权不可能把服务给你。最早都是物理机过来的它依赖物理机设备上的东西。怎么把这些东西挂到容器内它依赖 MAC 地址而容器的 MAC 地址是虚拟的。腾讯在这里面做了一部分改造把物理机挂到容器然后再做 License 的鉴权。GPU 虚拟化也涉及一些选型问题英伟达 GPU 虚拟化存在一些问题第一是物理层面英伟达是在 CUDA 的驱动层面来做的虽然性能很好但由于是在虚拟机层面做的因而不适合容器。第二是它不开源而且收费。既然不开源出现各种问题你就很难去查。另外英伟达基于 MPS 做了一个软件的 GPU 虚拟化要求必须平均分配这会造成资源的浪费。比如它是把一张卡虚拟成 0.01 之类的。使用一张卡其实很浪费以一张 P40 的卡为例很有可能你的算法根本用不到。基于这个痛点腾讯做了一个选型也是在 CUDA 层面上做了一层所有的调用都是转到这个后面再去调 CUDA 的底层但是我们这个不会对 CUDA 底层的东西做任何改动只是中间加了一层。超参数科技高级研发工程师 朱恒满超参数科技高级研发工程师朱恒满从 AI 与游戏的角度讲解了游戏 AI 在实践中遇到的难点以及解决问题的思路。游戏 AI 近些年来在学术界已经有了很多的探索在最近几年出现了比较显著的成果。2013 年 deepmind 在 Atari 的游戏上超过了人类但是在当时并没有引起很大的轰动在 2016 年 AlphaGo 击败了国际顶尖的围棋选手使得 AI 有了很大的进展。最近deepmind 和 OpenAI 分别在 rts 和 moba 游戏里面战胜了职业选手资源不断升级规模也是越来越大。游戏 AI 的实验流程首先在本地是一些算法的设计、迭代包括一开始去体验游戏感受游戏需要怎样的特征设计怎么样的流程更好然后是模型的参数调整做一些小范围的参数设置接下来就是做一些大规模的实验。强化学习主要是 CPU 和 GPU 混合的异构的计算规模会比较庞大。那么现在 AI 真实对战的能力指标是不是已经达到我们的预期了如果达到预期实验就可能会停止如果达不到就会再回溯到之前的各个模块看看在特征方面有没有什么需要改变最后就是保存模型。那为什么要做一个平台化首先是因为计算模式的复杂性。目前强化学习在 K8S 上的编排模块比较多包括 GPU、CPU 生产数据等方面还有中间做了一些缓存。这么复杂的模式如果没有做平台化需要写很多的脚本对于个人而言很难掌握大规模、复杂的系统。另外比较重要的一点是计算模式需要能够被复用。整个迭代流程更多的可能是修改参数或者是一些模型、特征其实整体的框架是不会动的这就需要提供一些可复用的计算模式进而可以提供对算法模型来说更加直接的分布式能力。其次是资源需要被更高效地管理和利用这也是 K8S 赋予的能力。如果是个人或者团队分配机器利用率是很低的包括自己的业务可能需要去协商可以用哪些机器这个流程非常拖沓。同时也存在资源竞争的问题比如两个人都想用 GPU一台虚拟化的机器只有一张卡怎么分配还有就是个人很难管理这么大量的机器。最后平台的通用化分析能力可以开放给算法同学包括算法的监控硬件和业务的监控。另外在日志处理方面通过日志去判断一个 AI 是不是已经达到了能力上的需求这里会有一些指标包括模型方面的要求还可以做日常定位的工作在数据管理方面训练数据和模型都需要做管理。虎牙直播高级开发工程师 王玉君因为虎牙直播业务方面的特性它有很多业务是部署在边缘节点因为涉及到主播推流等对网络质量要求比较高也在尝试边缘机房的建设。目前虎牙有一些测试的机房预计会在今年 Q4 完成生产环境的建设。这是目前的现状虎牙现在 Node 机房有 700 物理机Pod 有 7000 多应用程序在 350这些数据还在不断增加。有时候有一些赛事需要紧急扩容一天就会扩容 100 台虎牙会根据实际的业务情况来增减。虎牙直播高级开发工程师王玉君分析了虎牙直播应用 K8S 的背景以及目前实践的一些思考。虎牙现在有一些 K8S 集群是搭建在公有云平台上的目前用到了腾讯云、阿里云、AWS。对比这三家腾讯云 TKE 可以大幅节约成本。比如说一台虚拟机上跑 10 个容器和跑 30 个容器是有本质差别的。虎牙当时也实践了不同的平台在腾讯云 TKE 上一台虚拟机可以跑到将近 40 个容器它还可以提供更多的密度。通常情况下K8S 如果直接提供给业务方API 等方面用起来不是很方便包括一些 CI/CD 的流程如果没有把业务打通用户是不愿意迁移上来的因为要考虑自己的应用性成本包括后期的部署一些变更的成本等。虎牙一站式服务可以实现从代码编译到部署所有的环节都帮助用户在页面上实现用户只要在页面上点一下就可以在很短的时间内把新版本发布。之前有用户不愿意上云担心业务被其他人影响。虎牙使用了 TC 限速策略做了一些容器的限速有稍微的改动。如下图所示左边底下这些三角形是容器出向限速在左边右边是入向限速底下蓝色的方框是 TC 的模块。如果这个网卡是 1000M左边这个图有两个方块虎牙做了一些优化。因为机房用 BGP 的模式要保证它有一个独享的带宽不能被其它所干扰否则对路由有影响。右边这部分就通过 filter 分给不同的容器然后有一些不同的策略。右边这一块只是限出不限入也是用开源的方案通过一个网卡转发网卡数据包进来再出去通过限制网卡的出速相当于限制了容器进来的速度。那么边缘节点如何接入如下图所示左下是数据中心master 跑在数据中心里面边缘节点分布在各个地方它如何接入数据中心呢图中右边这部分是通过公网直接接入集群这种方式有很多风险比较严重依赖虎牙自研的防火墙设备。比如说 K8S 的业务运维或者是系统运维在扩容边缘节点的时候它会先跟安全部门进行申请开白名单然后接入才能成功跨部门的沟通是非常影响效率的。左边这一块是通过 IPsec VPN 的方式直接接入边缘节点这种方式是比较依赖一个边缘网关、EdgeHub。另外它使用 VPN在同样的链路下它会有一些性能上的损耗。基于这一点虎牙结合 K8S 的特性做了一些边缘节点更新的方案(1)用户可以直接通过公网接入。(2)系统管理员不需要找安全部门开白名单。通过 kubectl 或者 Restful API 向 master API 发起一个授权进而推送一个资源安全资源有变更时会把配置后的信息发送到一个源数据服务源数据服务会实时更新该插件上的防火墙配置业务的节点就会比较快速地接入集群。这样做的好处是边缘节点分布在各个地方edge mate 可以进行统一的管理它会把边缘配置下发到各个节点然后对自身进行配置提供一种边缘集群的对外访问能力。另外原地升级是对 K8S 比较好的一个补充。如果要进行升级按照 K8S 现在的方式会把 pod 销毁重建这样业务是不答应的所以原地升级可以 pod 不变业务容器也不动只是把 Sidecar 容器做一个更改。当集群的规模到一定的程度之后有很多的业务要进行更新操作更新的时候会对调度器带来一些压力这是可以完全避免的。从这一点上看K8S 原生设计上对规模比较大的集群还需要一定的优化。从资源锁定的角度资源不足的时候被内部抢占也可以通过原地升级来解决因为 Pod 根本没有销毁所以 pod 的立面没有改变其它的 pod 不会调到这一台物理机上不能达到 pod 锁定的目的。腾讯高级工程师 杜扬浩Harbor 是目前唯一的一个也是最流行的一个开源企业级镜像仓库解决方案。Harbor 除了包含最原始的镜像功能以外还包含用户图形界面以及它的认证、鉴权模型同时它还支持病毒扫描、镜像的复制。另外它也支持一个 RestfulAPI这对企业来说是非常重要。最后 Harbor 也比较好部署现在 Harbor 支持两种部署模式。腾讯高级工程师杜扬浩在演讲中主要介绍了 Harbor 的优势以及应用过程中的经验。他提到目前 API 可以满足大部分企业的需求但是随着企业的业务越来越复杂应用越来越多原有的 API 就有点不够了。杜扬浩举例说「我查询过一个仓库所有的镜像列表它最开始提供的 API 里面并没有企业用户所需要的一些信息比如需要对某个用户进行过滤或者对某个字段进行过滤这时候它的 API 就不能满足企业用户的需求。」这时候就有一个问题怎么在不改变 Harbor 的情况下来适应企业级的需求有两种方案第一种是内嵌式的修改方案。直接修改 Harbor API让 Harbor 实现 API另一种是非侵入式的方案。在 Harbor 的外面另外配置一个适配器所有对 Harbor 的适配操作全部通过 Harbor Adapter 改造无需修改 Harbor。这两种方案相比使用非侵入的方案需要几百行代码来完成这个逻辑如果用修改 Harbor 代码的方式可以通过几行代码实现一个非常简单的功能。但是内嵌式的方案有一个很大的缺点它对 Harbor 是有侵入的当 Harbor 升级、修改比较多的时候维护成本随之会增加有可能当 Harbor 进行了一个版本升级的时候企业内定制的 Harbor 也需要进行升级就需要一个完整的路径来进行升级的工作。对于非侵入式的 Harbor 修改方案来说优点也很明显唯一需要注意的是 API 的向下兼容。如果它的 API 不能实现向下兼容就需要进行适配它的缺点就是一个效率问题可能一个很简单的操作就需要很麻烦地拼凑才能实现同样的效果。还有就是对一些有状态的数据的操作比如需要在 Harbor 原有的数据的模型下再插入一些数据在外部就不是那么好做还需要在里面存储一份数据这份数据还要和 Harbor 原有的数据合并这并不适合采用侵入式方案。综合来说在满足性能要求的情况下可以接受非侵入式对 HarborAPI 调用的损失。但更值得关心的是这种升级所带来的维护成本。因为这种非侵入的方案有利于 Harbor 的升级和维护当开源的 Harbor 升级的时候可以用很少的工作量完成 Harbor 的迁移和升级。Harbor 虽然支持完善的认证和鉴权机制但是企业内部一般都有自己定制的认证和鉴权逻辑而这些特殊逻辑是无法通过 Harbor 现有的方式来兼容的。怎么在不修改 Harbor 的情况下进行认证和鉴权首先是无侵入的认证和鉴权。它的核心就是把认证和鉴权从 Harbor 内部迁移到 Harbor 外部。现在的流程是平台调用认证中心由企业的认证中心来完成这个认证和鉴权当认证和鉴权通过之后再调用 Harbor 的 API 来执行相关的操作。执行完相关的操作之后还需要把对应的 RBAC 的资源写入到认证中心这样就可以实现对 Harbor 的无侵入认证和鉴权修改方案。API 的认证、鉴权无侵入方案存在的一个问题就是它不能兼容 docker 命令行因为它不是使用我们的平台 API它是由 dockdemo 加入所以这里面还要对认证和鉴权的命令行做一个无侵入方案。在企业生产环境里如果需要部署 Harbor要进行高并发来压测一下。杜扬浩在演讲里对比了基于普通的 CephFS、基于对象存储和文件存储这三个环境的压测对比。Harbor Ceph FS 压测Harbor Rook FS 压测Harbor Rook Ceph RGW 压测通过压测数据得出结论随着并发量的增加三种存储平均拉取时间都在增加而且成功率也是越来越低。10 个并发的时候是 100%30 个并发是 92%600 个并发是 73%当然这里面很大的原因是 Harbor 本身的 bug 问题。可以认为 rook 的文件系统和普通用物理机搭建的文件系统性能接近rook 的对象存储的性能是远高于 rook 搭建的文件系统的。除了刚才提到的对象存储的性能本身就优于文件系统之外为什么 Harbor 压测结果有这么高性能的提升经分析可知一方面Harbor 切换了对象存储之后它在与 docker 交互的过程中会采用一个重镜像的技术这样流量就从 Harbor 切换到对象存储的服务里面来Harbor 就不需要中转数据节省了 Harbor 自己的一些资源以及时间。另一方面数据由 Harbor 切到对象存储之后流量瓶颈和并发瓶颈就由 Harbor 转到了对象存储所以基于上面的两个原因就导致了 Harbor 在切换对象存储之后它的性能有了一个质的提升。还有比较重要的一点是关于 ceph 文件系统的备份还原。对于 Harbor 的 ceph 文件系统来说Harbor 的数据实际上是落地在文件系统的某一个路径上这里备份的原理就很简单通过 PV 获取到它的路径然后把这个路径 mount 到本地的文件系统通过这个文件系统进行一个压缩或者备份。文件系统的还原就是刚才备份的一个逆过程只需要把备份的数据打入到刚才 mount 的文件系统里面就可以了。对于 ceph 的对象存储来说它的备份还原的原理实际上是一样的但是它的具体实现就有点区别因为对于对象存储来说它的数据不是保存在某个路径下而是保存在对象存储的 bucket 的概念中所以如果要对 Harbor 的对象存储进行备份还原就需要对这个对象存储中 Harbor 所对应的 bucket 数据进行备份还原。 在现场提问环节部分参会者也问到了关于腾讯云容器服务 TKE 的问题为什么选择 TKE开源自建 K8S 与 TKE 的对比如下想了解更多扫码回复TKE 即可免费获取本次技术开放日完整 PPT 资源。点击
