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

继UK8S后,UCloud再推容器实例Cube,为了谁?

本文就借着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的困惑可以归纳总结为三个方面:

继UK8S后,UCloud再推容器实例Cube,为了谁?

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

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

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

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

Cube,有什么不一样

下面来全面认识一下Cube。

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

继UK8S后,UCloud再推容器实例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也将秉承初心,去帮助客户上云,完成数字化升级。