有关容器的六大误区和八大正确场景.docx

? ? ? ? ? ? ? ? 有关容器的六大误区和八大正确场景 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 做容器的研究和容器化几年了，从最初对于容器的初步认识，到积攒了大量的容器迁移经验，并和客户解释了容器技术之后，发现原来对于容器的理解有大量的误解，而且容器并非虚拟机的替代，而是有十分具体的应用场景的。 ? 第一部分：容器的理解误区 ? 误区一：容器启动速度快，秒级启动 ? 这是很多人布道容器的时候经常说的一句话，往往人们会启动一个nginx之类的应用，的确很快就能够启动起来了。 ? 容器为啥启动快，一是没有内核，二是镜像比较小。 ? 然而容器是有主进程的，也即Entrypoint，只有主进程完全启动起来了，容器才算真正的启动起来，一个比喻是容器更像人的衣服，人站起来了，衣服才站起来，人躺下了，衣服也躺下了。衣服有一定的隔离性，但是隔离性没那么好。衣服没有根(内核)，但是衣服可以随着人到处走。 ? 所以按照一个nginx来评判一个容器的启动速度有意义么？对于Java应用，里面安装的是tomcat，而tomcat的启动，加载war，并且真正的应用启动起来，如果你盯着tomcat的日志看的话，还是需要一些时间的，根本不是秒级。如果应用启动起来要一两分钟，仅仅谈容器的秒级启动是没有意义的。 ? 现在OpenStack中的VM的启动速度也优化的越来越快了，启动一个VM的时候，原来需要从Glance下载虚拟机镜像，后来有了一个技术，是的Glance和系统盘共享Ceph存储的情况下，虚拟机镜像无需下载，启动速度就快很多。 ? 而且容器之所以启动速度快，往往建议使用一个非常小的镜像，例如alpine，里面很多东西都裁剪掉了，启动的速度就更快了。 ? OpenStack的虚拟机镜像也可以经过大量的裁剪，实现快速的启动 ? 我们可以精细的衡量虚拟机启动的每一个步骤，裁剪掉相应的模块和启动的过程，大大降低虚拟机的启动时间。 ? 例如在UnitedStack的一篇博客里面: /blog/build-block-storage-service，我们可以看到这样的实现和描述 ? ? “使用原生的OpenStack创建虚拟机需要1~3分钟，而使用改造后的OpenStack仅需要不到10秒钟时间。这是因为nova-compute不再需要通过HTTP下载整个镜像，虚拟机可以通过直接读取Ceph中的镜像数据进行启动。” ? 所以对于虚拟机的整体启动时间，现在优化的不错的情况下，一般能够做到十几秒到半分钟以内。这个时间和Tomcat的启动时间相比较，其实不算是负担，和容器的启动速度相比，没有质的差别，可能有人会说启动速度快一点也是快，尤其是对于在线环境的挂掉自修复来讲，不是分秒必争么？关于自修复的问题，我们下面另外说。 ? 然而虚拟机有一个好处，就是隔离性好，如果容器是衣服，虚拟机就是房子，房子立在那里，里面的人无论站着还是躺着，房子总是站着的，房子也不会跟着人走。使用虚拟机就像人们住在公寓里面一样，每人一间，互补干扰，使用容器像大家穿着衣服挤在公交车里面，看似隔离，谁把公交弄坏了，谁都走不了。 ? 综上所述，容器的启动速度不足以构成对OpenStack虚拟机的明显优势，然而虚拟机的隔离性，则秒杀容器。 ? 误区二：容器轻量级，每个主机会运行成百上千个容器 ? 很多人会做实验，甚至会跟客户说，容器平台多么多么牛，你看我们一台机器上可以运行成百上千个容器，虚拟机根本做不到这一点。 ? 但是一个机器运行成百上千个容器，有这种真实的应用场景么？对于容器来讲，重要的是里面的应用，应用的核心在于稳定性和高并发支撑，而不在于密度。 ? 我在很多演讲的会议上遇到了很多知名的处理双十一和618的讲师，普遍反馈当前的Java应用基本上4核8G是标配，如果遇见容量不足的情况，少部分通过纵向扩容的方式进行，大部分采用横向扩容的方式进行。 ? 如果4核8G是标配，不到20个服务就可以占满一台物理服务器，一台机器跑成百上千个nginx有意思么？ 这不是一个严肃的使用场景。 ? 当然现在有一个很火的Serverless无服务架构，在无服务器架构中，所有自定义代码作为孤立的、独立的、常常细粒度的函数来编写和执行，这些函数在例如AWS Lambda之类的无状态计算服务中运行。这些计算服务可以是虚拟机，也可以是容器。对于无状态的函数来讲，需要快速的创建可删除，而且很可能执行一个函数的时间本身就非常短，在这种情况下容器相比于虚拟机还是有一定优势的。 ? ? 目前无服务架构比较适用于运行一些任务型批量操作，利用进程级别的横向弹性能力来抵消进程创建和销毁带来的较大的代价。 ? 在spark和mesos的集成中，有一个Fine-Grained模式，同通常