Kubernetes 复杂吗？可以不复杂( 二 ) 据调查

文章插图
其次，把业务迁移到 Kubernetes 的时候，把单体业务变成分布式业务、微服务的时候，用户一定需要考虑容器日志的统一收集、统一管理的问题。在 Cube 里面自动完成了日志的采集工作，集成了日志管理工作。另外，对容器环境的监控也是同样的道理，统一在 Cube 中完成。
文章插图
当把这些产品全部集成到 Cube 里以后， Cube 是一个什么样的产品形态呢？
首先保证 Kubernetes 最核心的功能，用户能够在 Cube 里面创建 Kubernetes 常用的对象；另外 Cube 的产品形态应该是无服务器的形式；最后， Cube 引入了轻量级的虚拟化技术，实现了容器组与容器组之间虚拟机级别的隔离，这样好处是什么呢？
我们都知道容器的运行是共享使用宿主机的内核的，存在一定的安全风险， Cube 为每一个容器组实现了一层虚拟机的封装，可以使用户安全的运行容器；同时 UCloud 容器团队针对虚拟机的启动进行了深入优化，虚拟机启动速度最快只需要 125 毫秒。
Cube 的功能亮点快速迁移
让我们横向对比一下，用户使用 Kubernetes 和 Cube 的流程上会有哪些区别。
文章插图
左边是 Kubernetes ，用户要把业务迁移到 Kubernetes ，大概要经过这几个步骤：

第一个步骤学习 Kubernetes ，不仅仅是一个人，也可能不仅仅是一个团队，这个过程可能需要三个月到一年。
搭建集群，考虑集群的参数配置、集群的维护工作。
然后是做业务镜像。
之后还要考虑了解 Kubernetes的 API 以及 Kubernetes 应用。
最后才部署应用。

从 UCloud 观察到的情况来看，如果是对 Kubernetes非常熟悉的用户，这个过程可能要一两个月；但是如果对 Kubernetes 不熟悉，需要半年乃至一年。
使用 Cube 的话，就不再需要学习复杂的 Kubernetes知识了，和创建虚拟机一样在 Cube 里面创建一个应用，全部都是图形化的方式。所以， Cube 整个流程只有两步：

制作镜像。
在 Cube 的界面上直接部署应用就好了。

UCloud 产品经理张鹏波说， “我们有几个用户知道了 Cube 公测，公测以后第一天进行了解，第二天就把自己部署的业务迁移到 Cube 上来了，一天的时间就可以完成业务迁移的工作。 ”
成本降低
另外在成本方面，我们知道 Kubernetes 是一个大型的分布式集群，除了工作节点以外，还有管理节点。管理节点只是用来管理 Kubernetes 支持的应用，这部分开销实际上从企业角度来看是浪费的。对业务没有起到正向的作用，所以 Kubernetes 成本会比较高。
而对于 Cube ，因为只需要为容器实例来付费，容器用了多少资源就付多少钱，不再考虑管理节点的开销、资源预留的问题。
更多的便利性
此外，还有一些其他针对 Kubernetes 自身的一些的改进。在 Cube 整个研发过程中，引入了一些亮点。
第一个是镜像预热，我们知道容器的启动速度其实很快的，基本一秒钟就能拉起来容器实例。但是这是热启动的情况，就是说工作节点上有这个镜像时，拉起来速度是很快的。而在冷启动的情况下，如果虚拟机上没有对应的镜像时，并且镜像非常大时，这个过程就非常缓慢了。我们遇到过最大的镜像有 20G 以上，容器的启动的时间就要花费几分钟。这样，容器本来说快速启动的优势就没有了，比虚拟机还慢了。所以， UCloud 在研发 Cube 的时候，使用了镜像预热的技术，把容器镜像变成 MBD 设备，在容器启动的时候，把它纳入到启动容器的节点上去，省去了镜像拉起的时间，让容器冷启动的时间从以前需要十几分钟变成现在只要几秒钟就拉起来了。
另外，因为 Kubernetes 是由谷歌开源的一项方案，很多理念和大部分企业更加超前一点。所以，在这种设计理念下， Kubernetes 每一个容器在重启以后，容器的 IP 就会变化。而我们知道很多传统的应用设计上是依赖于固定 IP 的， IP 一旦变化整个应用就会出现一些问题。很多用户都希望让容器重启后 IP 保持不变。这对于特别是有状态的服务尤为重要。所以，在 Cube 里面使用了 UCloud 的 EIP 功能，能够让用户容器重启时其 IP 保持不变。
最后， Cube 要兼容原有的运维习惯。传统上，虚拟机和 IDC 里面的物理机在使用体验上是没有什么差别的。有些用户之前业务部署在虚拟机，经常需要在出现问题的时候，直接登录到虚拟机里面去排错，查看一些日志。所以，为了兼容用户以前使用虚拟机的习惯，在 Cube 里面的容器也提供了登录功能，让用户在业务出现问题的时候，能够登录到容器里去快速排查问题。