容器化实践的经验分享(2)

在容器化落地的实践过程中,难免会遇到很多坑。其中一个坑是就是graph driver的选择问题。当时使用的CentOS的devicemapper,遇到了内核crash的问题。这个问题在当时比较棘手,我们一开始没能解决,于是我们自己写了一版graph driver,命名为vdisk。这个vdisk主要是通过稀疏文件来模拟union filesystem的效果。这个在实际使用中,会减慢创建速度,但是益处是带来了极高的稳定性,而且不再有dm的data file的预设磁盘容量的限制了。因为容器创建后,还需要启动公司的工具链,运维确认,然后切流量等才能完成上线,所以在实际中,该方式仍然有着极好的效果。

不过我们没有放弃dm,在之后我们也解决了dm带来的内核crash问题,这个可以参见蘑菇街对此的分享记录使用Docker时内核随机crash问题的分析和解决。配置nodiscard虽然解决了内核crash的问题,但是在实际的实践中,又引入了一个新的问题,就是容器磁盘超配的问题。就比如dm的data是一个稀疏问题,容量为10G,现在有5个容器,每个容器磁盘预设空间是2G。但是容器文件实际占用只有1G。这时理论上来说,创建第6个2G的容器是没问题的。但是如果这个5个容器,虽然实际文件只占用1G,但是容器中对于某个大文件进行反复的创建、删除(如redis的aof),则在dm的data中,会实际占用2G的空间。这时创建第6个容器就会因为dm的data空间不足而无法创建。这个问题从dm角度来说不好直接解决,在实际操作中,通过与业务的沟通,将这种频繁读写的文件放置到外挂的volume中,从而解决了这个问题。

从这个坑中,我们也对于后来的业务方做了建议,镜像和根目录尽量只存只读和少量读写的文件,对于频繁读写或大量写的文件,尽量使用外挂的volume。当然,我们对外挂的volume也做了一些容量和写速度的限制,以免业务之间互相影响。规范业务对于容器的使用行为。

docker版本选择

在开始研究docker时,docker的稳定版本还是1.2和1.3。但是随着docker的火热,版本迅速迭代。诚然,新的版本增加了很多的新功能。但是也可能引入了一些新的bug。我们使用docker的基本理念是新技术不一定都步步跟上。更多的是考虑实际情况,版本尽量的稳定。落地是第一要务。而且我们的容器平台1.0更偏向于基础设施层,容器尽量不进行重启和迁移。因为业务混合部署在集群中,当一个宿主机上的docker需要升级,则容器需要迁移,那么可能涉及到多个业务方,要去与各个业务方的运维、研发等进行沟通协调,相当的费时费力。我们在充分测试之后,定制了自己的docker版本,并稳定使用。docker提供的功能足够,尽量不再升级,新增功能我们通过其他的方式进行实现。

监控与巡检

这里所指的监控主要指对资源,如CPU、内存等的监控。如前文中所述,由于容器的隔离性不足,因此容器中使用top等看到的信息,也不完全是容器内的信息,也包含有宿主机的信息。如果用户直接在容器中使用工具获取资源监控信息,容易被这些信息误导,无法准确判断资源的使用情况。因此我们自己研发完成了一套容器平台监控系统,负责容器平台的资源监控,对于物理机和容器的资源使用情况进行采集和整理,统一在前端呈现给用户。并集成了资源告警、历史查询等功能。

由于容器平台系统,包含了多个子系统,以及许多的模块。系统庞大,就涉及到了诸多的配置、状态检查等等。我们对应开发了一套巡检系统,用于巡查一些关键信息等。巡检系统一方面定时巡查,以便核实各个组件的工作状态;另一方面,当出现状况时,使用巡检系统对于定位出现问题的节点,分析问题产生的原因有极多的帮助。

标准化的工具

在没有容器化之前,公司内部逐渐形成了自己的一套工具链,诸如编译打包、自动部署、统一监控等等。这些已经为部署在物理机和虚拟机中的应用提供了稳定的服务。因此在我们的私有云落地实践中,我们尽可能的兼容了公司的工具链,在制作镜像时,将原有的工具链也都打入了镜像中。真正实现了业务的平滑迁移。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/65757efb60567be8be7680047b1cdad6.html