这些年，伴随着微服务的发展以及k8s的兴起，各种各样的容器平台开始进入大家的视线并且越来越多的金融行业也开始尝试使用容器平台来部署自己的应用程序。容器相比于虚拟机具有以下几个显著优点。在基础设施层面：一是启动速度快，相比于虚拟机的分钟级启动，容器只需要秒级就可以启动；二是资源保证率高，容器更容易实现cpu的亲和性设置，从而保证关键应用的计算能力；三是容器平台一般都可以实现服务容器的自动缩容和扩容，从而提高运维效率。在应用层面：一是容器的轻量化是加速微服务落地的天然助推剂；二是容器基于镜像的发布方式能够屏蔽开发、测试和生产环境的环境参数差异；三是容器的轻量特性也有助于敏捷的开发模式。
在8月31日的线上交流活动中，围绕着企业级应用容器化部署实践经验及平台建设等进行了问题的讨论，也得到了各位专家的支持，大家针对容器的相关问题体现出了非常大的热情，在此也对相关问题及大家的观点总结如下：

一、容器、虚拟机、微服务等各种概念之间的区别

典型问题：

Q1：PCF与容器云的区别？

A1:

这个问题是两个不同层面的概念，后者包含的范围更大。容器云是基于容器打造的云环境可以包含iaas、paas和saas等，而pcf就是paas层。如果硬要扣字眼，就要说到底什么算是云了，这个就没有一个很严格的区分了，一般而言，凡是能够提供按需供给能力并且可以弹性伸缩的都可以称为云。从这个层面讲，pcf就是paas云平台。

Q2：容器与微服务的关系是什么？

A2:

现在一提到微服务，有很多人会想到容器技术（这里说到的容器技术是指docker）。那么微服务和容器之间到底有什么关系呢，我来简要和大家探讨下。先抛出结论：微服务和容器其实没有半毛钱关系。微服务理念出现的比容器技术要早很多，其理念是在70年代提出的。而容器技术是2013年才提出的，它最初是由一个叫做dotcloud的项目发展而来，后来改名叫做docker。基于微服务的思想开发应用程序是完全可以不用容器技术的，例如现在很流行的spring cloud和dubbo都是可以不使用容器技术来做开发实现的。从2017年开始很多人喜欢同时提到微服务和容器化，这主要是基于以下几个原因：（1）按照微服务的理念，如果使用容器作为基础设施，能够实现快速部署，快速迭代；（2）在云计算浪潮中，容器作为替代vm的基础设施受到大家的关注度更高；（3）k8s作为几乎实际默认的容器化平台标准，其集成了配置中心和注册中心，相当于天然的帮微服务架构解决了自己开发配置中心和注册中心的问题。在我看来，以上三个是促使在2017年度很多时候，大家会将微服务和容器技术一起谈论的重要原因，甚至有些公司直接将自己的新建的微服务应用部署在容器平台上。

Q3：容器、虚拟机和物理机的关系是什么？

A3：

这个问题问的很大，而且度娘也可以查到很多这方面的解释。我这里从最本质最容易理解的角度做下对比说明。第一，虚拟机是基于物理机的，虚拟机创建出来以后是包含完整的操作系统内核的，这个内核和物理机的内核是完全独立的；第二，容器可以部署在虚拟机上，也可以部署在物理机上；第三，容器是共享宿主机（虚拟机或者物理机）内核的，即在一个宿主机上的容器其内核是共享的；第四，容器是基于namsepace、cgroup、chroot和xxxfs（例如aufs）；第五，容器在os的表象上就是一个os的进程，通过 ps -aufxww可以清晰的看出继承关系。

二、容器平台的选择方面

典型问题：

Q1：目前有哪些比较成熟的k8s商业产品可以推荐？

A1：

商用的k8s产品有很多，笔者也没有全部都适用过，关于平台的选择，更多的还是要结合本公司的具体情况和与产品的真实使用方进行线下交流来做出判断。

Q2：容器云平台选型时应该注意和考虑哪些方面？

A2：

第一，容器云平台在选型的时候，需要结合公司的实际需求，看看哪一家的产品最能解决自己的问题；第二，对于圈定的几家产品，通过线下的方式了解其客户的真实使用情况，而不要听商家的一面之言；第三，如果计划将容器用于生产环境，那么有两个技术要点需要特别注意和评审：一是容器的网络技术方案，主要是要看提供的方案是否是扁平的网络，以及网络效率问题；二是容器的存储方案，平台提供的存储方案能否保证数据安全以及数据存储的高效；三是容器平台能否做到io隔离，这个需求对于并发压力比较大的系统（主要指io密集型）还是非常重要的。第四，平台厂商的合作态度。

Q3：如何结合公司实际情况，部署容器平台？

A3：

第一，梳理出公司的实际需求，评估哪家的产品最能解决自己的问题；第二，对于圈定的几家产品，通过线下的方式了解其客户的真实使用情况，而不要听商家的一面之言；第三，如果计划将容器用于生产环境，那么有两个技术要点需要特别注意和评审：一是容器的网络技术方案，主要是要看提供的方案是否是扁平的网络，以及网络效率问题；二是容器的存储方案，平台提供的存储方案能否保证数据安全以及数据存储的高效；三是容器平台能否做到io隔离，这个需求对于并发压力比较大的系统（主要指io密集型）还是非常重要的。第四，平台厂商的合作态度,评估厂商是否愿意一起投入力量，解决问题。第五，还要考虑公司现有的监控平台如何与容器平台的监控进行结合。

Q4：容器部署在虚拟机上还是物理机上？怎么进行选择？

A4：

目前商用容器平台在进行推广的过程中，一般都是支持部署在物理机和虚拟机上的，并且两者收费的价格也是不同的。在这个问题上，如果公司是刚开始使用容器化平台，规模不大（原先30-50台虚拟机化宿主机的规模），并且并没有计划在半年到一年内将容器化应用到生产环境，那么对于这样的情况，建议部署在虚拟机上即可。对于计划将容器用于生产环境，并且计划跑高io业务，网络延迟要求较高的场景，根据笔者经验，建议使用物理机，并且必须配置ssd盘，哪怕是sata接口的ssd盘也是可以，不然应用的延迟会很高，严重影响应用的使用.

三、什么样的应用适合采用容器部署

典型问题：

Q1：应用是否都适合做容器化部署？什么样的应用适合容器化部署？

A1:

并不是所有的应用程序都适合容器化部署，在笔者看来以下几类应用比较适合容器化部署：一是功能单一的应用，即微服务（这也是为什么现在大家一谈到微服务就会谈到容器，一谈到容器就会谈到微服务的原因）；二是无状态的应用，容器的一个最大的优点就是可以快速创建（秒级），对于无状态的应用，可以通过快速横向扩容来提升并发处理能力；三是变更频繁的应用，容器是基于镜像创建的，对于变更频繁的应用，只要能保证镜像在测试环境测试没有问题，那么在生产环境上线由于环境差异导致出问题的概率就会少的多；四是对于需要在一个站点快速部署的应用组，对于需要在一个新站点快速部署的应用组，使用容器技术能够结合容器平台自身的特性，快速创建一个新的站点。

Q2：websphere和DB2架构的应用适合用k8s吗？

A2:

不太适合，容器属于轻量级平台，其设计的初衷就是为了能够快速创建和快速销毁，对于was而言还好，不过其镜像比较重，同时配置也复杂，建议更换为tomcat；db2就更不适合了，容器本身具有易销毁和无状态的特性，当然bat大厂也做了数据库的容器化，不过那些也是基于mysql这种轻量级的数据库，另外db2是否有镜像支持都是一个疑问。。。。 另外was和db2这种重量级的组件部署在容器中有什么好处呢？或者说为什么会有这样的想法？这样部署完全不能利用容器的特性，意义不大又引入了额外的维护成本。胖容器，重平台都不是容器推崇的应用场景。k8s+db2+was这样简单的组合也做不了应用双活，应用双活是需要应用程序层面一起处理的，不单单是平台层面能解决的。

四、容器监控方面

典型问题：

Q1：应用容器化场景下，如何做好监控？

A1：

首先，现在的容器平台自身都提供对平台自身状态的监控，这个可以和已有的监控平台进行对接使用；其次，在应用容器化的场景下，监控就显得更加重要了，相比于传统的烟囱式架构，完成一项业务流程需要涉及多个容器（容器和微服务改造一般都是同时发生的），而且这些容器又可能是新增或者有发生扩容的。那么当一笔业务发生问题的时候，需要快速定位是哪个节点出了问题，这就需要分布式链路跟踪上场了。在容器大量使用的场景下，监控就是眼睛，在应用进行上线、变更和弹性扩容的时候需要实时感知应用的健康状态，主要包括可用率（正常情况这个指标需要是100%）、响应时间等，以便采取相应的措施来保证不影响用户体验。在云平台上，应用变更（包括版本更新和扩容）的正确姿势应该是一边做变更，一边看监控大盘，看每个动作对当前应用可用率的影响，看着监控做变更是一种好习惯。最后，在ai日益火爆的趋势下，可以留意市面上的aiops工具，看能否引入到我们的容器平台中。

Q2:容器内部JVM的监控有没有什么比较好的实践可以分享下？

A2：

单从技术角度看容器jvm监控和其他情形的jvm监控没有本质区别，因为其本质都是os上的一个jvm进程，一般都是可以通过javaagent或者jmx的方式来进行监控，然后将监控信息统一收集起来进行处理即可。如果是基于容器搭建微服务平台，拆分了很多微服务，那么这里更应该关注的是在众多微服务应用存在时，访问路径，以及各个节点的处理时限，这是对故障处理有宜的，例如阿里巴巴的鹰眼系统，或者基于开源的zikpin去进行二次开发从而来实现微服务链路上的监控。

Q3:容器和其他资源池的统一监控管理产品？

A3：

云管平台，目前做云管平台的公司还是挺多的可以了解一下。

五、容器行业应用

典型问题：

Q1：容器在金融行业的应用？

A1：

现在金融行业很多都开始使用容器了，主要应用在互联网业务场景方面，用来解决配合微服务进行的敏捷开发工作，可靠性取决于所选的平台以及对业务的容错需求，但就总体而言，容器的稳定性不是其主要的卖点，容器的初衷就是允许快速销毁和快速创建，因此业务系统也需要做相应的改造，例如无状态的改造。

Q2：大数据分析平台是否可以构建到容器云上？目前有没有这方面的案例？

A2：

大数据平台可以构建在容器云上，蚂蚁金服和淘宝的大数据平台都是部署在容器平台上，并且经历了双11的考验。

六、其他

典型问题：

Q1：虚拟机的网络 容器网络和物理机网络如何互联互通？

A1：

不同的容器网络方案的具体实现不同，这是一块非常大的话题，但其本质是一样的。简而言之，容器会生成一块虚拟网卡，将这个虚拟网卡与一个虚拟机交换机（目前使用较多的是ovs）或者虚拟网桥相连，虚拟交换机再与宿主机（虚拟机或者物理机）的网卡联通，通过宿主机的网卡与其他宿主机上的容器进行通讯（虚拟机到物理机的数据包也是通过虚拟机的虚拟网卡与物理机的物理网卡进行交互）。linux系统中一切皆文件，其实每个不同类型的网卡不过是一个个有着特殊结构的文件，数据的交互都是通过对这些文件的读写进行。

Q2：docker基于主机系统层面，在安全方面，应该怎么做?有没有什么成熟的安全配置方案？

A2：

但就docker本身而言，本质就是一个linux的系统进程，可以参考进程安全管理的一些经验。docker层面，自身也带有认证模块和权限模块来进行安全保证。在主机层面，要严格限制root用户的使用，因为通过root用户可以对docker最关键的chroot、cgroup、namespace进行修改，直接影响docker的稳定性。docker镜像访问方面，建议配置证书的方式，同时对镜像中心的镜像进行定期清理。docker容器在创建的时候一定要指定cpu、内存、io的使用，以防一个容器将整个宿主机的资源跑满。

Q3:容器的容灾要怎么做？

A3：

虽然目前的商用容器平台都可以做到容器crash后自动创建新的容器，这个过程中应用还是会多多少少受一些影响，所以一般情况下我们还是不希望因为容器crash掉而对应用有太大影响。为了做到上述这点需要做以下几种容灾：机器级别的容灾，即同一个应用的互备容器不要部署在同一台机器上；机柜级别的容灾，同一个应用的互备容器不要部署在同一个机柜的机器上，要实现这一点其实很简单，只需要用到容器的标签和互斥能力就可以了。