共计 3365 个字符，预计需要花费 9 分钟才能阅读完成。
Cube 诞生背景
随着云原生技术的推广及落地，容器技术在企业生产环境中的应用比重越来越大。Kubernetes 作为容器编排的事实标准，在企业服务中被大量采纳。UCloud 容器团队在 2018 年推出了 Kubernetes 产品 UK8S, 这款产品基于 UCloud 私有云环境实现，无缝集成了 UCloud IaaS 层计算、网络及存储的服务，使客户可能疾速获取到生产可用的 Kubernetes 集群，并领有灵便管制集群的能力。
但在 UK8S 产品推广及接入客户过程中，容器团队也陆续收到一些用户反馈的问题：
**
- 保护 Kubernetes 集群减少了额定的累赘；用户除了管利用还须要后端资源，并未能实现以利用为核心的业务管理。
- Kubernetes 体系较为简单，学习曲线比拟平缓，须要客户团队有肯定技术储备；对于曾经应用了容器但尚未尝试 Kubernetes 的客户也是如此，一方面须要理解 Kubernetes 的技术体系，另一方面须要批改利用架构适配 Kubernetes。
- 心愿能有一款即开即用的容器产品，通过容器间接拉起利用，不须要期待虚拟机就绪再部署利用，缩短利用就绪等待时间。**
为解决上述用户问题，容器团队开发了一款新的 serverless 容器产品 Cube&version=12040210&nettype=WIFI&lang=zh_CN&fontScale=100&exportkey=AeyrACYKyIn6fp2sFm1vTgs%3D&pass_ticket=4wqmpVNc2jvkdI3dVYbM1f74r5bD%2FzhEMtm19sXCUL0fO4Be09DNFqEUoj08GHxM&fontgear=2.000000)，目前正处在公测阶段。除了升高用户应用容器的门槛，该产品还具备以下个性：
- 免运维 ：没有保护资源累赘，不须要关怀运行地位，以利用为核心，以容器镜像为利用打包规范。
- 按需付费 ：依照利用理论应用资源付费。
- 主动扩缩容 ：基于海量资源，提供 API，可按需拉起和敞开利用，主动调度资源。
- 高可用 ：产品自身高可用，同时提供利用自愈能力。
技术选型
在实现 Cube 产品个性的过程中，容器团队须要解决几个技术问题：
1. 容器运行时的选型
私有云产品必然要思考多租户隔离问题。不同于 UK8S 产品以云主机为根底构建的隔离性，Cube 产品则间接在宿主物理机上运行容器。规范 docker 实现的容器并不能实现同台宿主机上不同用户不同容器之间的强隔离，因而 Cube 产品须要一款同时具备虚拟机强隔离性和容器疾速启动特点的容器运行时计划。
容器团队留神到 AWS 开源了轻量级虚拟机 firecracker，具备资源占用少、启动速度快、易于保护等诸多长处，并已用于理论生产环境，十分合乎 Cube 业务场景，因而最终采纳了以 firecracker 轻量级虚拟机为根底的容器运行时计划。从上面两张图能够看出，通过对云计算场景特地的精简和优化，firecracker 绝对于目前支流的虚拟化组件 qemu 在启动速度和内存耗费方面有显著的劣势。
VMM 启动工夫和内存占用比照，图片援用起源 &version=12040210&nettype=WIFI&lang=zh_CN&fontScale=100&exportkey=AeyrACYKyIn6fp2sFm1vTgs%3D&pass_ticket=4wqmpVNc2jvkdI3dVYbM1f74r5bD%2FzhEMtm19sXCUL0fO4Be09DNFqEUoj08GHxM&fontgear=2.000000)
2. 容器治理服务
反对虚拟机容器运行时的容器治理服务也有多种开源计划，例如 containerd/cri-o，kata-container 和 firecracker-containerd 等。通过比拟，容器团队抉择了 cri-o + firecracker-containerd 的组合。这二者在性能上可能满足单机容器治理的需要，而且和其余选型相比，代码架构更加清晰，调用链路简单明了，便于后续依据产品需要定制和革新。
3. 容器调度服务
Kubernetes 曾经成为了容器调度的事实标准，具备丰盛的性能和良好的可扩展性。因而容器团队采纳 Kubernetes 作为根本调度框架，并依据产品需要做相干革新，最终根本的服务架构如下所示：
优化改良
尽管采纳开源计划能够放慢开发进度，但为满足产品需要仍需解决一些问题，次要包含以下几个方面：
1. 容器镜像
在规范的容器镜像实现中，镜像是通过分层构造存储在宿主上的。当创立容器时，容器运行时会在镜像层之上创立一个可写层，并挂载在宿主上供容器实例应用。但 Cube 容器并不是间接在宿主上运行的，也不须要在宿主上挂载容器根目录。因而容器团队批改了 cri- o 中镜像层的相干实现，间接将容器可写层以块设施的形式挂载到轻量级虚拟机中而非宿主上，减低了宿主对 Cube 容器的烦扰。
另外，为了解决新镜像拉取迟缓导致的容器实例启动慢的问题，容器团队提出了镜像近程挂载的解决方案。将容器镜像以块设施的模式存储在缓存集群，当须要在此镜像上生成容器实例时，先将容器镜像通过近程挂载的模式挂载到宿主上，而后容器运行时会在宿主上创立一层可写层生成容器实例。同时后盾会将近程镜像同步到宿主本地，进一步减速读取，升高集群危险。上述办法可使宿主上首次获取镜像的工夫缩短至 3s 以下，并有进一步优化空间。目前这一性能以镜像缓存的产品模式提供给用户应用，并正在逐渐整合到一般镜像拉取过程中。
2. 应用私有云资源
网络方面，Cube 容器的网络模型和云主机的基本相同。在将相干网络性能以 cni 插件的模式实现之后，Cube 容器就能够很好的接入到私有云 vpc 网络中。
存储方面，Cube 容器目前反对了两种类型的存储：能够多点读写的网络文件系统 nfs 和仅单点读写的云硬盘 udisk。在文件存储性能上，Cube 产品实现了在轻量级虚拟机中主动挂载 nfs 的性能，用户只需在配置文件中指定好挂载点和挂载参数，就能间接在容器中应用网络文件系统，并能够同时反对 vpc 网络内用户自建的 nfs 和 UCloud 私有云产品 ufs。在块设施性能上，容器团队扩大了 firecracker 块设施的实现。通过增加对 vhost-user 协定的反对，Cube 轻量级虚拟机能够间接对接到 spdk 服务，从而实现了对高性能的 rssd 型云硬盘挂载和应用。
3. 容器运行环境
为了缩小额定资源耗费，容器团队在容器治理服务和容器运行时上做了大量优化工作。
容器团队批改了 cri- o 治理容器组的架构，采纳了单 pod 对应单 shim 的模型。通过一个 shim 治理一个 pod 内全副容器，能够显著的升高 shim 资源耗费，简化容器治理。对于轻量级虚拟机，容器团队也对 kernel/rootfs/init 过程等做了充沛地精简优化，只保留了最根本的性能，以放慢启动速度，减小平安攻击面，升高资源耗费。另外，容器团队还在轻量级虚拟机中内置了 infra container 的实现，Cube 作为 pod 运行时能够不用挂载额定的 infra 容器。
4. k8s 革新
Kubernetes 作为一个通用的容器调度框架，可能满足大部分容器治理的需要。但针对 Cube 特定的应用场景，容器团队仍需对 k8s 组件做一些革新。在管制面，容器团队采纳了自定义的调度器，能够更好的满足多租户场景下工作优先级，调度速度，资源管理的需要。在宿主节点上，鉴于 Cube 容器运行时的特点，容器团队精简了一些不须要 kubelet 实现的性能，例如在宿主上挂载 configmap/volume 目录，运行 cni 插件，收集特定目录日志等，加强了容器与宿主之间的隔离安全性。
Cube 将来瞻望
在实现了上述开发革新后，Cube 产品胜利上线，并获得良好效果。后续 Cube 产品会持续沿着帮忙用户晋升效率、升高开销、简化保护、节约老本的思路继续迭代更新。在容器性能方面，容器团队会持续优化轻量级虚拟机 IO 门路，缩小虚拟化及治理组件的性能损耗，确保用户容器实例稳固高效运行。在服务治理方面，Cube 产品层面会推出多种的容器治理控制器，并实现 Cube 实例间接接入 Kubernetes 集群的能力，为用户提供多层次的资源调度形式，不便用户按理论须要治理保护。
如果您对 UCloud Cube 产品感兴趣，欢送扫码退出 Cube 测试交换群！