继UK8S后，UCloud再推容器实例Cube，为了谁？

又是一年Think in Cloud，疫情原因，形式变了，线上+线下同步进行，但精彩不变。此次大会上，UCloud带来了众多最新的产品技术和最佳实践，一天跟下来，无数次感叹，UCloud能在巨头夹击的公有云市场存活下来，并且成为公有云上市第一股，绝不是靠运气，UCloud有两把刷子。

本文就借着UCloud新产品Cube容器实例（以下简称“Cube”）发布的契机，聊聊UCloud为什么能成功。

谈起容器，大家应该不陌生。

伴随云计算2.0时代的到来，云原生受到空前关注，容器作为云原生最基础的技术，在短时间也实现了快速普及。来自权威机构的调查数据显示，2019年已有43.9%的用户采用了容器技术，另外有40.8%的用户计划采用容器技术，容器发展势头可以说非常迅猛。与此同时，Kubernetes已成事实上的标准，几乎一统容器天下。

那么一连串问题就来了，既然Kubernetes大器已成，UCloud为什么还会做Cube这样一款产品？事实上，UCloud也有Kubernetes的产品UK8S，Cube有什么独特价值？Cube和UK8S是什么关系？下面我们来一一解答这些问题。

01

Cube，为了让更多客户获益

Kubernetes香归香，但不是所有用户都能共享到Kubernetes的技术红利。为什么这么说？UCloud近两年的客户服务历程可以说就是最好的注解。

UCloud产品经理张鹏波在演讲中提到一个非常有趣的现象，两年前他们在和一些客户沟通时，对方就说想把业务嵌到Kubernetes中，但两年过去了，他们还在说着同样的话。

UCloud很困惑，因为这其中UCloud也做了很多线上线下的技术培训。但结果依旧很不理想，本质原因究竟是什么？其实就一句话，Kubernetes太复杂了，很多企业没有足够的能力、资源去系统学习、规划、全面上Kubernetes。

事实上，这也是自2018年，UCloud推出Kubernetes产品UK8S至今，两年间服务客户过程中收到的问题反馈的集中体现。据张鹏波介绍，用户对Kubernetes的困惑可以归纳总结为三个方面：

一、Kubernetes体系较为复杂，学习曲线比较陡峭，需要客户团队有一定技术储备，对于已经使用容器但尚未尝试Kubernetes的客户也是如此，一方面需要了解Kubernetes的技术体系，另一方面需要修改应用架构适配Kubernetes。

二、维护Kubernetes集群会增加额外的负担，用户除了管应用还需要管后端资源，并不能实现以应用为中心的业务管理。

三、Kubernetes会造成资源浪费，因为它是基于虚拟架构建容器，而不是直接建立容器，这也导致应用就绪等待时间较长，并不能完全体现容器敏捷的特性。

所有这些因素促使UCloud下决心研发一款新的容器产品，让没有太强技术能力的企业也能用上、用好。这款新产品也就是本文要讲的Cube。

02

Cube，有什么不一样

下面来全面认识一下Cube。

先来直观的看下Kubernetes和Cube的使用流程对比，如下图，一目了然，Cube相较Kubernetes，省去了三个费时费力的步骤，Kubernetes是先学习，而Cube只需要容器镜像就能使用。

对Cube有了直观的认识后，下面再来详细拆解一下Cube。

简单理解Cube，它是一个小号的Kubernetes体系。在Cube中，UCloud保留了诸如Kubernetes自动部署调度、快速扩容、故障自愈等便捷用户使用的功能，去掉、屏蔽了像Kubernetes架构、配置、网络等的复杂性。

所以，Cube基本上可以理解为一个傻瓜式的平台，点点鼠标就能完成部署应用。就如张鹏波所说，通过Cube，用户只需要提供打包好的容器镜像，即可快速、批量部署容器化应用，而不需要预先购买云主机或UK8S集群。换句话说，无论是技术层面还是成本方面，Cube都能带来极大的改善。

具体来说，firecracker轻量级虚拟化、cri-o + firecracker-containerd容器管理服务，以及Kubernetes基本调度框架是Cube的基本组成单元。当然，每一部分UCloud都进行了相应的优化。

比如，虚拟化层，UCloud对firecracker的kernel/rootfs/init进程等做了充分地精简优化，只保留了最基本的功能，以加快启动速度，减小安全攻击面，降低资源消耗。另外，UCloud还在firecracker中内置了infra container，使得Cube作为pod运行时可以不必挂载额外的infra容器。

容器管理层，UCloud修改了cri-o管理容器组的架构，采用了单pod对应单shim的模型，这样可以显著降低shim资源消耗，简化容器管理。

调度层，针对Kubernetes，在控制面，UCloud采用了自定义的调度器，可以更好的满足多租户场景下任务优先级、调度速度、资源管理的需求。在宿主节点上，鉴于Cube运行的特点，UCloud精简了一些不需要kubelet实现的功能，例如在宿主上挂载configmap/volume目录、运行cni插件、收集特定目录日志等，增强了容器与宿主之间的隔离安全性。

从以上内容不难看出，Cube不是基于开源软件简单改改而来的一款产品，而是UCloud真正从用户需求侧出发，一点点打磨出来的一款产品。事实上，这也是UCloud成功的一个决定性因素，以客户为中心，狠抓产品创新，回顾UCloud的发展史，这样的例子不胜枚举，比如安全屋就是另一个典型。

全面创新使得Cube有着与众不同的特性，比如：

•   

免运维。不需要云主机自然就省去了维护过程，真正让用户做到以应用为中心。

•   

无操作系统占用。不需要基础运行环境，做到申请多少资源，容器就能使用多少资源，能用尽用，按需付费，最大程度减少浪费。

•   

更小的规格。容器可以创建的足够小，Cube最小规格可以做到0.1核128Mi，给用户更细粒度的业务选择。

•   

虚拟机级别强隔离。firecracker轻量虚拟化技术能使每个容器组之间形成隔离，注意不是进程级别的隔离，提高了容器运行的安全性。

•   

按秒付费。Cube实现了用户只需为容器运行的生命周期进行付费。

Cube值得一提的特性还有很多，比如每个Cube实例都具备独立的内网和外网IP，Cube实例重启后，内网和外网IP保持不变，并且可以作为ULB的后端服务节点对外暴露服务，提供稳定可靠的服务。再比如，Cube目前已支持在创建时直接挂载UFS作为持久存储，这一点在便利性上甚至比云主机更好。

综上所述，Cube有两个关键词：简化、节约。为的都是降低门槛，让更多用户用上容器这样先进的技术，享受时代的红利。

03

承上启下，Cube的大用处

最后聊一下Cube和Kubernetes的关系。

前面提到了Cube的调度层用的也是Kubernetes，只不过做了一些改造，所以Cube和Kubernetes的关系其实很简单，Cube可以向上对接Kubernetes。在UCloud内部，Cube被定义为一个承上启下的产品。

对下，Cube可以让在技术、支出方面有顾虑的客户用起来，向上，如果客户容器应用规模逐步扩大，又可以无缝衔接更加强大的Kubernetes体系。换句话说，UCloud给客户提供了一种分层建设的路径。

正因如此，在7月初UCloud将Cube推出公测至今短短几个月时间，吸引了很多容器的客户，典型场景如业务弹性扩缩容，比如达达就属于此，再比如数据采集、转发业务，因为Cube能够以更小的规格实现，能够帮助客户节约成本。

张鹏波表示，Cube的适用范围是很广的，对于已经使用Kubernetes的头部客户来说，可以把Cube作为资源池来使用，做弹性扩缩容。对于腰部客户、小客户，Cube则可以带领他们入门，提前享受容器技术的红利。

总结全文，透过Cube我们不仅看到了UCloud的产品匠心。Cube更像一面镜子，透过它，能读懂UCloud的很多。以客户为中心，不能只关注大客户的需求，还应该有广大的中小客户痛点，这才是UCloud成功的关键。未来，Cube还会朝着简化、节约的目标再前进，UCloud也将秉承初心，去帮助客户上云，完成数字化升级。

生成海报

免责声明：此文内容为第三方自媒体作者发布的观察或评论性文章，所有文字和图片版权归作者所有，且仅代表作者个人观点，与 无关。文章仅供读者参考，并请自行核实相关内容。投诉邮箱：editor@fromgeek.com。

免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。