黑基网 首页 资讯 IT业界 查看内容

虚拟机已死

2016-5-6 11:01| 投稿: lofor

摘要: 我也曾经是容器技术尤其是 Docker 粉丝,但用了一年后觉得事情也没那么美好,而颇有一些同学以及一些公司依然认为容器就是银弹,虚拟机已经是昨儿黄花必须打倒,大家赶紧一切皆容器。这里我对这种观点吐吐槽。仅代表 ...

我也曾经是容器技术尤其是 Docker 粉丝,但用了一年后觉得事情也没那么美好,而颇有一些同学以及一些公司依然认为容器就是银弹,虚拟机已经是昨儿黄花必须打倒,大家赶紧一切皆容器。这里我对这种观点吐吐槽。仅代表作者个人看法首先要明确的是,软件开发和运维活动中,可维护性、正确性、性能的优先级是依次降低的,不要跟我抬杠少数极端情况。关于可维护性和正确性的先后,著名的 “worse is better” 文章就是很好的无奈的解释,如果你犹豫这两者,这还情有可原,毕竟真善美和糙快猛的斗争从未停歇,而你如果第一反应觉得性能是最重要的,那就不要继续往下看了,洗洗去睡吧——适合的才是最好的。

那么对于虚拟机 vs 容器,自然我们也需要从这三方面考察。

回合一:可维护性之争虚拟机—维护性

从hypervisor讲,Xen/KVM/vSphere/HyperV 都很成熟了,久经考验,BSD也在凑热闹搞bhyve(FreeBSD)和vmm(OpenBSD),最近unikernel也在试图跑在hypervisor上,而AWS/GCE/Azure等等云计算巨头以及Intel/AMD等在CPU、磁盘和网络IO虚拟化技术上的投资显然不会立马推翻,Linux上虚拟机的开源管理方案也已成熟定型:libvirt, OpenStack,没人吃饱了撑的去弄个“新的开源”项目替换它们,虽然我很不喜欢OpenStack的乱糟和复杂。VM的动态迁移也是成熟技术,出来好多年了,实现原理非常简单,反正整个OS内存一锅端弄过去,不操心少个依赖进程的内存没过去。想用不同版本内核? 想要自定义内核模块?想调整内核参数?期望更安全的隔离?期望如同物理机版几乎一致的使用体验?VM就是虚拟机的缩写嘛,这些都是拿手戏。

容器— 维护性

Linux容器,Linux一贯的作风,慢慢演化,不求仔细设计,然后就是cgroup, pid/uts/ipc/net/uid namespace一个个实现出来,凑出一个容器技术,貌似uid namespace还是最近刚刚出来的特性。用户空间则更是群雄并起,LXC,Docker,rkt,LXD,各有拥蹇,鹿死谁手,还真不好说,在这个局还没明朗的时候,Mesos、Swarm、Kubernetes、Nomad又出来一堆搅局的,眼下看来最吸引眼球的Kubernetes俨然有OpenStack继任者的感觉,但依然很嫩,没几个人敢在生产环境大规模使用。

Linux容器里进程的跨机器动态迁移我还没听说,不要说是个服务就得有集群有HA嘛,可还真有不少用户一个服务就单机顶着呢,就算有热备或者冷备,在线那台机器内存里的东西可宝贵了,轻易不能丢。用Linux容器就不能挑内核,不能加载内核模块,不能挂载文件系统,不能调整内核参数,不能改网络配置,等等,不要告诉我你能——你是不是开了docker run –privileged了? 你是不是没drop capability?你是不是没有remap uid?话说某大公司的容器还真就用–privileged 选项跑的呢。 而Linux的隔离不彻底恐怕大部分人都没意识到,/sys,/dev,/selinux还有/proc下的某些关键文件比如/proc/kcore没隔离呢。

Redhat做的project Atomic意识到这些问题,正在积极的给Docker加SELinux支持,指定SELinux policy,但Docker官方爱搭不理,而且SELinux这种高端技术是凡人玩的么? 结局大概依然是“FAQ 1:关掉SELinux”。Linux容器本来并不局限在一个容器里跑几个进程,但Docker官方为了加强“轻量级”这词的洗脑效果,搞出个无比脑残的single process理念,被无数人捧臭脚,所幸有些人慢慢意识到问题,Yelp搞了个dumb-init擦了一半屁股,还有无数docker image用runit、supervisor 之类的做/sbin/init替换,但问题在于这要自定义启动脚本,需要加ssh/cron/syslog/logrotate等等边角料——这已然是解决了无数遍的问题,还要解决一遍,不觉得麻烦吗?难道没有人认为这些包的作者或者打包者更善于处理服务启动脚本么?像systemd那种搞法还算正道,特意考虑容器环境,跳过一些步骤,但貌似还没做完善,需要手动删除一些.service文件。

虚拟机 vs 容器

也许有人会说docker pull/push多方便啊,docker build多方便啊,可不要忘了,vm image storage早在openstack里就解决了,自己处理也不是个大事,vm image build也有Hashicorp的Packer工具代劳,不是个事。Docker自豪的官方docker registry其实大家最多用用base os image,那些app级别的出于信任以及定制考虑都会自己build。而Docker自豪的layered storage也是无数血泪,aufs & overlayfs坑了多少人?容器社区最近还特崇拜immutable deployment,以把容器根文件系统弄做只读的为荣,全然不管有紧急安全更新或者功能修正怎么处理——什么,你要说docker rm && docker run再起一批不就完事么?真有这么简单就好了。

像Linux kernel和git那种才是正经unix设计的思想,分层堆叠,底层提供mechanism,高层提供policy,各取所需,可惜人总是易于被洗脑,在接受各种高大上policy的时候全然忘了mechanism还在不在自己手里。

回合二:正确性之争

强隔离、full OS体验、保留mechanism,这才是正道。另外容器还隐藏了一个坑,/proc/cpuinfo和free命令输出是host os的,这坑了无数探测系统资源自动决定默认线程池和内存池大小的程序,尤以Java最为普遍。

回合三:性能之争

容器粉丝津津乐道——启动容器快,容器的开销少。 这两点确实如此但好处真的有那么巨大么?谁有事没事不停创建虚拟机?谁的虚拟机生命周期平均在分钟级别?谁的“用完全启动时间”平均在秒级? 至于说到虚拟机浪费的资源太多,其实也就是个障眼法。理论上服务器的资源利用率平均不应该超过 80%而实际上绝大部分公司的服务器资源利用率应该都不到 50%,大量的CPU、内存、本地磁盘都是常年浪费的,所以VM的额外开销不过是浪费了原本就在浪费的资源罢了。就单机的巅峰I/O能力来言,VM确实不敌容器。但平时根本就用不到巅峰状态, 原本一个VM里多进程干的事,非得搞多个容器跑,这容器开销,这人力开销怎么算?

关于容器还有一个幻想,那就是可以在物理机上直接跑容器,开销巨低、管理巨方便,用专用物理机方式提供多租户强隔离。前面两点上面已经驳过了,话说还有人用openstack管理docker容器呢。 我只是说一下第三点,在一台物理机上直接跑容器的一个最容易被忽视的问题:现在用来提供云服务的物理机一般都是硬件超级牛逼,跑上百个容器都没问题,但问题在于用户很可能只需要几个容器,所以要么跟人共用物理机,要么浪费资源白交钱。哪怕用户需要上百个容器,出于容灾考虑,也不可以把上百容器部署到一台物理机上,所以还是要么跟人共用物理机,要么浪费资源。

方案

以上是我的观点,我并不是“容器黑”,而是“实用白”。AWS、Azure、GCE 都主推在虚拟机上跑容器,按虚拟机收费,这非常明智的解决了问题:老的纯VM基础设施不用动,计费照旧,单物理机可以被安全的多租户共用,资源隔离有保证(起码比共享内核强多了),把容器管理软件如“kubernetes”给用户,既满足用户的容器需求,又不担心容器的多租户问题。

所以我认为:以VM为基础,以容器为辅助点,要买就买VM,自己管理容器,别买CAAS直接提供的容器,别看不到底下物理机或者虚拟机。用VM还是用容器,冷静考察自己的应用上容器是否有好处。最后,残念,VM开源管理软件能搞个比OpenStack简单的东西吗?

小编推荐:欲学习电脑技术、系统维护、网络管理、编程开发和安全攻防等高端IT技术,请 点击这里 注册黑基账号,公开课频道价值万元IT培训教程免费学,让您少走弯路、事半功倍,好工作升职加薪!



免责声明:本文由投稿者转载自互联网,版权归原作者所有,文中所述不代表本站观点,若有侵权或转载等不当之处请联系我们处理,让我们一起为维护良好的互联网秩序而努力!联系方式见网站首页右下角。

1

鲜花

握手

雷人

路过

鸡蛋

刚表态过的朋友 (1 人)

  • 鲜花

    匿名

相关阅读

最新评论


新出炉

返回顶部