据相关调研机构出具的报告数据显示，目前应用容器市场规模将从2016年的 7.62亿美元增⻓到2020年的27亿美元。 显而易⻅，引入容器所展现的巨大灵活性有效推动了其采用速率，使企业日益依赖该技术，与此同时容器技术也逐渐成⻓为虚拟机的实力替代品。对此，调研机构Forrester公司曾指出， 58%的开发商计划在未来一年内使用容器或正在计划使用容器。

总结来看，使用容器可以帮助企业提高效率、降低成本，甚至在安全性方面有更可靠的保障， 这些易于打包以及轻量级的组件可以与同一虚拟机中的其他组件一起运行；此外容器的大力采用也让开发者通过创建虚拟“沙箱”来更快、更好地工作，从而完成编写、管理和操作软件代 码，可以在不影响服务器或虚拟机(VM)上运行其他应用程序和系统的情况下就可完成此操作。

基于此，CSDN云计算特别策划了容器服务盘点系列文章，欲以CSDN中立技术社区专业、客观的角度，探讨当前云服务商眼中的“容器服务”并为开发者选择合适的容器服务提供相关建议，以帮助其实现容器技术的创新应用等。

为此，我们采访了数家提供容器服务的云服务厂商，本期程序员硬核评测，我们请来的是UCloud的容器服务的明星产品UK8S以及其实验室负责人叶理灯共同带来技术分享。

K8S厉害不假，但需要走的路依旧很长

经过漫长的技术演进，带有相似规律的一点，从炉火纯青的容器技术到炙手可热的K8S，每次新技术的应运而生都预示着一场“效率革命”的来临，无论是开发、运维还是运营等诸多重要环节。在此背景下谈及企业对容器云平台的构建与创新，UCloud实验室负责人叶理灯可谓感同身受。

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

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

基于以上原因，叶理灯及其团队着手构建内部的容器云平台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本身轻量级快速启动的效率，虚拟化容器还是比较符合此项需求的。

另附技术小贴士

据了解，基于Kubernetes自动化部署、弹性伸缩和容器化等特性，UCloud针对内部研发人员和外部用户分别构建了容器云平台。

其中UCloud内部容器云平台（简称KUN）的底层是基于Kubernetes搭建的，主要的实现方法之一是K8S+Docker，通过Docker提高运维部署效率和运维环境的一致性，通过K8S实现跨可用区容灾和AutoScaling能力，从而实现高可用、在线升级、自动扩缩、负载均衡、日志查看、资源监控等多种功能。

叶理灯提到，在构建内部容器云平台KUN的过程中要解决四个主要问题，分别是：

1. 多租户隔离的问题，保证业务之间互相不受干扰
2. IPv6的问题，如何保证跟IPv4网络兼容
3. 如何用Operator来管理有状态的服务
4. 监控问题

对应的解决方案是：

基于RBAC来实现账号管理隔离，选择Token认证方式，通过服务账号SA（Service Account）模拟普通用户User，所有模拟账号的SA放置同⼀个NS，进行统⼀管理；定制权限组ClusterRole，通过授予模拟账号SA的不同权限组，来控制不同User在NS中的不同权限。抽象Project对象给User使用，Project与每个集群的NS⼀⼀对应，User在每个集群上都有对应模拟账号用于NS授权。

针对IPv6的问题，接入6to4 Tunnel和Bridge网桥，核心基础网络无需修改，采用underlay，实现Pod与集群外部互通。Service全网可访问，ClusterIP在K8S集群外部可以直接访问，分配一个Ipv4地址，在Kubernetes集群下的所有介入交换机上宣告，该IPv4地址对应的6to4地址作为该Kubernetes集群ServiceIP地址段。Pod返回的包，会先回给Service Gatevay，由于做了SNAT，基于连接追踪（conntrack），再返回给请求的客户端。

在KUN中使用Operator，为用户提供可视化 Web 操作页面，简化对各类自定义资源的管理操作。 用户不需要详细理解具体的 CRD 结构，就可以在Web 页面上快速创建⼀个 Redis 集群，并且可以看到集群⼀步步创建的过程。同时还可以对集群进行配置更新、删除等操作。

监控系统方案基于Prometheus构建，Prometheus部署于K8S集群中，使用HostPath存储数据、Metrics采集，使用Alert Manager 聚合报警，调用 Monitor Manager 提供的 Web Hook；自研 Monitor Manager：使用Grafana 实现 Web 可视化；

而UK8S是基于Kubernetes的对外部用户的容器管理服务，用户可以在UK8S上部署、管理、扩展容器化应用，而无需关心Kubernetes集群自身的搭建及维护等运维类工作。

除此之外，UK8S还完全兼容原生的KubernetesAPI、以UCloud私有网络为基础，并整合了ULB、UDisk、EIP、VPC等云产品。

UK8S集群网络通过自研CNI插件与VPC网络深度集成、利用Secondary IP API实现IP管理、无overlay性能与云主机一致、Pod网络可与物理云托管云直接互通。

叶理灯总结了UK8S管理服务的特点，例如：

A、完全的容器化和微服务化。

B、所有管理服务全部运行在K8S上。

C、基于K8S的API对服务模块进行动态管理。

D、一个集群对应生成一个Watcher，容易进行横向扩展。

E、基于Watcher+Redis缓存的方式，保证用户在控制台获取集群信息的速度足够快。