本文介紹美團點評的 Docker 容器叢集管理平臺（以下簡稱容器平臺）。該平臺始於 2015 年，基於美團雲的基礎架構和元件而開發的 Docker 容器叢集管理平臺。目前該平臺為美團點評的外賣、酒店、到店、貓眼等十幾個事業部提供容器計算服務，承載線上業務數百個，容器例項超過 3 萬個，日均線上請求超過 45 億次，業務型別涵蓋 Web、資料庫、快取、訊息佇列等等。

容器到來之前

在容器平臺實施之前，美團點評的所有業務都是執行在美團私有云提供的虛擬機器之上。美團點評大部分的線上業務都是面向消費者和商家的，業務型別多樣，彈性的時間、頻度也不盡相同，這對彈性服務提出了很高的要求。

在這一點上，虛擬機器已經難以滿足需求，主要體現以下兩點：

• 虛擬機器彈效能力較弱，部署效率低，認為干預較多，可靠性差。
• IT 成本高。由於虛擬機器彈效能力較弱，業務部門為了應對流量高峰和突發流量，普遍採用預留大量機器和服務例項的做法。資源沒有得到充分使用產生浪費。

容器時代

架構設計

美團點評將容器管理平臺視作一種雲端計算模式，因此雲端計算的架構同樣適用於容器。

如前所述，容器平臺的架構依託於美團私有云現有架構，其中私有云的大部分元件可以直接複用或者經過少量擴充套件開發，如圖所示。

圖 1. 美團點評容器管理平臺架構

整體架構上與雲端計算架構是一致的，自上而下分為業務層、PaaS 層、IaaS 控制層及宿主機資源層。

• 業務層：代表美團點評使用容器的業務線，他們是容器平臺的終端使用者。
• PaaS 層：使用容器平臺的 HTTP API，完成容器的編排、部署、彈性伸縮，監控、服務治理等功能，對上面的業務層通過 HTTP API 或者 Web 的方式提供服務
• IaaS 控制層：提供容器平臺的 API 處理、排程、網路、使用者鑑權、映象倉庫等管理功能，對 PaaS 提供 HTTP API 介面
• 宿主機資源層：Docker 宿主機叢集，由多個機房，數百個節點組成。每個節點部署 HostServer，Docker、監控資料採集模組，Volume 管理模組，OVS 網路管理模組，Cgroup 管理模組等。容器平臺中的絕大部分元件是基於美團私有云已有元件擴充套件開發的，例如映象倉庫、平臺控制器、HostServer、網路管理模組。容器平臺的技術棧，核心元件，包括平臺控制器，網路服務，排程器等都是自研開發的。Docker 映象倉庫基於 Openstack 的 Glance 擴充套件開發，監控系統有使用 Falcon，CAT；服務治理、服務發現、服務負載均衡是使用的美團自研系統。開發語言主要是 Python 和 Golang。

容器網路  

 高效能、高彈性的架構設計

容器平臺在網路方面複用了美團雲網絡基礎架構和元件，邏輯架構設計如圖所示。

圖 2. 美團點評容器平臺網路架構

在資料平面，我們採用萬兆網絡卡，結合 OVS-DPDK 方案，並進一步優化單流的轉發效能，將幾個 CPU 核繫結給 OVS-DPDK 轉發使用，需要少量的計算資源即可提供萬兆的資料轉發能力。OVS-DPDK 和容器所使用的 CPU 完全隔離，因此也不影響使用者的計算資源。控制平面我們使用 OVS 方案。所謂 OVS 方案是在每個宿主機上部署一個軟體的 Controller，動態接收網路服務下發的網路規則，並將規則進一步下發至 OVS 流表，決定是否對某網路流放行。

自研配置模式 MosBridge

在 MosBridge 之前，我們配置容器網路使用的是 None 模式。在實踐中，我們發現 None 模式存在一些不足：

1. 容器剛啟動時是無網路的，一些業務在啟動前會檢查網路，導致業務啟動失敗；
2. 網路配置與 Docker 脫離，容器重啟後網路配置丟失；
3. 網路配置由 Host-SRV 控制，對於以後網路功能的升級和擴充套件帶來很多不便，例如對容器增加虛擬網絡卡，或者支援 VPC。

為了解決這些問題，我們基於 Libnetwork，開發了 MosBridge – 適配美團雲網絡架構的 Docker 網路驅動。在建立容器時，需要指定容器建立引數—net=mosbridge，並將 ip 地址，閘道器，OVS Bridge 等引數傳給 Docker，由 MosBridge 完成網路的配置過程。有了 MosBridge，容器建立啟動後便有了網路可以使用。容器的網路配置也持久化在 MosBridge 中，容器重啟後網路配置也不會丟失。

容器儲存隔離性  

為了解決本地磁碟資料卷限容能力弱的問題，我們開發了 LVM Volume 方案。該方案在宿主機上建立一個 LVM VG 作為 Volume 的儲存後端。建立容器時，從 VG 中建立一個 LV 當作一塊磁碟，掛載到容器裡。這樣 Volume 的容量便由 LVM 的 LV 加以強限制，得益於 LVM 機強大的管理能力，我們可以做到對 Volume 更精細、更高效的管理。例如，我們可以很方便地呼叫 LVM 命令檢視 Volume 使用量，通過打標籤的方式實現 Volume 偽刪除和回收站功能，還可以使用 LVM 命令對 Volume 做線上擴容。

圖 3. LVM-Volume 方案

容器狀態採集  

在設計實現容器監控之前，美團點評內部已經有了許多監控服務，例如 zabbix，falcon 和 CAT。我們不需要設計實現一套完整的監控服務，而更多地是如何高效地採集容器執行資訊，根據執行環境的配置上報到相應的監控服務上。

圖 4：監控資料採集方案

針對業務和運維的監控需求，我們基於 libcontainer 開發了 mos-docker-agent 監控模組。該模組從宿主機 proc、cgroup 等介面採集容器資料，經過加工換算，再通過不同的監控系統 driver 上報資料。該模組使用 go 語言編寫，既可以高效率，又可以直接使用 libcontainer。而且監控不經過 Docker Daemon，不加重 Daemon 的負擔。

美團自研容器分支：MosDocker

基本介紹

我們從 Docker 1.11 版本開始，自研維護一個分支，我們稱之為 MosDocker。除了一些 Bugfix 之外，MosDocker 還有一些自研的特性。

1. MosBridge：支援美團雲網絡架構的網路驅動。
2. Cgroup 持久化：擴充套件 Docker Update 介面，可以使更多的 cgroup 配置持久化在容器中，保證容器重啟後 cgroup 配置不丟失。
3. 支援子映象的 Docker Save，可以大幅度提高 Docker 映象的上傳、下載速度。

MosDocker 的大部分特性是解決美團點評業務場景的需求問題，不適合開源。對於社群的 bugfix，我們會定期 review 並 backport 到我們的 MosDocker 版本里。

原理探究：服務治理與容器編排

圖 5：美團點評服務治理平臺

元件：

• MNS：命名服務
• SG_agent: 服務治理代理
• HLB：彈性負載均衡器

功能：

• 服務命名、註冊、發現
• 負載均衡
• 容錯
• 灰度釋出
• 服務呼叫資料視覺化

圖 6：set 容器組設計

設計特性

• 鬆耦合
• 容器組作為一個整體排程、管理
• 容器之間 CPU、IO 資源隔離
• 網路棧，Volume 共享

參考 Kubernetes 的 Pod 設計，針對我們的容器平臺設計實現了 set 容器組。容器組對外呈現一個 IP，內建一個 busybox 作為 infra-container，它不提供任何業務功能，set 的網路、volume 都配置在 busybox 上，所有其他的容器都和 busybox 共享。

 在實際業務中的推廣應用

通過引入 Docker 技術，為業務部門帶來諸多好處，典型的好處有幾點：

• 快速部署，快速應對業務突發流量由於使用 Docker，業務的機器申請、部署、業務釋出一步完成，業務擴容從原來的小時級縮減為秒級，極大地提高了業務的彈效能力。
• 節省 IT 硬體和運維成本Docker 在計算上效率更高，加之高彈性使得業務部門不必預留大量的資源，節省大量的硬體投資。以某業務為例，之前為了應對流量波動和突發流量，預留了 32 臺 8 核 8G 的虛擬機器。使用容器彈性方案，即 3 臺容器 + 彈性擴容的方案取代固定 32 臺虛擬機器，平均單機 QPS 提升 85%， 平均資源佔用率降低 44-56%。

圖 7. 某業務虛擬機器和容器平均單機 QPS

圖 8 某業務虛擬機器和容器資源使用量

• Docker 線上擴容能力，保障服務不中斷

總結

在容器化過程中，我們發現 Docker 或者容器技術本身存在許多問題和不足，例如，Docker 存在 IO 隔離性不強的問題，無法對 Buffered IO 做限制；偶爾 Docker Daemon 會卡死，無反應的問題；容器記憶體 OOM 導致容器被刪除，開啟 OOM_kill_disabled 後可能導致宿主機核心崩潰等等問題。因此 Docker 或者容器技術，在我們看來應該和虛擬機器是互補的關係，不能指望在所有場景中 Docker 都可以替代虛擬機器，因此只有將 Docker 和虛擬機器並重，才能滿足使用者的各種場景對雲端計算的需求。

QA 環節

A1:4G 記憶體的容器還好，我們線上物理機標配是 128G 記憶體，而且容器的記憶體只是 cgroup 裡的一個設定，實際分配記憶體還是以容器使用為準。對於一些記憶體 bound 型業務，記憶體需要 10G 甚至更多的，我們給這類業務單獨一個物理機叢集使用，不和其他業務混部。

A2：kubernetes 源於 Google 的 Borg 系統，Borg 是一個分散式容器叢集管理平臺，在 Google 內部使用 10 多年，承載海量的 Google 線上業務，架構、效能都在業內有廣泛聲譽。Kubernetes 可以看作 Borg 用 Go 語言重寫，和 Borg 一脈相承，所以 Kubernetes 一經推出便廣受業界推崇，現在已經是容器叢集管理系統的業界標杆。簡單來說 Kuberenetes 有一下優勢：

1. 鬆耦合架構設計：etcd 是 k8s 的元資料儲存中心，使用 RAFT 演算法保證資料強一致性，除了支援 POST/PUT/GET/DELETE 之外，還支援 WATCH，是 k8s 的真實之源。apiserver 是無狀態的 API 伺服器，是唯一可以和 etcd 通訊的元件，所有其他元件都是通過 apiserver 訪問 etcd 的，apiserver 可以水平擴充套件。Controller-mananger 整合 RC、Deployment 等控制器。Scheduler 是 Pod 的排程器。Kubelet 是 Node 上資源和容器 runtime 的管理器。除 etcd, apiserver 之外，所有元件之間的通訊方式都是通過 Watch etcd 交換資料，元件之間不直接通訊，這種設計使整個架構徹底鬆耦合，任何元件都很容易被替換、擴充套件的。
2. Pod 容器組支援：Pod 是一個容器組的抽象概念，將一組容器聚合成一個 Pod，作為排程和資源分配的接本單位。Pod 的設計更貼近生成場景對容器的需求，因為實際一個服務都是有多個業務程序組成的，這些程序在 VM 時代一般都放在同一個 VM 內，而在容器時代，最佳方案是一個容器只執行一個程序，而將這些強相關的程序放到不通的容器裡，再將這些容器聚合成一個 Pod，是更理想的使用容器的方式。
3. Kubernetes 不僅是一個物理機 /VM 叢集管理系統，或者說不僅是一個 IaaS，它自帶許多容器的編排控制功能，例如 RC，Service。容器時代業界更關心基於容器的編排管理，Kubernetes 考慮了大多數容器生成場景的需求，內建了許多容器編排功能，可以讓使用者開箱即用的方式使用容器自動化部署業務，高效運維。
4. kubernetes 已經成為業界容器標準之一，社群火熱，版本更新快，因此使用 k8s，在長期的技術支援上，是有比較長期的、穩定的報障。

A3：

1. 從技術上說，容器技術有 10 幾年的歷史，Docker 也有 5，6 年的歷史了，容器 /Docker 所依賴的 Linux 核心 Cgroup 和 Namespace 技術，歷史更悠久，因此容器的技術可靠性是完全可以信賴的。
2. Docker 版本更新較快，版本迭代頻繁，而且 docker 沒有長期穩定版 LTS 的支援，所以在生產場景中使用，難免會踩到 Docker 的 Bug，所以如果要在實際生產環境中大規模使用，需要有對 Docker 本身的維護能力。
3. Docker 和 VM 相比，虛擬化層次不同，導致 Docker 的隔離性要比 VM 弱，在多租戶環境中有安全隔離的問題，另外在單宿主機上，容器之間的資源競爭也可能導致業務會受到影響，需要對容器的資源隔離，特別是 cgroup 的隔離有較為精細的運維。

A4：美團雲 Docker 平臺的 Volume 管理經過 3 個階段：

階段 1：本地檔案系統做 volume，優點是開發快，缺點是限容、隔離性差，資料可靠性差

階段 2：本地 lvm 磁碟，解決了 volume 隔離性問題，但可靠性仍然不足

階段 3：現階段，我們使用美團雲自研的分散式彈性塊儲存服務，相當於 aws 的 EBS，用 ebs 做 volume 儲存後端，完全解決了容量限制，隔離性，可靠性的問題，在 volume 備份、遷移上也有優勢。

A5：據我所知，業界大規模使用容器的方案有 k8s 和 Mesos 的，Swarm 早期功能簡單，不能滿足生產所需，不過 Docker 公司對 Swarm 的更新很快，而且 Swarm 和 Docker 是一致的介面，相信以後會有較多的實踐。

A6：美團雲端儲存後端有分散式物件儲存系統，也有分散式塊儲存系統。都是美團雲自研的系統。

作者介紹

鄭坤， 2011 年中科院計算所博士畢業，曾在華為從事核心研發工作。2015 年加入美團，負責美團雲容器平臺的設計開發，以及在美團點評內部容器化推廣工作。很高興本次分享 Docker 技術在美團點評的實踐情況。

文章來自微信公眾號：高效開發運維