本文是鄭坤根據(jù)第14期美團點評技術(shù)沙龍“你不知道的美團云”演講內(nèi)容整理而成，已發(fā)表在《程序員》雜志2017年1月刊。

美團點評容器平臺簡介

本文介紹美團點評的Docker容器集群管理平臺（以下簡稱“容器平臺”）。該平臺始于2015年，是基于美團云的基礎(chǔ)架構(gòu)和組件而開發(fā)的Docker容器集群管理平臺。目前該平臺為美團點評的外賣、酒店、到店、貓眼等十幾個事業(yè)部提供容器計算服務(wù)，承載線上業(yè)務(wù)數(shù)百個，日均線上請求超過45億次，業(yè)務(wù)類型涵蓋Web、數(shù)據(jù)庫、緩存、消息隊列等。

為什么要開發(fā)容器管理平臺

作為國內(nèi)大型的O2O互聯(lián)網(wǎng)公司，美團點評業(yè)務(wù)發(fā)展極為迅速，每天線上發(fā)生海量的搜索、推廣和在線交易。在容器平臺實施之前，美團點評的所有業(yè)務(wù)都是運行在美團私有云提供的虛擬機之上。隨著業(yè)務(wù)的擴張，除了對線上業(yè)務(wù)提供極高的穩(wěn)定性之外，私有云還需要有很高的彈性能力，能夠在某個業(yè)務(wù)高峰時快速創(chuàng)建大量的虛擬機，在業(yè)務(wù)低峰期將資源回收，分配給其他的業(yè)務(wù)使用。美團點評大部分的線上業(yè)務(wù)都是面向消費者和商家的，業(yè)務(wù)類型多樣，彈性的時間、頻度也不盡相同，這些都對彈性服務(wù)提出了很高的要求。在這一點上，虛擬機已經(jīng)難以滿足需求，主要體現(xiàn)以下兩點。

第一，虛擬機彈性能力較弱。使用虛擬機部署業(yè)務(wù)，在彈性擴容時，需要經(jīng)過申請?zhí)摂M機、創(chuàng)建和部署虛擬機、配置業(yè)務(wù)環(huán)境、啟動業(yè)務(wù)實例這幾個步驟。前面的幾個步驟屬于私有云平臺，后面的步驟屬于業(yè)務(wù)工程師。一次擴容需要多部門配合完成，擴容時間以小時計，過程難以實現(xiàn)自動化。如果可以實現(xiàn)自動化“一鍵快速擴容”，將極大地提高業(yè)務(wù)彈性效率，釋放更多的人力，同時也消除了人工操作導(dǎo)致事故的隱患。

第二，IT成本高。由于虛擬機彈性能力較弱，業(yè)務(wù)部門為了應(yīng)對流量高峰和突發(fā)流量，普遍采用預(yù)留大量機器和服務(wù)實例的做法。即先部署好大量的虛擬機或物理機，按照業(yè)務(wù)高峰時所需資源做預(yù)留，一般是非高峰時段資源需求的兩倍。資源預(yù)留的辦法帶來非常高的IT成本，在非高峰時段，這些機器資源處于空閑狀態(tài)，也是巨大的浪費。

由于上述原因，美團點評從2015年開始引入Docker，構(gòu)建容器集群管理平臺，為業(yè)務(wù)提供高性能的彈性伸縮能力。業(yè)界很多公司的做法是采用Docker生態(tài)圈的開源組件，例如Kubernetes、Docker Swarm等。我們結(jié)合自身的業(yè)務(wù)需求，基于美團云現(xiàn)有架構(gòu)和組件，實踐出一條自研Docker容器管理平臺之路。我們之所以選擇自研容器平臺，主要出于以下考慮。

快速滿足美團點評的多種業(yè)務(wù)需求

美團點評的業(yè)務(wù)類型非常廣泛，幾乎涵蓋了互聯(lián)網(wǎng)公司所有業(yè)務(wù)類型。每種業(yè)務(wù)的需求和痛點也不盡相同。例如一些無狀態(tài)業(yè)務(wù)（例如Web），對彈性擴容的延遲要求很高；數(shù)據(jù)庫，業(yè)務(wù)的master節(jié)點，需要極高的可用性，而且還有在線調(diào)整CPU，內(nèi)存和磁盤等配置的需求。很多業(yè)務(wù)需要SSH登陸訪問容器以便調(diào)優(yōu)或者快速定位故障原因，這需要容器管理平臺提供便捷的調(diào)試功能。為了滿足不同業(yè)務(wù)部門的多種需求，容器平臺需要大量的迭代開發(fā)工作。基于我們所熟悉的現(xiàn)有平臺和工具，可以做到“多快好省”地實現(xiàn)開發(fā)目標，滿足業(yè)務(wù)的多種需求。

從容器平臺穩(wěn)定性出發(fā)，需要對平臺和Docker底層技術(shù)有更高的把控能力

容器平臺承載美團點評大量的線上業(yè)務(wù)，線上業(yè)務(wù)對SLA可用性要求非常高，一般要達到99.99%，因此容器平臺的穩(wěn)定性和可靠性是最重要的指標。如果直接引入外界開源組件，我們將面臨3個難題：1. 我們需要摸熟開源組件，掌握其接口、評估其性能，至少要達到源碼級的理解；2. 構(gòu)建容器平臺，需要對這些開源組件做拼接，從系統(tǒng)層面不斷地調(diào)優(yōu)性能瓶頸，消除單點隱患等；3. 在監(jiān)控、服務(wù)治理等方面要和美團點評現(xiàn)有的基礎(chǔ)設(shè)施整合。這些工作都需要極大的工作量，更重要的是，這樣搭建的平臺，在短時間內(nèi)其穩(wěn)定性和可用性都難以保障。

避免重復(fù)建設(shè)私有云

美團私有云承載著美團點評所有的在線業(yè)務(wù)，是國內(nèi)規(guī)模最大的私有云平臺之一。經(jīng)過幾年的經(jīng)營，可靠性經(jīng)過了公司海量業(yè)務(wù)的考驗。我們不能因為要支持容器，就將成熟穩(wěn)定的私有云擱置一旁，另起爐灶再重新開發(fā)一個新的容器平臺。因此從穩(wěn)定性、成本考慮，基于現(xiàn)有的私有云來建設(shè)容器管理平臺，對我們來說是最經(jīng)濟的方案。

美團點評容器管理平臺架構(gòu)設(shè)計

我們將容器管理平臺視作一種云計算模式，云計算的架構(gòu)同樣適用于容器。如前所述，容器平臺的架構(gòu)依托于美團私有云現(xiàn)有架構(gòu)，其中私有云的大部分組件可以直接復(fù)用或者經(jīng)過少量擴展開發(fā)。容器平臺架構(gòu)如下圖所示。

美團點評容器管理平臺架構(gòu)

可以看出，容器平臺整體架構(gòu)自上而下分為業(yè)務(wù)層、PaaS層、IaaS控制層及宿主機資源層，這與美團云架構(gòu)基本一致。

業(yè)務(wù)層：代表美團點評使用容器的業(yè)務(wù)線，他們是容器平臺的最終用戶。 PaaS層：使用容器平臺的HTTP API，完成容器的編排、部署、彈性伸縮，監(jiān)控、服務(wù)治理等功能，對上面的業(yè)務(wù)層通過HTTP API或者Web的方式提供服務(wù)。 IaaS控制層：提供容器平臺的API處理、調(diào)度、網(wǎng)絡(luò)、用戶鑒權(quán)、鏡像倉庫等管理功能，對PaaS提供HTTP API接口。 宿主機資源層：Docker宿主機集群，由多個機房，數(shù)百個節(jié)點組成。每個節(jié)點部署HostServer、Docker、監(jiān)控數(shù)據(jù)采集模塊，Volume管理模塊，OVS網(wǎng)絡(luò)管理模塊，Cgroup管理模塊等。 容器平臺中的絕大部分組件是基于美團私有云已有組件擴展開發(fā)的，例如API，鏡像倉庫、平臺控制器、HostServer、網(wǎng)絡(luò)管理模塊，下面將分別介紹。

API

API是容器平臺對外提供服務(wù)的接口，PaaS層通過API來創(chuàng)建、部署云主機。我們將容器和虛擬機看作兩種不同的虛擬化計算模型，可以用統(tǒng)一的API來管理。即虛擬機等同于set（后面將詳細介紹），磁盤等同于容器。這個思路有兩點好處：1. 業(yè)務(wù)用戶不需要改變云主機的使用邏輯，原來基于虛擬機的業(yè)務(wù)管理流程同樣適用于容器，因此可以無縫地將業(yè)務(wù)從虛擬機遷移到容器之上；2. 容器平臺API不必重新開發(fā)，可以復(fù)用美團私有云的API處理流程 創(chuàng)建虛擬機流程較多，一般需要經(jīng)歷調(diào)度、準備磁盤、部署配置、啟動等多個階段，平臺控制器和Host-SRV之間需要很多的交互過程，帶來了一定量的延遲。容器相對簡單許多，只需要調(diào)度、部署啟動兩個階段。因此我們對容器的API做了簡化，將準備磁盤、部署配置和啟動整合成一步完成，經(jīng)簡化后容器的創(chuàng)建和啟動延遲不到3秒鐘，基本達到了Docker的啟動性能。

Host-SRV

Host-SRV是宿主機上的容器進程管理器，負責容器鏡像拉取、容器磁盤空間管理、以及容器創(chuàng)建、銷毀等運行時的管理工作。

鏡像拉取：Host-SRV接到控制器下發(fā)的創(chuàng)建請求后，從鏡像倉庫下載鏡像、緩存，然后通過Docker Load接口加載到Docker里。

容器運行時管理：Host-SRV通過本地Unix Socker接口與Docker Daemon通信，對容器生命周期的控制，并支持容器Logs、exec等功能。

容器磁盤空間管理：同時管理容器Rootfs和Volume的磁盤空間，并向控制器上報磁盤使用量，調(diào)度器可依據(jù)使用量決定容器的調(diào)度策略。

Host-SRV和Docker Daemon通過Unix Socket通信，容器進程由Docker-Containerd托管，所以Host-SRV的升級發(fā)布不會影響本地容器的運行。

鏡像倉庫

容器平臺有兩個鏡像倉庫： - Docker Registry: 提供Docker Hub的Mirror功能，加速鏡像下載，便于業(yè)務(wù)團隊快速構(gòu)建業(yè)務(wù)鏡像； - Glance: 基于Openstack組件Glance擴展開發(fā)的Docker鏡像倉庫，用以托管業(yè)務(wù)部門制作的Docker鏡像。

鏡像倉庫不僅是容器平臺的必要組件，也是私有云的必要組件。美團私有云使用Glance作為鏡像倉庫，在建設(shè)容器平臺之前，Glance只用來托管虛擬機鏡像。每個鏡像有一個UUID，使用Glance API和鏡像UUID，可以上傳、下載虛擬機鏡像。Docker鏡像實際上是由一組子鏡像組成，每個子鏡像有獨立的ID，并帶有一個Parent ID屬性，指向其父鏡像。我們稍加改造了一下Glance，對每個Glance鏡像增加Parent ID的屬性，修改了鏡像上傳和下載的邏輯。經(jīng)過簡單擴展，使Glance具有托管Docker鏡像的能力。通過Glance擴展來支持Docker鏡像有以下優(yōu)點： - 可以使用同一個鏡像倉庫來托管Docker和虛擬機的鏡像，降低運維管理成本； - Glance已經(jīng)十分成熟穩(wěn)定，使用Glance可以減少在鏡像管理上踩坑； - 使用Glance可以使Docker鏡像倉庫和美團私有云“無縫”對接，使用同一套鏡像API，可以同時支持虛擬機和Docker鏡像上傳、下載，支持分布式的存儲后端和多租戶隔離等特性； - Glance UUID和Docker Image ID是一一對應(yīng)的關(guān)系，利用這個特性我們實現(xiàn)了Docker鏡像在倉庫中的唯一性，避免冗余存儲。

可能有人疑問，用Glance做鏡像倉庫是“重新造輪子”。事實上我們對Glance的改造只有200行左右的代碼。Glance簡單可靠，我們在很短的時間就完成了鏡像倉庫的開發(fā)上線，目前美團點評已經(jīng)托管超過16,000多個業(yè)務(wù)方的Docker鏡像，平均上傳和下載鏡像的延遲都是秒級的。

高性能、高彈性的容器網(wǎng)絡(luò)

網(wǎng)絡(luò)是十分重要的，又有技術(shù)挑戰(zhàn)性的領(lǐng)域。一個好的網(wǎng)絡(luò)架構(gòu)，需要有高網(wǎng)絡(luò)傳輸性能、高彈性、多租戶隔離、支持軟件定義網(wǎng)絡(luò)配置等多方面的能力。早期Docker提供的網(wǎng)絡(luò)方案比較簡單，只有None、Bridge、Container和Host這四種網(wǎng)絡(luò)模式，也沒有用戶開發(fā)接口。2015年Docker在1.9版本集成了Libnetwork作為其網(wǎng)絡(luò)的解決方案，支持用戶根據(jù)自身需求，開發(fā)相應(yīng)的網(wǎng)絡(luò)驅(qū)動，實現(xiàn)網(wǎng)絡(luò)功能自定義的功能，極大地增強了Docker的網(wǎng)絡(luò)擴展能力。

從容器集群系統(tǒng)來看，只有單宿主機的網(wǎng)絡(luò)接入是遠遠不夠的，網(wǎng)絡(luò)還需要提供跨宿主機、機架和機房的能力。從這個需求來看，Docker和虛擬機來說是共通的，沒有明顯的差異，從理論上也可以用同一套網(wǎng)絡(luò)架構(gòu)來滿足Docker和虛擬機的網(wǎng)絡(luò)需求。基于這種理念，容器平臺在網(wǎng)絡(luò)方面復(fù)用了美團云網(wǎng)絡(luò)基礎(chǔ)架構(gòu)和組件。

美團點評容器平臺網(wǎng)絡(luò)架構(gòu)

數(shù)據(jù)平面: 我們采用萬兆網(wǎng)卡，結(jié)合OVS-DPDK方案，并進一步優(yōu)化單流的轉(zhuǎn)發(fā)性能，將幾個CPU核綁定給OVS-DPDK轉(zhuǎn)發(fā)使用，只需要少量的計算資源即可提供萬兆的數(shù)據(jù)轉(zhuǎn)發(fā)能力。OVS-DPDK和容器所使用的CPU完全隔離，因此也不影響用戶的計算資源。

控制平面: 我們使用OVS方案。該方案是在每個宿主機上部署一個自研的軟件Controller，動態(tài)接收網(wǎng)絡(luò)服務(wù)下發(fā)的網(wǎng)絡(luò)規(guī)則，并將規(guī)則進一步下發(fā)至OVS流表，決定是否對某網(wǎng)絡(luò)流放行。

MosBridge

在MosBridge之前，我們配置容器網(wǎng)絡(luò)使用的是None模式。所謂None模式也就是自定義網(wǎng)絡(luò)的模式，配置網(wǎng)絡(luò)需要如下幾步： 1. 在創(chuàng)建容器時指定—net=None，容器創(chuàng)建啟動后沒有網(wǎng)絡(luò)； 2. 容器啟動后，創(chuàng)建eth-pair； 3. 將eth-pair一端連接到OVS Bridge上； 4. 使用nsenter這種Namespace工具將eth-pair另一端放到容器的網(wǎng)絡(luò)Namespace中，然后改名、配置IP地址和路由。

然而，在實踐中，我們發(fā)現(xiàn)None模式存在一些不足： - 容器剛啟動時是無網(wǎng)絡(luò)的，一些業(yè)務(wù)在啟動前會檢查網(wǎng)絡(luò)，導(dǎo)致業(yè)務(wù)啟動失敗； - 網(wǎng)絡(luò)配置與Docker脫離，容器重啟后網(wǎng)絡(luò)配置丟失； - 網(wǎng)絡(luò)配置由Host-SRV控制，每個網(wǎng)卡的配置流程都是在Host-SRV中實現(xiàn)的。以后網(wǎng)絡(luò)功能的升級和擴展，例如對容器添加網(wǎng)卡，或者支持VPC，會使Host-SRV越來越難以維護。

為了解決這些問題，我們將眼光投向Docker Libnetwork。Libnetwork為用戶提供了可以開發(fā)Docker網(wǎng)絡(luò)的能力，允許用戶基于Libnetwork實現(xiàn)網(wǎng)絡(luò)驅(qū)動來自定義其網(wǎng)絡(luò)配置的行為。就是說，用戶可以編寫驅(qū)動，讓Docker按照指定的參數(shù)為容器配置IP、網(wǎng)關(guān)和路由。基于Libnetwork，我們開發(fā)了MosBridge – 適配美團云網(wǎng)絡(luò)架構(gòu)的Docker網(wǎng)絡(luò)驅(qū)動。在創(chuàng)建容器時，需要指定容器創(chuàng)建參數(shù)—net=mosbridge，并將IP地址、網(wǎng)關(guān)、OVS Bridge等參數(shù)傳給Docker，由MosBridge完成網(wǎng)絡(luò)的配置過程。有了MosBridge，容器創(chuàng)建啟動后便有了網(wǎng)絡(luò)可以使用。容器的網(wǎng)絡(luò)配置也持久化在MosBridge中，容器重啟后網(wǎng)絡(luò)配置也不會丟失。更重要的是，MosBridge使Host-SRV和Docker充分解耦，以后網(wǎng)絡(luò)功能的升級也會更加方便。

解決Docker存儲隔離性的問題

業(yè)界許多公司使用Docker都會面臨存儲隔離性的問題。就是說Docker提供的數(shù)據(jù)存儲的方案是Volume，通過mount bind的方式將本地磁盤的某個目錄掛載到容器中，作為容器的“數(shù)據(jù)盤”使用。這種本地磁盤Volume的方式無法做到容量限制，任何一個容器都可以不加限制地向Volume寫數(shù)據(jù)，直到占滿整個磁盤空間。

LVM-Volume方案

針對這一問題，我們開發(fā)了LVM Volume方案。該方案是在宿主機上創(chuàng)建一個LVM VG作為Volume的存儲后端。創(chuàng)建容器時，從VG中創(chuàng)建一個LV當作一塊磁盤，掛載到容器里，這樣Volume的容量便由LVM加以強限制。得益于LVM機強大的管理能力，我們可以做到對Volume更精細、更高效的管理。例如，我們可以很方便地調(diào)用LVM命令查看Volume使用量，通過打標簽的方式實現(xiàn)Volume偽刪除和回收站功能，還可以使用LVM命令對Volume做在線擴容。值得一提地是，LVM是基于Linux內(nèi)核Devicemapper開發(fā)的，而Devicemapper在Linux內(nèi)核的歷史悠久，早在內(nèi)核2.6版本時就已合入，其可靠性和IO性能完全可以信賴。

適配多種監(jiān)控服務(wù)的容器狀態(tài)采集模塊

容器監(jiān)控是容器管理平臺極其重要的一環(huán)，監(jiān)控不僅僅要實時得到容器的運行狀態(tài)，還需要獲取容器所占用的資源動態(tài)變化。在設(shè)計實現(xiàn)容器監(jiān)控之前，美團點評內(nèi)部已經(jīng)有了許多監(jiān)控服務(wù)，例如Zabbix、Falcon和CAT。因此我們不需要重新設(shè)計實現(xiàn)一套完整的監(jiān)控服務(wù)，更多地是考慮如何高效地采集容器運行信息，根據(jù)運行環(huán)境的配置上報到相應(yīng)的監(jiān)控服務(wù)上。簡單來說，我們只需要考慮實現(xiàn)一個高效的Agent，在宿主機上可以采集容器的各種監(jiān)控數(shù)據(jù)。這里需要考慮兩點： 1. 監(jiān)控指標多，數(shù)據(jù)量大，數(shù)據(jù)采集模塊必須高效率； 2. 監(jiān)控的低開銷，同一個宿主機可以跑幾十個，甚至上百個容器，大量的數(shù)據(jù)采集、整理和上報過程必須低開銷。

監(jiān)控數(shù)據(jù)采集方案

針對業(yè)務(wù)和運維的監(jiān)控需求，我們基于Libcontainer開發(fā)了Mos-Docker-Agent監(jiān)控模塊。該模塊從宿主機proc、CGroup等接口采集容器數(shù)據(jù)，經(jīng)過加工換算，再通過不同的監(jiān)控系統(tǒng)driver上報數(shù)據(jù)。該模塊使用GO語言編寫，既可以高效率，又可以直接使用Libcontainer。而且監(jiān)控的數(shù)據(jù)采集和上報過程不經(jīng)過Docker Daemon，因此不會加重Daemon的負擔。

在監(jiān)控配置這塊，由于監(jiān)控上報模塊是插件式的，可以高度自定義上報的監(jiān)控服務(wù)類型，監(jiān)控項配置，因此可以很靈活地適應(yīng)不同的監(jiān)控場景的需求。

支持微服務(wù)架構(gòu)的設(shè)計

近幾年，微服務(wù)架構(gòu)在互聯(lián)網(wǎng)技術(shù)領(lǐng)域興起。微服務(wù)利用輕量級組件，將一個大型的服務(wù)拆解為多個可以獨立封裝、獨立部署的微服務(wù)實例，大型服務(wù)內(nèi)在的復(fù)雜邏輯由服務(wù)之間的交互來實現(xiàn)。

美團點評的很多在線業(yè)務(wù)是微服務(wù)架構(gòu)的。例如美團點評的服務(wù)治理框架，會為每一個在線服務(wù)配置一個服務(wù)監(jiān)控Agent，該Agent負責收集上報在線服務(wù)的狀態(tài)信息。類似的微服務(wù)還有許多。對于這種微服務(wù)架構(gòu)，使用Docker可以有以下兩種封裝模式。 1. 將所有微服務(wù)進程封裝到一個容器中。但這樣使服務(wù)的更新、部署很不靈活，任何一個微服務(wù)的更新都要重新構(gòu)建容器鏡像，這相當于將Docker容器當作虛擬機使用，沒有發(fā)揮出Docker的優(yōu)勢。 2. 將每個微服務(wù)封裝到單獨的容器中。Docker具有輕量、環(huán)境隔離的優(yōu)點，很適合用來封裝微服務(wù)。不過這樣可能產(chǎn)生額外的性能問題。一個是大型服務(wù)的容器化會產(chǎn)生數(shù)倍的計算實例，這對分布式系統(tǒng)的調(diào)度和部署帶來很大的壓力；另一個是性能惡化問題，例如有兩個關(guān)系緊密的服務(wù)，相互通信流量很大，但被部署到不同的機房，會產(chǎn)生相當大的網(wǎng)絡(luò)開銷。

對于支持微服務(wù)的問題，Kubernetes的解決方案是Pod。每個Pod由多個容器組成，是服務(wù)部署、編排、管理的最小單位，也是調(diào)度的最小單位。Pod內(nèi)的容器相互共享資源，包括網(wǎng)絡(luò)、Volume、IPC等。因此同一個Pod內(nèi)的多個容器相互之間可以高效率地通信。

我們借鑒了Pod的思想，在容器平臺上開發(fā)了面向微服務(wù)的容器組，我們內(nèi)部稱之為set。一個set邏輯示意如下圖所示。

Set邏輯示意圖

set是容器平臺的調(diào)度、彈性擴容/縮容的基本單位。每個set由一個BusyBox容器和若干個業(yè)務(wù)容器組成， BusyBox容器不負責具體業(yè)務(wù)，只負責管理set的網(wǎng)絡(luò)、Volume和IPC配置。

 set的配置json

set內(nèi)的所有容器共享網(wǎng)絡(luò)，Volume和IPC。set配置使用一個JSON描述(如圖6所示)，每一個set實例包含一個Container List，Container的字段描述了該容器運行時的配置，重要的字段有： - Index，容器編號，代表容器的啟動順序； - Image，Docker鏡像在Glance上的name或者ID； - Options，描述了容器啟動時的參數(shù)配置。其中CPU和MEM都是百分比，表示這個容器相對于整個set在CPU和內(nèi)存的分配情況（例如，對于一個4核的set而言，容器CPU:80，表示該容器將最多使用3.2個物理核）。

通過set，我們將美團點評的所有容器業(yè)務(wù)都做了標準化，即所有的線上業(yè)務(wù)都是用set描述，容器平臺內(nèi)只有set，調(diào)度、部署、啟停的單位都是set。 對于set的實現(xiàn)上我們還做了一些特殊處理： - Busybox具有Privileged權(quán)限，可以自定義一些sysctl內(nèi)核參數(shù)，提升容器性能。 - 為了穩(wěn)定性考慮，用戶不允許SSH登陸B(tài)usybox，只允許登陸其他業(yè)務(wù)容器。 - 為了簡化Volume管理，每一個set只有一個Volume，并掛載到Busybox下，每個容器相互共享這個Volume。

很多時候一個set內(nèi)的容器來自不同的團隊，鏡像更新頻度不一，我們在set基礎(chǔ)上設(shè)計了一個灰度更新的功能。該功能允許業(yè)務(wù)只更新set中的部分容器鏡像，通過一個灰度更新的API，即可將線上的set升級?；叶雀伦畲蟮暮锰幨强梢栽诰€更新部分容器，并保持線上服務(wù)不間斷。

Docker穩(wěn)定性和特性的解決方案：MosDocker

眾所周知，Docker社區(qū)非?；馃?#xff0c;版本更新十分頻繁，大概2～4個月左右會有一個大版本更新，而且每次版本更新都會伴隨大量的代碼重構(gòu)。Docker沒有一個長期維護的LTS版本，每次更新不可避免地會引入新的Bug。由于時效原因，一般情況下，某個Bug的修復(fù)要等到下一個版本。例如1.11引入的Bug，一般要到1.12版才能解決，而如果使用了1.12版，又會引入新的Bug，還要等1.13版。如此一來，Docker的穩(wěn)定性很難滿足生產(chǎn)場景的要求。因此十分有必要維護一個相對穩(wěn)定的版本，如果發(fā)現(xiàn)Bug，可以在此版本基礎(chǔ)上，通過自研修復(fù)，或者采用社區(qū)的BugFix來修復(fù)。

除了穩(wěn)定性的需求之外，我們還需要開發(fā)一些功能來滿足美團點評的需求。美團點評業(yè)務(wù)的一些需求來自于我們自己的生產(chǎn)環(huán)境，而不屬于業(yè)界通用的需求。對于這類需求，開源社區(qū)通常不會考慮。業(yè)界許多公司都存在類似的情況，作為公司基礎(chǔ)服務(wù)團隊就必須通過技術(shù)開發(fā)來滿足這種需求。

基于以上考慮，我們從Docker 1.11版本開始，自研維護一個分支，我們稱之為MosDocker。之所以選擇從版本1.11開始，是因為從該版本開始，Docker做了幾項重大改進： Docker Daemon重構(gòu)為Daemon、Containerd和runC這3個Binary，并解決Daemon的單點失效問題； - 支持OCI標準，容器由統(tǒng)一的rootfs和spec來定義； - 引入了Libnetwork框架，允許用戶通過開發(fā)接口自定義容器網(wǎng)絡(luò)； - 重構(gòu)了Docker鏡像存儲后端，鏡像ID由原來的隨即字符串轉(zhuǎn)變?yōu)榛阽R像內(nèi)容的Hash，使Docker鏡像安全性更高。

到目前為止，MosDocker自研的特性主要有： 1. MosBridge，支持美團云網(wǎng)絡(luò)架構(gòu)的網(wǎng)絡(luò)驅(qū)動, 基于此特性實現(xiàn)容器多IP，VPC等網(wǎng)絡(luò)功能； 2. Cgroup持久化，擴展Docker Update接口，可以使更多的CGroup配置持久化在容器中，保證容器重啟后CGroup配置不丟失。 3. 支持子鏡像的Docker Save，可以大幅度提高Docker鏡像的上傳、下載速度。

總之，維護MosDocker使我們可以將Docker穩(wěn)定性逐漸控制在自己手里，并且可以按照公司業(yè)務(wù)的需求做定制開發(fā)。

在實際業(yè)務(wù)中的推廣應(yīng)用

在容器平臺運行的一年多時間里，已經(jīng)接入了美團點評多個大型業(yè)務(wù)部門的業(yè)務(wù)，業(yè)務(wù)類型也是多種多樣。通過引入Docker技術(shù)，為業(yè)務(wù)部門帶來諸多好處，典型的好處包括以下兩點。 - 快速部署，快速應(yīng)對業(yè)務(wù)突發(fā)流量。由于使用Docker，業(yè)務(wù)的機器申請、部署、業(yè)務(wù)發(fā)布一步完成，業(yè)務(wù)擴容從原來的小時級縮減為秒級，極大地提高了業(yè)務(wù)的彈性能力。 - 節(jié)省IT硬件和運維成本。Docker在計算上效率更高，加之高彈性使得業(yè)務(wù)部門不必預(yù)留大量的資源，節(jié)省大量的硬件投資。以某業(yè)務(wù)為例，之前為了應(yīng)對流量波動和突發(fā)流量，預(yù)留了32臺8核8G的虛擬機。使用容器彈性方案，即3臺容器+彈性擴容的方案取代固定32臺虛擬機，平均單機QPS提升85%， 平均資源占用率降低44-56%(如圖7，8所示)。 - Docker在線擴容能力，保障服務(wù)不中斷。一些有狀態(tài)的業(yè)務(wù)，例如數(shù)據(jù)庫和緩存，運行時調(diào)整CPU、內(nèi)存和磁盤是常見的需求。之前部署在虛擬機中，調(diào)整配置需要重啟虛擬機，業(yè)務(wù)的可用性不可避免地被中斷了，成為業(yè)務(wù)的痛點。Docker對CPU、內(nèi)存等資源管理是通過Linux的CGroup實現(xiàn)的，調(diào)整配置只需要修改容器的CGroup參數(shù)，不必重啟容器。

 某業(yè)務(wù)虛擬機和容器平均單機QPS  某業(yè)務(wù)虛擬機和容器資源使用量

結(jié)束語

本文介紹了美團點評Docker的實踐情況。經(jīng)過一年的推廣實踐，從部門內(nèi)部自己使用，到覆蓋公司大部分業(yè)務(wù)部門和產(chǎn)品線；從單一業(yè)務(wù)類型到公司線上幾十種業(yè)務(wù)類型，證明了Docker這種容器虛擬化技術(shù)在提高運維效率，精簡發(fā)布流程，降低IT成本等方面的價值。

目前Docker平臺還在美團點評深入推廣中。在這個過程中，我們發(fā)現(xiàn)Docker（或容器技術(shù)）本身存在許多問題和不足，例如，Docker存在IO隔離性不強的問題，無法對Buffered IO做限制；偶爾Docker Daemon會卡死，無反應(yīng)的問題；容器內(nèi)存OOM導(dǎo)致容器被刪除，開啟OOM_kill_disabled后可能導(dǎo)致宿主機內(nèi)核崩潰等問題。因此Docker技術(shù)，在我們看來和虛擬機應(yīng)該是互補的關(guān)系，不能指望在所有場景中Docker都可以替代虛擬機，因此只有將Docker和虛擬機并重，才能滿足用戶的各種場景對云計算的需求。

總結(jié)

以上是生活随笔為你收集整理的美团点评Docker容器管理平台的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。