背景
最近几年基于容器技术的资源分配方式越来越流行,kubernetes作为容器领域事实上的容器编排技术也开始在企业中逐渐落地。借助容器、微服务DevOps等技术,新生代的云原生应用得到了极大的普及。但在企业的应用生态中,当前云原生系统仅占很小的一部分,尚存在大量的传统应用无法享受容器技术带来的好处,业界需要一种专门针对传统应用快速上云的解决方案。
-
传统应用往往部署在虚拟机上,而虚拟机启动较慢,不能满足业务灵活性,弹性的需求。
-
虚拟化技术堆栈较重,资源损耗大,客户希望能够充分发挥强大服务器硬件的能力。
-
传统应用的运维人员更倾向于将应用系统视为pet而不是cattle,发现问题后更希望能手动去做调整。
-
应用对性能敏感,容器环境下的高密度部署引起的CPU上下文切换等性能造成很大影响。
博云胖容器技术BeyondVM
01
1号进程
容器技术推崇单进程模型,而胖容器技术与容器技术一个明显的差异点就是在胖容器内部运行一个init进程,而传统的容器(如 docker 容器等)将容器镜像中指定的 CMD作为容器内 pid=1 的进程。BeyondVM技术支持使用systemd和sbin/init作为init进程。init程序的引入,使得胖容器内的运维工作成为可能,也为传统应用上云提供了很大的便利。
02
容器的CMD
容器的CMD代表了容器内部运行的业务系统。beyondVM技术会自动将其托管在Init进程下,运维人员可以方便的对业务系统进行运维工作。
03
系统组件或特定agent
传统应用和应用的运维人员依赖众多系统组件,比如ssh/rsyslog/crond等。这部分传统应用上云时可以直接安装相应组件并做成镜像,这样既获取了容器交付可移植性强的优势,又保留了传统的使用习惯。
04
资源视图隔离
传统的应用系统经过多年的维护,往往具有多种的优化措施,例如业务上线后,自动根据环境资源大小调整运行时参数。但传统容器环境下,即使为容器设置了cpu/mem配额,容器内部的业务系统仍然会看到主机的计算资源。这对传统的应用如典型的java应用造成了很多问题。BeyondVM技术利用lxcfs技术对容器的资源进行了视图隔离,从而让内部运行的业务系统能自动感知容器自身的计算资源。05
业务启动前和停止后的钩子处理
因为BeyondVM技术与Kubernetes进行了集成,因此可以天然利用kubernetes为pod提供的钩子函数实现业务系统启动前和停止后需要的处理工作。与容器、虚拟机的技术对比
|
虚拟机 |
容器 |
BeyondVM |
模型 |
基于kvm+qemu,内核隔离 |
基于cgroup+namespace,共享内核
|
基于cgroup+namespace,共享内核
|
资源消耗 | 重 | 轻 | 轻 |
镜像体积 | 大 | 小 | 小 |
进程模型 | 虚拟机内可以运行多个进程 | 容器内单进程 | BeyondVM内部可以运行多个进程 |
状态保持 |
|
|
|
弹性伸缩 | 状态重,弹性伸缩慢 | 手动、自动快速弹性伸缩 | 手动、自动快速弹性伸缩 |
移植性 | 差 | 强 | 中 |
微服务、DevOps支持 | 差 | 强 | 强 |
Kubernetes支持 | 差 | 支持 | 支持 |
主要场景 |
|
|
|
BeyondVM核心优势
BeyondVM 提供相对完备的进程树和系统服务的容器环境,使得业务获得虚拟机的运行体验,无需改变代码即可实现向容器平台的迁移。利用BeyondVM技术,可以实现:- 比虚拟机轻量的资源分配能力,以方便资源快速申请、弹性。
- 类似虚拟机的使用体验,可登陆,可任意安装组件。
- 有固定IP地址,胖容器从创建到删除,IP地址保持不变。
- 可以通过ssh远程登录系统。
- 登录登录后,可以通过传统的yum命令安装标准的软件包, 比如mysq,apache。
- 可以安装运维类的agent,不影响应用的正常部署流程。
- 资源隔离,如CPU、内存等。
- JVM,监控类工具看到的资源不是整个物理机的资源,而是真实分配给胖容器使用的资源。
展望
当前容器云平台建设的过程中,上线的往往是新的业务系统;企业中大量的存量业务仍然运行在物理机或虚拟机环境中。虽然目前已经有部分企业碰到了传统应用上云困难的问题,但整体上这部分需求还不强烈。我们有理由相信,随着容器技术在企业生态中的占比逐渐增加,传统应用上云的需求会逐步释放出来,胖容器技术将在其中发挥重要作用。