UCloud叶理灯：内外部容器云平台构建的思考！

一年一度的用户大会，UCloud再次携“中立”而来， 会上一口气发布的诸多产业互联网产品再次印证了其在技术创新方面始终很坚持。尤其是USQL数据湖分析工具、StepFlow工作流服务两款产品更是牢牢抓住了与会者们的眼球，充分印证了一点：在热门的Serverless领域，UCloud也是探索许久、厚积薄发。

关于UCloud Serverless领域的具体创新，阿晶暂且不深入表达，但不可否认的是从炉火纯青的容器技术到炙手可热的K8S，每次新技术的应运而生都预示着一场“效率革命”的来临，无论是开发、运维还是运营等诸多重要环节。

K8S还有很多“努力”的空间

在此背景下谈及企业对容器云平台的构建与创新，UCloud实验室负责人叶理灯可谓感同身受。与很多企业相似，UCloud内部也需要通过一些技术创新来提升运维、软件迭代的速度以及质量保障，进而降低人力成本，故容器云平台的建设被提上日程。“在建设平台之前，公司大部分业务都跑在虚拟机上，数以万计一点儿也不夸张，可想而知虚拟机的初始化部署以及日常运维操作都是很消耗人力的。”他表示。

此外，据了解由于内部架构不统一，似乎每个业务部门都在做属于自己的高可用以及Auto Scaling来分别实施，这就存在了很大程度上的隐形成本；更重要的一点，大量的虚拟机利用率并不高带来很多资源浪费。

UCloud实验室负责人  叶理灯

基于以上原因，叶理灯及其团队着手构建内部的容器云平台KUN，主要采用了K8S+Docker的技术实现，通过Docker来提高运维部署的效率以及环境的一致性，凭借K8S本身跨可用区的特性来保障跨可用区容灾和Auto Scaling能力，最大程度力求弹性、分布式的应用托管，进一步帮助开发者一站式轻松开发并部署应用程序。此外，UCloud容器云平台KUN底层基于Kubernetes，还提供了高可用、在线升级、自动扩缩、负载均衡、日志查看和资源监控等多种功能。

早在2013年，Docker横空出世，如果要说容器的历史那就更是久远了。细想当年Docker的风靡，叶理灯抽丝剥茧认为，是因为其让容器的使用门槛大大降低，其中更重要的成果Docker镜像，妥妥解决了PaaS应用打包标准化的问题。

以此类推，毕竟在Docker解决标准化打包之后，容器的编排就转而成为更加核心的问题之一，所以现今炙手可热的微服务以及容器的大规模落地都与K8S统一应用编排标准息息相关。有了标准，再从应用角度出发，云厂商逐渐学会了从整个生命周期去思考很多问题，例如如何让用户高效在云上落地应用等，带动了从应用的打包、上线、监控以及日志等诸多阶段来提供相应的工具和解决方案的风潮。

但不容忽视的一点，也是叶理灯一再强调的，K8S以容器技术为核心，以容器镜像为打包标准的特点意味着如果企业选择迁移到这个体系之下，就需要做到将软件容器化打包以及微服务改造，成本的关注不可缺少；此外，K8S作为运维和研发之间重要的纽带，企业的研发过程必然会伴随变化而紧随其后，所谓“改变了习惯、增加了负担”就是这个道理。起初无论是在研发还是运维方向都会出现偏重的情况，尽管这一点会伴随时间逐渐产生效率以及成本优势，但任重道远也是真现实。

另外除了业务改造的成本，K8S人才比较缺乏也是个问题。不同用户的情况本就不同，更不可能专门抽调人力运作这项技术。但换个角度来讲，技术人员数量不足，有了问题该如何解决？

在叶理灯看来，其实这就需要云厂商更进一步，除了帮助构建良性发展的K8S平台，还需要协同解决很多技术问题。“每一个用户加入进来，我们都会拉一个群，针对技术方向进行互动。此外在落地方向，我们还想多做一些工作，关于人才以及K8S本身对用户架构的改造，帮助用户培育出K8S的运维人员以及制定关于架构迁移的解决方案。随着技术的发展，未来我们相信会有越来越多人理解K8S，其中云厂商所提供的更便利的产品与服务对其推广助力颇多。”叶理灯接受采访时说道。

总体来说，这是一个新技术落地的问题，会涉及到用户、商业企业甚至是技术社区协同完成；再加上K8S本身也在发展，尤其是Serverless一旦成熟，对其落地就会产生很大的推动作用。所以无论是从UCloud自身的容器实践，还是技术发展的客观规律，容器革命尚未成功，K8S仍需努力！

明星产品UK8S，我们有想法！

谈及UCloud针对K8S的探索与创新，叶理灯认为UK8S服务不得不聊一聊。据阿晶了解，UK8S全称“UCloud Container Service for Kubernetes ”，是一项基于Kubernetes的容器管理服务，可以在上面部署、管理以及扩展私人化的容器应用，过程中无需关心Kubernetes集群自身的搭建及维护等运维工作。更重要的一点，UK8S完全兼容原生的Kubernetes API，并以UCloud私有网络为基础，并整合了ULB、UDisk、EIP和VPC等云产品。

据悉在管理服务方面，UK8S支持完全的容器化和微服务化，可以确保所有管理服务全部运行在内部KUN平台上，基于KUN的API对服务模块进行动态管理；一个集群对应生成一个Watcher，容易进行横向扩展；基于Watcher+Redis缓存的方式，保证用户在控制台获取集群信息的速度足够快，相当于用K8S管理K8S。

托管方面，采用“UK8S+托管物理机”的模式可以合理利用存量物理资源，且无需运维管理UK8S集群以及部署外部负载均衡，业务高峰可随时扩容集群，帮助用户有效利用存量IT资源。例如，Master节点部署在共有云上，Node节点分为公有云和托管云两部分，两个区的网络实现了互联互通等。

值得提及的是，在用户“元年科技”的探索实践中，利用UK8S可以有效解决了新服务的上线以及原有服务的更新过程繁杂、动态服务迁移操作难度大、线上服务健康检查复杂度高、服务之间的调用和发现配置工作多以及单个服务完全消耗云主机资源等诸多痛点。

聊完概念讲本质，叶理灯强调，UK8S服务并不是定制化的K8S，只是基于公有云为用户提供原生应用服务，“不定制”的理念主要取决于不违背K8S的初衷，即保持生命力、不被供应商绑定这样一个原则。

具体来说，在整合IaaS层面，在保证K8S的原生特性的前提下，基于开放体系所提供的插件机制完成二次开发。例如，在网络插件方面，UCloud选择基于自身IaaS的VPC网络，让Pod可以和托管区和物理云区域打通，这一点可以被认为是IaaS能力在K8S产品上的体现，算是特色之一，但这项技术尝试并不影响K8S的原生性质以及开放属性等。此外，在应用层面，公有云厂商可以基于K8S提供一些周边功能来帮助用户提高效率，但这个尝试同样与提供一致性的K8S环境不矛盾。

阿晶认为，这种类型的“定制”其实每家容器厂商都需做到，因为毕竟K8S本身不是一个productio-ready的环境，需要使用者去适配网络、存储以及计算等。如果每个公有云厂商基于自身的IaaS来提供K8S产品，必然要开发插件，例如cloud provider 、CNI和CSI等。此类底层基于自身的IaaS平台定制，本质还是为了提高用户使用K8S的效率，让用户开箱即用。一句话总结，作为公有云厂商，最重要的容器方面工作在于根据云体系，在提供原生K8S的过程中，尽量做到减少在集群管理、资源整合方面的负担。

针对UK8S发展究竟有何路线甚至强规划？关于此叶理灯总结道，要让K8S管理更多的资源，例如多种类型的云主机、物理机甚至是异构资源以及GPU等。

另外在业务层面还会提供一些有关微服务的基础设施，将新技术产品化推进。一方面让用户的资源负担减轻，另一方面令应用层的架构缓解压力，更有助于落地；很关键的一点就是对Serverless K8S的热衷。

炙手可热的Serverless，应该怎么看？

如果说Kubernetes能够专注提升容器集群的运维管理效率，那么Serverless则从根源上摆脱服务器的运维难题，使计算资源作为服务而不是服务器的概念出现，从而将开发人员的效率最大化。有人说Serverless会带来容器轻量化的加剧，对不对呢？对此，阿晶特别求证了叶理灯，他表示并不完全如此。

“其实Serverless最初萌生是针对计算，并等同于FaaS，有一个对标的产品被称为Lambda。总体而言，Serverless出现的动力是由于云计算的飞速发展带来了很多丰富的中间件，例如对象存储等。提出Serverless概念的人希望App的开发者不要集中所有精力写后端逻辑，而是选择直接把逻辑写在客户端，通过在前端组合云上的一些服务来完成业务逻辑，这样就没有管理后端资源的负担。”他说。

但随着对技术认知度的提升，人们发现很多时候还是需要后端代码，所以这个趋势就逐渐演变成“如果有后端代码就被拆分成函数托管在FaaS服务中”，这样操作依然不需要管理服务器，也很便捷。

伴随概念进步，早在2017年AWS提出了一个新概念，借此机会重新定义了Serverless。只要一个服务具备了四方面特性：免运维、按需付费、高可用和自动扩容，就被称为是Serverless服务，所以Serverless这个概念可能对应的是FaaS，也可能代表一种架构，当然也可能代表一种服务形态，例如Aurora。其实容器与Serverless的区别在于Serverless是no Container的，除了不关注Server，也看不到容器。两者面向不同场景，并不是互相替代的关系。

有关实践证明，FaaS具备的特点对一些延时敏感的情况并不合适，但类似IoT的有些场景是非常合适的，比方说设备管理以及图片处理等。总体来看，K8S接受的用户比FaaS的用户更多，因为K8S的面更广，覆盖的场景更多。但叶理灯也同时表达了目前Serverless使用并不普及的原因：不可忽视的一点，国内用户对新技术的接受程度还是比较低的水平，无论是习惯问题还是IT发展水平的差距；此外对国内用户来说将架构改为Serverless成本很高，而且改造的收益和规模相关。需要明确的是，FaaS本身不是一个独立能起作用的产品，需要开放事件源，通过事件去触发函数执行。只有产品体系开放足够多的事件源，FaaS才能渗透到整个平台层面，才能覆盖更多场景，而国内的厂商还没有做到这一点。

但随着API-Gateway方式调用和体系开放事件源越来越丰富，覆盖场景越来越多，相信FaaS会逐步落地。背后的动力还有关于FaaS按需付费和免运维的方式，能有效节省客户成本和提高效率。

谈及未来在容器方向的关注点，虚拟化容器被列为UCloud容器研发的首选。叶理灯认为，如今用户使用K8S还存在资源管理的负担，不能完全面向应用来运维，所以解决这个问题就要提供一个海量集群去跑通客户应用，这就造成了多个客户应用可能跑在同一个节点上。

如此来看，考虑到Docker本身的隔离问题，就需要类似虚拟化容器的计算去完成隔离，同时又渴望具有Docker本身轻量级快速启动的效率，虚拟化容器还是比较符合此项需求的。