邱戈川:唯品会“简易”DCOS 实践探讨

aabzw178im 3年前
   <h2>为什么需要容器化平台</h2>    <p>目前唯品会做的是容器化平台,为什么需要这么做呢?主要跟唯品会目前面临的问题有关。</p>    <ol>     <li>整个运维的思路比较简单,在部署方面基本上是单物理机,单进程模式——毕竟是要保持业务的稳定性,这是目前最大的约束。但是公司所有的物理机从机房上架、上电,网络开通等等,整个流程下来消耗非常大。</li>     <li>资源利用率很低,整个体系的物理机CPU利用率平均还不到10%,在四个数据中心却有超过2万台物理机,这个量浪费非常大。</li>     <li>灵活性差,响应慢,我们要换一个硬盘很困难,效率很低、成本很高,这也是我们考虑容器化的一个原因。</li>    </ol>    <p>所以我们现在需要打造我们下一代的管理平台,主要是考虑以下几个因素:</p>    <ol>     <li>能够分时段和分资源的方式使用,这样能够高效地利用资源。</li>     <li>唯品会现在是多数据中心,后面可能要考虑混合的数据中心,我们希望私有云或公有云的接入能做到快速部署、自动部署和严格隔离。</li>     <li>整个电商平台业务模式会因为支持多数据中心、混合数据中心变得非常复杂,不是纯粹的单体的一个网站,后面涉及很多的流程和很多的模块,我们希望把它们有效的混合在一起。</li>    </ol>    <p>当然大家很容易想到今天的主题,单就纯粹加一个Docker是否能完全解决这个问题?最大的问题不是Docker加进来就OK了,除了要用Docker引擎之外,还要考虑怎么做编排。我们需要做到把所有的资源有机的编排在一起,做到弹性伸缩和灵活资源调度。</p>    <h2>Docker容器、容器编排</h2>    <p>现在的容器化平台是个很大的概念,那么我们要从概念模型上去看,我们到底选择什么样的平台,毕竟现在很多企业有很多不同的选择。</p>    <p>简单地讲一下,公有云可能是从虚拟机开始私有云从物理机开始。如果你从物理机开始,一个物理主机拥有多个容器在跑,每个容器会含有单个应用(单进程),每台物理机会运行一组容器,每个容器管理一段IP。容器IP管理是个复杂的问题,后面会说到。</p>    <p><img src="https://simg.open-open.com/show/12caa98b3cedb8ef794b3882ee00c2e8.jpg"></p>    <p><img src="https://simg.open-open.com/show/abd0cfaaae1df1abafddb919badc18d5.jpg"></p>    <p>从选型上来看,我们的容器方案用的是Mesos Marathon,如上图,这个选型的原因是什么?很多情况下大家可能会去选择Kubernetes,大家可以看下二者之间的对比。</p>    <p><img src="https://simg.open-open.com/show/f8c5376b0c0a203e2e9517d39c94c18f.jpg"></p>    <p>因为我们是多数据中心,所以Kubernetes能不能支持还是一个疑问。另外,虽然Google做的东西比较好,但是有一个毛病,就是做到一定的程度就扔掉不管了。我们这么做选择,里面有很多特性的问题,但是现在包括Kubernetes自己在做很多类似的功能性的拓展。Docker自己也在做,Swarm也是选择之一。至于选哪一种呢,就是萝卜青菜,各有所好了,大家自己要做好自己的业务分析。把这几套体系做好选择是不是就够了?实际上你需要考虑的问题不单是这个,容器本身还要考虑的是数据中心的运营,如下图,要考虑的东西包括:</p>    <p><img src="https://simg.open-open.com/show/0559acc9508d92923939f6a46abf4473.jpg"></p>    <p>3.      网络管理和网络模型:网络模型是搭建方案时最大的一个问题,而不只是简单地搭一个容器使用默认的NAT模式,这样整个方案的效率和延迟性是没法接受的。后面我会讲一下唯品会的容器网络模型。</p>    <p>再强调一遍,整个容器化平台是一个体系,不要单纯地选择一个Docker引擎,希望大家做方案的时候一定要考虑清楚体系怎么搭建。</p>    <p><img src="https://simg.open-open.com/show/c337c9c8bae2200c8076cad582fb7601.jpg"></p>    <p>上图是我们目前整个体系的架构,里面我就不细讲了,从下面开始看,首先是整个物理机集群的调度,然后是容器的调度。除此外我们还要有相应的管理体系,包括我们自身还有运维等,每个模块都需要考虑到,可以做简单,也可以做复杂。</p>    <h2>关键技术点</h2>    <p>首先我们看下资源层的模型,也是从物理机器开始,把所有的物理资源后者云主机认为是一个池子,如下图:</p>    <p><img src="https://simg.open-open.com/show/2e267655fc1d1d908cd9dd4c8e8c9b6a.jpg"></p>    <p>在搭建整个物理资源时,每个物理资源每一台服务器会有一个IP段,作为容器的管理,我们要做好相应的网段的管理,要把所有的网络规划做好。</p>    <p><img src="https://simg.open-open.com/show/2d657db140190fbe4a5931ce9798023d.jpg"></p>    <p>对于物理资源,我们用PC的服务器方式做,从管理上讲,会有自己的CMDB的管理体系,根据不同的方式分不同的业务,业务分不同的主机,主机管不同的容器,这个模型比较简单,实际上我们也是这么做的。</p>    <p><img src="https://simg.open-open.com/show/656da3d131a157c0ffbed2f1c3b003a1.jpg"></p>    <p>对于整个网络,目前还是以最简单VLAN的方式做,当然也可以用很多开源的方式做,但是稳定性和可靠性是一个比较大的麻烦。从管理上讲,大二层的网络方案有一定的风险,毕竟整个交换机管VLAN的总数是有限的,包括网络ARP包的量也比较大,但在没有达到大规模的时侯可以先不去考虑,所以我们基本上不需要任何的管理系统,直接用交换机给每台主机分一个段,这里面有另外一个问题,就是整个IP的分配都是由Docker引擎去做。这种方式最大的问题是怎么去分配这个IP,你的IP段分给了Docker引擎之后,如果现在一台主机上有16个IP,但是只有5个容器,那有11个IP是浪费的,但是好处是管理上会非常的简单。</p>    <p><img src="https://simg.open-open.com/show/8f68f9b72be69caa2dbf215ba32aea56.jpg"></p>    <p>镜象机制大家都比较清楚了,我就不讲这个原理了。唯一做的不太一样的地方是我们倾向于单个镜象,单进程;我们不倾向于一个容器里有多进程,如果你有多进程,而你的主进程并不是在启动进程,那很可能在管理上会很复杂,因为其他的进程死掉的时候,Marathon实际上根本不知道。这是我们当时遇到的一个坑,所以我们想了很多办法,应用全部拆成单进程的方式去做管理。</p>    <p><img src="https://simg.open-open.com/show/a23e3c569b50b8d8c90c50dac4e741a2.jpg"></p>    <p>资源的隔离,很多的业务体系希望不同的业务体系只跑那一类的业务,希望它们不要有冲突,你在网站上看到购物车是一个体系,物流是一个体系,另外我们希望可以支持多数据中心。这个都是通过Mesos的分组方式支持。</p>    <p>之前提到的监控实际上是很大的一块,所以整个容器要为整个公司去考虑你的监控体系,去监控容器的CPU、NET、IO。目前唯品会的整个网络层体系是这样的:应用层有自己的监控体系,我们把它叫作Mercury,这是我们自己做的业务层的监控,Mercury是调用链的监控,业务层主要是Telescope。大家需要自己去考虑自己的方案。目前也有不少开源的选择。</p>    <p><img src="https://simg.open-open.com/show/06dd787b65438cbd97a61593dd433fdf.jpg"></p>    <p>唯品会的容器化管理,基本上涵盖几个大块,一个是刚才说的监控,另外就是整个弹性的伸缩,弹性的伸缩这一块,我们目前用比较简单的做法,实际上是通过Jenkins的方式,固定时间把某些应用的容器的实例给缩下来或扩展上去。</p>    <p><img src="https://simg.open-open.com/show/367024429f78406d70a8ec5d8b395f7c.jpg"></p>    <p>整个的部署模型大概是这个样子的,Haproxy我们有两套,一套是管理端,一套是整个应用接入层,这样把体系搭出来,管理机器基本上是在20台到25台主机,管理体系基本上是走物理机的体系,只是应用跑在Docker里面。</p>    <p>除了整个技术体系还有一个是管理体系,包括整个流程的发布和打包,还有持续的集成,都会影响到整个的开发流程,还有整个监控告警的处理、镜像的维护,很多时候,举个例子,假如有一个应用要连数据库,那这个镜像谁可以拿,谁不可以拿,都是管理体系需要考虑的,还有就是整个物理资源的上线回收等。</p>    <h2>唯品会之前遇到过的问题</h2>    <p>简单讲一下我们遇到的一些问题,可能大家以后也会遇到同样的问题。</p>    <ol>     <li>最大的坑,是默认的安装完之后,会造成机器访问时,内存访问到硬盘上,这样整个体系的系统会非常差,这是我们必调的一个,这是第一个坑。</li>     <li>整个Docker集群是一个Vlan的模式,所以我们会把IP段分给Docker引擎,要在启动参数时把这个做出来,要把整个网络上的IP分配规划好。另外就是如果你往容器化走,就建议大家不要走到Linux 6系列,尽可能走到7系列,7系列选择Overlay的容器的存储方式,这个也是整个6系列带来的一些问题,所以你可能还要去考虑整个存储引擎的日志模式,你要把Docker引擎自身的日志,包括容器化日志的输出,用Linux机器本身的Journal方式去做,所以启动参数是有很大的讲究的。另外我们现在的监控体系,后续的日志处理,可能会遇到整个容器的时间跟主机时间实际上在不同的地方,就需要把时区做一个调整。还有整个安装和维护,这里也有一些技巧。</li>     <li>我们的日志文件,是把主机的盘挂给容器,但是这样又会冲突,所以每个容器写盘的时候,会挂容器IP做子目录去写盘。</li>    </ol>    <p>其实我们前面讲那么多,是想把目前的体系尽可能简单化地去做生产的试运行,后续可能会考虑得更加复杂,主要考虑三个:</p>    <p>一个是网络,考虑网络整个模型的话,容器到了一定的量,你的网络模型可能就会重新搭建,目前可选择的有Contiv和Calico。</p>    <p>第二个方式是考虑整个存储,你要考虑存储怎么走,实际上我们目前考虑的分布式存储是Ceph的方式。</p>    <p>第三块是整个的Registry管理,这个我们可能会考虑VMware harbor,之前跟他们开发团队也有过沟通,而且他们现在的版本也更新比较快。</p>    <p>我分享的内容基本上就是这么多。把目前Docker容器化数据中心的概念和模型跟大家讲一讲,里面的每一小块是要花很大的精力去做的。大家在选择时一定要慎重,一定要根据自己的情况选择适合自己的,因为走的是各自不同的技术路线,各自的要求是不一样的。以上是我今天的分享。</p>    <p> </p>    <p>来自:http://jiasuhui.com/archives/97052</p>    <p> </p>