专栏名称: 分布式实验室
最专业的Docker文章,最权威的Docker新闻。关注容器生态圈的发展。
目录
相关文章推荐
51好读  ›  专栏  ›  分布式实验室

美团点评Docker容器管理平台

分布式实验室  · 公众号  · 后端  · 2017-01-26 07:52

正文

本文授权转载自“美团点评技术团队”微信公众号。

美团点评容器平台简介

本文介绍美团点评的Docker容器集群管理平台(以下简称“容器平台”)。该平台始于2015年,是基于美团云的基础架构和组件而开发的Docker容器集群管理平台。目前该平台为美团点评的外卖、酒店、到店、猫眼等十几个事业部提供容器计算服务,承载线上业务数百个,日均线上请求超过45亿次,业务类型涵盖Web、数据库、缓存、消息队列等。

为什么要开发容器管理平台

作为国内大型的O2O互联网公司,美团点评业务发展极为迅速,每天线上发生海量的搜索、推广和在线交易。在容器平台实施之前,美团点评的所有业务都是运行在美团私有云提供的虚拟机之上。随着业务的扩张,除了对线上业务提供极高的稳定性之外,私有云还需要有很高的弹性能力,能够在某个业务高峰时快速创建大量的虚拟机,在业务低峰期将资源回收,分配给其他的业务使用。美团点评大部分的线上业务都是面向消费者和商家的,业务类型多样,弹性的时间、频度也不尽相同,这些都对弹性服务提出了很高的要求。在这一点上,虚拟机已经难以满足需求,主要体现以下两点。

第一,虚拟机弹性能力较弱。使用虚拟机部署业务,在弹性扩容时,需要经过申请虚拟机、创建和部署虚拟机、配置业务环境、启动业务实例这几个步骤。前面的几个步骤属于私有云平台,后面的步骤属于业务工程师。一次扩容需要多部门配合完成,扩容时间以小时计,过程难以实现自动化。如果可以实现自动化“一键快速扩容”,将极大地提高业务弹性效率,释放更多的人力,同时也消除了人工操作导致事故的隐患。

第二,IT成本高。由于虚拟机弹性能力较弱,业务部门为了应对流量高峰和突发流量,普遍采用预留大量机器和服务实例的做法。即先部署好大量的虚拟机或物理机,按照业务高峰时所需资源做预留,一般是非高峰时段资源需求的两倍。资源预留的办法带来非常高的IT成本,在非高峰时段,这些机器资源处于空闲状态,也是巨大的浪费。

由于上述原因,美团点评从2015年开始引入Docker,构建容器集群管理平台,为业务提供高性能的弹性伸缩能力。业界很多公司的做法是采用Docker生态圈的开源组件,例如Kubernetes、Docker Swarm等。我们结合自身的业务需求,基于美团云现有架构和组件,实践出一条自研Docker容器管理平台之路。我们之所以选择自研容器平台,主要出于以下考虑。

快速满足美团点评的多种业务需求

美团点评的业务类型非常广泛,几乎涵盖了互联网公司所有业务类型。每种业务的需求和痛点也不尽相同。例如一些无状态业务(例如Web),对弹性扩容的延迟要求很高;数据库,业务的Master节点,需要极高的可用性,而且还有在线调整CPU,内存和磁盘等配置的需求。很多业务需要SSH登陆访问容器以便调优或者快速定位故障原因,这需要容器管理平台提供便捷的调试功能。为了满足不同业务部门的多种需求,容器平台需要大量的迭代开发工作。基于我们所熟悉的现有平台和工具,可以做到“多快好省”地实现开发目标,满足业务的多种需求。

从容器平台稳定性出发,需要对平台和Docker底层技术有更高的把控能力

容器平台承载美团点评大量的线上业务,线上业务对SLA可用性要求非常高,一般要达到99.99%,因此容器平台的稳定性和可靠性是最重要的指标。如果直接引入外界开源组件,我们将面临3个难题:1. 我们需要摸熟开源组件,掌握其接口、评估其性能,至少要达到源码级的理解;2. 构建容器平台,需要对这些开源组件做拼接,从系统层面不断地调优性能瓶颈,消除单点隐患等;3. 在监控、服务治理等方面要和美团点评现有的基础设施整合。这些工作都需要极大的工作量,更重要的是,这样搭建的平台,在短时间内其稳定性和可用性都难以保障。

避免重复建设私有云

美团私有云承载着美团点评所有的在线业务,是国内规模最大的私有云平台之一。经过几年的经营,可靠性经过了公司海量业务的考验。我们不能因为要支持容器,就将成熟稳定的私有云搁置一旁,另起炉灶再重新开发一个新的容器平台。因此从稳定性、成本考虑,基于现有的私有云来建设容器管理平台,对我们来说是最经济的方案。

美团点评容器管理平台架构设计

我们将容器管理平台视作一种云计算模式,云计算的架构同样适用于容器。如前所述,容器平台的架构依托于美团私有云现有架构,其中私有云的大部分组件可以直接复用或者经过少量扩展开发。容器平台架构如下图所示。

可以看出,容器平台整体架构自上而下分为业务层、PaaS层、IaaS控制层及宿主机资源层,这与美团云架构基本一致。

业务层 :代表美团点评使用容器的业务线,他们是容器平台的最终用户。

PaaS层 :使用容器平台的HTTP API,完成容器的编排、部署、弹性伸缩,监控、服务治理等功能,对上面的业务层通过HTTP API或者Web的方式提供服务。

IaaS控制层 :提供容器平台的API处理、调度、网络、用户鉴权、镜像仓库等管理功能,对PaaS提供HTTP API接口。

宿主机资源层 :Docker宿主机集群,由多个机房,数百个节点组成。每个节点部署HostServer、Docker、监控数据采集模块,Volume管理模块,OVS网络管理模块,Cgroup管理模块等。

容器平台中的绝大部分组件是基于美团私有云已有组件扩展开发的,例如API,镜像仓库、平台控制器、HostServer、网络管理模块,下面将分别介绍。

API

API是容器平台对外提供服务的接口,PaaS层通过API来创建、部署云主机。我们将容器和虚拟机看作两种不同的虚拟化计算模型,可以用统一的API来管理。即虚拟机等同于set(后面将详细介绍),磁盘等同于容器。这个思路有两点好处:1. 业务用户不需要改变云主机的使用逻辑,原来基于虚拟机的业务管理流程同样适用于容器,因此可以无缝地将业务从虚拟机迁移到容器之上;2. 容器平台API不必重新开发,可以复用美团私有云的API处理流程。

创建虚拟机流程较多,一般需要经历调度、准备磁盘、部署配置、启动等多个阶段,平台控制器和Host-SRV之间需要很多的交互过程,带来了一定量的延迟。容器相对简单许多,只需要调度、部署启动两个阶段。因此我们对容器的API做了简化,将准备磁盘、部署配置和启动整合成一步完成,经简化后容器的创建和启动延迟不到3秒钟,基本达到了Docker的启动性能。

Host-SRV

Host-SRV是宿主机上的容器进程管理器,负责容器镜像拉取、容器磁盘空间管理、以及容器创建、销毁等运行时的管理工作。

镜像拉取 :Host-SRV接到控制器下发的创建请求后,从镜像仓库下载镜像、缓存,然后通过Docker Load接口加载到Docker里。

容器运行时管理 :Host-SRV通过本地Unix Socker接口与Docker Daemon通信,对容器生命周期的控制,并支持容器Logs、exec等功能。

容器磁盘空间管理 :同时管理容器Rootfs和Volume的磁盘空间,并向控制器上报磁盘使用量,调度器可依据使用量决定容器的调度策略。

Host-SRV和Docker Daemon通过Unix Socket通信,容器进程由Docker-Containerd托管,所以Host-SRV的升级发布不会影响本地容器的运行。

镜像仓库

容器平台有两个镜像仓库:

镜像仓库不仅是容器平台的必要组件,也是私有云的必要组件。美团私有云使用Glance作为镜像仓库,在建设容器平台之前,Glance只用来托管虚拟机镜像。每个镜像有一个UUID,使用Glance API和镜像UUID,可以上传、下载虚拟机镜像。Docker镜像实际上是由一组子镜像组成,每个子镜像有独立的ID,并带有一个Parent ID属性,指向其父镜像。我们稍加改造了一下Glance,对每个Glance镜像增加Parent ID的属性,修改了镜像上传和下载的逻辑。经过简单扩展,使Glance具有托管Docker镜像的能力。通过Glance扩展来支持Docker镜像有以下优点:

可能有人疑问,用Glance做镜像仓库是“重新造轮子”。事实上我们对Glance的改造只有200行左右的代码。Glance简单可靠,我们在很短的时间就完成了镜像仓库的开发上线,目前美团点评已经托管超过16,000多个业务方的Docker镜像,平均上传和下载镜像的延迟都是秒级的。

高性能、高弹性的容器网络

网络是十分重要的,又有技术挑战性的领域。一个好的网络架构,需要有高网络传输性能、高弹性、多租户隔离、支持软件定义网络配置等多方面的能力。早期Docker提供的网络方案比较简单,只有None、Bridge、Container和Host这四种网络模式,也没有用户开发接口。2015年Docker在1.9版本集成了Libnetwork作为其网络的解决方案,支持用户根据自身需求,开发相应的网络驱动,实现网络功能自定义的功能,极大地增强了Docker的网络扩展能力。

从容器集群系统来看,只有单宿主机的网络接入是远远不够的,网络还需要提供跨宿主机、机架和机房的能力。从这个需求来看,Docker和虚拟机来说是共通的,没有明显的差异,从理论上也可以用同一套网络架构来满足Docker和虚拟机的网络需求。基于这种理念,容器平台在网络方面复用了美团云网络基础架构和组件。

数据平面 :我们采用万兆网卡,结合OVS-DPDK方案,并进一步优化单流的转发性能,将几个CPU核绑定给OVS-DPDK转发使用,只需要少量的计算资源即可提供万兆的数据转发能力。OVS-DPDK和容器所使用的CPU完全隔离,因此也不影响用户的计算资源。

控制平面 :我们使用OVS方案。该方案是在每个宿主机上部署一个自研的软件Controller,动态接收网络服务下发的网络规则,并将规则进一步下发至OVS流表,决定是否对某网络流放行。

MosBridge

在MosBridge之前,我们配置容器网络使用的是None模式。所谓None模式也就是自定义网络的模式,配置网络需要如下几步:

  1. 在创建容器时指定—net=None,容器创建启动后没有网络;

  2. 容器启动后,创建eth-pair;

  3. 将eth-pair一端连接到OVS Bridge上;

  4. 使用nsenter这种Namespace工具将eth-pair另一端放到容器的网络Namespace中,然后改名、配置IP地址和路由。

然而,在实践中,我们发现None模式存在一些不足:

为了解决这些问题,我们将眼光投向Docker Libnetwork。Libnetwork为用户提供了可以开发Docker网络的能力,允许用户基于Libnetwork实现网络驱动来自定义其网络配置的行为。就是说,用户可以编写驱动,让Docker按照指定的参数为容器配置IP、网关和路由。基于Libnetwork,我们开发了MosBridge – 适配美团云网络架构的Docker网络驱动。在创建容器时,需要指定容器创建参数—net=mosbridge,并将IP地址、网关、OVS Bridge等参数传给Docker,由MosBridge完成网络的配置过程。有了MosBridge,容器创建启动后便有了网络可以使用。容器的网络配置也持久化在MosBridge中,容器重启后网络配置也不会丢失。更重要的是,MosBridge使Host-SRV和Docker充分解耦,以后网络功能的升级也会更加方便。

解决Docker存储隔离性的问题







请到「今天看啥」查看全文