虚拟机已死，容器才是未来？
发表于2016-04-08
我也曾经是容器技术尤其是 Docker 粉丝，但用了一年后觉得事情也没那么美好，而颇有一些同学以及一些公司依然认为容器就是银弹，虚拟机已经是昨儿黄花必须打倒，大家赶紧一切皆容器。这里我对这种观点吐吐槽。
首先要明确的是，软件开发和运维活动中，可维护性、正确性、性能的优先级是依次降低的，不要跟我抬杠少数极端情况。关于可维护性和正确性的先后，著名的 "worse is better" 那篇文章就是很好的无奈的解释，如果你犹豫这两者，这还情有可原，毕竟真善美和糙快猛的斗争从未停歇，而你如果第一反应觉得性能是最重要的，那就不要继续往下看了，洗洗去睡吧。
那么对于虚拟机 vs 容器，自然我们也需要从这三方面考察。
回合一：可维护性之争
VM 的动态迁移也是成熟技术，出来好多年了，实现原理从根子上就简单，反正整个 OS 内存一锅端弄过去，不操心少个依赖进程的内存没过去。
想用不同版本内核？ 想要自定义内核模块？想调整内核参数？期望更安全的隔离？期望如同物理机版几乎一致的使用体验？VM 就是虚拟机的缩写嘛，这些都是拿手戏。
Linux容器里进程的跨机器动态迁移我还没听说，不要说是个服务就得有集群有 HA 嘛，可还真有不少low b用户一个服务就单机顶着呢，就算有热备或者冷备，在线那台机器内存里的东西可宝贵了，轻易不能丢。。。
用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 文件。
也许有人会说 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、内存、本地磁盘都是常年浪费的，而由于 CPU 利用率往往低的又不够降频节能，所以 VM 的额外开销不过是浪费了原本就在浪费的资源罢了。
虽然有 virtio 支持，论单机巅峰 IO 能力，VM 确实不敌容器，但既然平时到不了巅峰，那抱着这个数字傻乐个啥呢？省了多少美刀呢？ 而实际情况恐怕是原本一个 VM 里多进程干的事，非得搞多个容器跑，这容器开销，这人力开销怎么算？
关于容器还有一个幻想，那就是可以在物理机上直接跑容器，开销剧低，管理剧方便，用专用物理机方式提供多租户强隔离，多美！前面两点上面已经驳过了，话说还有人用 openstack 管理 docker 容器呢。 我只是说一下第三点，在一台物理机上直接跑容器的一个容易被忽视的问题：现在用来提供云服务的物理机一般都是硬件超级牛逼，跑上百个容器没问题，但问题在于用户很可能只需要几个容器，所以要么跟人共用物理机，要么浪费资源白交钱。哪怕这个用户需要上百容器，出于容灾考虑，不可以把上百容器部署到一台物理机上，所以还是要么跟人共用物理机，要么浪费资源白交钱。
吐槽太长时间了，简单结尾收工。 听起来我好像是容器黑，但其实我是实用派，AWS、Azure、GCE 都主推在虚拟机上跑容器，按虚拟机收费，这非常明智的解决了问题：老的纯 VM 基础设施不用动，计费照旧，单物理机可以被安全的多租户共用，资源隔离有保证（起码比共享内核强多了），又提供 *容器管理软件* 比如 kubernetes给用户，满足用户的容器需求，又不操心容器的多租户问题。
所以我的结论是类似策略，以 VM 为基础，以容器为辅助甜点，要买就买 VM，自己管理容器，别买 CAAS 直接提供的容器，别看不到底下物理机或者虚拟机。用 VM 还是用容器，冷静考察自己的应用，上容器有多大好处。
最后，残念，VM 开源管理软件能搞个比 OpenStack 简单的东西么。。。
首先要明确的是，软件开发和运维活动中，可维护性、正确性、性能的优先级是依次降低的，不要跟我抬杠少数极端情况。关于可维护性和正确性的先后，著名的 "worse is better" 那篇文章就是很好的无奈的解释，如果你犹豫这两者，这还情有可原，毕竟真善美和糙快猛的斗争从未停歇，而你如果第一反应觉得性能是最重要的，那就不要继续往下看了，洗洗去睡吧。
那么对于虚拟机 vs 容器，自然我们也需要从这三方面考察。
回合一：可维护性之争
- 虚拟机
VM 的动态迁移也是成熟技术，出来好多年了，实现原理从根子上就简单，反正整个 OS 内存一锅端弄过去，不操心少个依赖进程的内存没过去。
想用不同版本内核？ 想要自定义内核模块？想调整内核参数？期望更安全的隔离？期望如同物理机版几乎一致的使用体验？VM 就是虚拟机的缩写嘛，这些都是拿手戏。
- 容器
Linux容器里进程的跨机器动态迁移我还没听说，不要说是个服务就得有集群有 HA 嘛，可还真有不少low b用户一个服务就单机顶着呢，就算有热备或者冷备，在线那台机器内存里的东西可宝贵了，轻易不能丢。。。
用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 文件。
也许有人会说 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、内存、本地磁盘都是常年浪费的，而由于 CPU 利用率往往低的又不够降频节能，所以 VM 的额外开销不过是浪费了原本就在浪费的资源罢了。
虽然有 virtio 支持，论单机巅峰 IO 能力，VM 确实不敌容器，但既然平时到不了巅峰，那抱着这个数字傻乐个啥呢？省了多少美刀呢？ 而实际情况恐怕是原本一个 VM 里多进程干的事，非得搞多个容器跑，这容器开销，这人力开销怎么算？
关于容器还有一个幻想，那就是可以在物理机上直接跑容器，开销剧低，管理剧方便，用专用物理机方式提供多租户强隔离，多美！前面两点上面已经驳过了，话说还有人用 openstack 管理 docker 容器呢。 我只是说一下第三点，在一台物理机上直接跑容器的一个容易被忽视的问题：现在用来提供云服务的物理机一般都是硬件超级牛逼，跑上百个容器没问题，但问题在于用户很可能只需要几个容器，所以要么跟人共用物理机，要么浪费资源白交钱。哪怕这个用户需要上百容器，出于容灾考虑，不可以把上百容器部署到一台物理机上，所以还是要么跟人共用物理机，要么浪费资源白交钱。
吐槽太长时间了，简单结尾收工。 听起来我好像是容器黑，但其实我是实用派，AWS、Azure、GCE 都主推在虚拟机上跑容器，按虚拟机收费，这非常明智的解决了问题：老的纯 VM 基础设施不用动，计费照旧，单物理机可以被安全的多租户共用，资源隔离有保证（起码比共享内核强多了），又提供 *容器管理软件* 比如 kubernetes给用户，满足用户的容器需求，又不操心容器的多租户问题。
所以我的结论是类似策略，以 VM 为基础，以容器为辅助甜点，要买就买 VM，自己管理容器，别买 CAAS 直接提供的容器，别看不到底下物理机或者虚拟机。用 VM 还是用容器，冷静考察自己的应用，上容器有多大好处。
最后，残念，VM 开源管理软件能搞个比 OpenStack 简单的东西么。。。