又是一年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是什么关系？下面我们来一一解答这些问题。

Cube，为了让更多客户获益

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

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

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

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

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

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

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

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

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有两个关键词：简化、节约。为的都是降低门槛，让更多用户用上容器这样先进的技术，享受时代的红利。

承上启下，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也将秉承初心，去帮助客户上云，完成数字化升级。