企業(yè)容器平臺架構及容器技術實踐

1、 企業(yè)容器平臺架構及容器技術實踐目 錄 TOC o 1-3 h z u HYPERLINK l _Toc26031189 1.背景 PAGEREF _Toc26031189 h 3 HYPERLINK l _Toc26031190 2.美團容器平臺的基本架構 PAGEREF _Toc26031190 h 4 HYPERLINK l _Toc26031191 2.1容器遇到的一些問題 PAGEREF _Toc26031191 h 6 HYPERLINK l _Toc26031192 3.容器的實現(xiàn) PAGEREF _Toc26031192 h 7 HYPERLINK l _Toc26031193

2、 4.美團的解法、改進和優(yōu)化 PAGEREF _Toc26031193 h 8 HYPERLINK l _Toc26031194 4.1隔離 PAGEREF _Toc26031194 h 8 HYPERLINK l _Toc26031195 4.2穩(wěn)定性 PAGEREF _Toc26031195 h 13 HYPERLINK l _Toc26031196 4.3性能 PAGEREF _Toc26031196 h 15 HYPERLINK l _Toc26031197 4.4性能優(yōu)化：文件系統(tǒng) PAGEREF _Toc26031197 h 17 HYPERLINK l _Toc26031198

3、4.5推廣 PAGEREF _Toc26031198 h 22 HYPERLINK l _Toc26031199 5.總結 PAGEREF _Toc26031199 h 23背景美團的容器集群管理平臺叫做HULK。漫威動畫里的HULK在發(fā)怒時會變成“綠巨人”，它的這個特性和容器的“彈性伸縮”很像，所以我們給這個平臺起名為HULK。貌似有一些公司的容器平臺也叫這個名字，純屬巧合。2016年，美團開始使用容器，當時美團已經具備一定的規(guī)模，在使用容器之前就已經存在的各種系統(tǒng)，包括CMDB、服務治理、監(jiān)控告警、發(fā)布平臺等等。我們在探索容器技術時，很難放棄原有的資產。所以容器化的第一步，就是打通容器的生

4、命周期和這些平臺的交互，例如容器的申請/創(chuàng)建、刪除/釋放、發(fā)布、遷移等等。然后我們又驗證了容器的可行性，證實容器可以作為線上核心業(yè)務的運行環(huán)境。2018年，經過兩年的運營和實踐探索，我們對容器平臺進行了一次升級，這就是容器集群管理平臺HULK 2.0。把基于OpenStack的調度系統(tǒng)升級成容器編排領域的事實標準Kubernetes（以后簡稱K8s）。提供了更豐富可靠的容器彈性策略。針對之前在基礎系統(tǒng)上碰到的一些問題，進行了優(yōu)化和打磨。美團當前的容器使用狀況是：線上業(yè)務已經超過3000多個服務，容器實例數(shù)超過30000個，很多大并發(fā)、低延時要求的核心鏈路服務，已經穩(wěn)定地運行在HULK之上。本文

5、主要介紹我們在容器技術上的一些實踐，屬于基礎系統(tǒng)優(yōu)化和打磨。美團容器平臺的基本架構首先介紹一下美團容器平臺的基礎架構，相信各家的容器平臺架構大體都差不多。首先，容器平臺對外對接服務治理、發(fā)布平臺、CMDB、監(jiān)控告警等等系統(tǒng)。通過和這些系統(tǒng)打通，容器實現(xiàn)了和虛擬機基本一致的使用體驗。研發(fā)人員在使用容器時可以和使用VM一樣，不需要改變原來的使用習慣。此外，容器提供彈性擴容能力，能根據一定的彈性策略動態(tài)增加和減少服務的容器節(jié)點數(shù)，從而動態(tài)地調整服務處理能力。這里還有個特殊的模塊“服務畫像”，它的主要功能是通過對服務容器實例運行指標的搜集和統(tǒng)計，更好的完成調度容器、優(yōu)化資源分配。比如可以根據某服務的容

6、器實例的CPU、內存、IO等使用情況，來分辨這個服務屬于計算密集型還是IO密集型服務，在調度時盡量把互補的容器放在一起。再比如，我們可以知道某個服務的每個容器實例在運行時會有大概500個進程，我們就會在創(chuàng)建容器時，給該容器加上一個合理的進程數(shù)限制（比如最大1000個進程），從而避免容器在出現(xiàn)問題時，占用過多的系統(tǒng)資源。如果這個服務的容器在運行時，突然申請創(chuàng)建20000個進程，我們有理由相信是業(yè)務容器遇到了Bug，通過之前的資源約束對容器進行限制，并發(fā)出告警，通知業(yè)務及時進行處理。往下一層是“容器編排”和“鏡像管理”。容器編排解決容器動態(tài)實例的問題，包括容器何時被創(chuàng)建、創(chuàng)建到哪個位置、何時被刪除

7、等等。鏡像管理解決容器靜態(tài)實例的問題，包括容器鏡像應該如何構建、如何分發(fā)、分發(fā)的位置等等。最下層是我們的容器運行時，美團使用主流的Linux+Docker容器方案，HULK Agent是我們在服務器上的管理代理程序。把前面的“容器運行時”具體展開，可以看到這張架構圖，按照從下到上的順序介紹：最下層是CPU、內存、磁盤、網絡這些基礎物理資源。往上一層，我們使用的是CentOS 7作為宿主機操作系統(tǒng)，Linux內核的版本是3.10。我們在CentOS發(fā)行版默認內核的基礎上，加入一些美團為容器場景研發(fā)的新特性，同時為高并發(fā)、低延時的服務型業(yè)務做了一些內核參數(shù)的優(yōu)化。再往上一層，我們使用的是CentO

8、S發(fā)行版里自帶的Docker，當前的版本是1.13，同樣，加入了一些我們自己的特性和增強。HULK Agent是我們自己開發(fā)的主機管理Agent，在宿主機上管理Agent。Falcon Agent同時存在于宿主機和容器內部，它的作用是收集宿主機和容器的各種基礎監(jiān)控指標，上報給后臺和監(jiān)控平臺。最上一層是容器本身。我們現(xiàn)在主要支持CentOS 6和CentOS 7兩種容器。在CentOS 6中有一個container init進程，它是我們開發(fā)容器內部的1號進程，作用是初始化容器和拉起業(yè)務進程。在CentOS 7中，我們使用了系統(tǒng)自帶的systemd作為容器中的1號進程。我們的容器支持各種主流編程

9、語言，包括Java、Python、Node.js、C/C+等等。在語言層之上是各種代理服務，包括服務治理的Agent、日志Agent、加密Agent等等。同時，我們的容器也支持美團內部的一些業(yè)務環(huán)境，例如set信息、泳道信息等，配合服務治理體系，可以實現(xiàn)服務調用的智能路由。美團主要使用了CentOS系列的開源組件，因為我們認為Red Hat有很強的開源技術實力，比起直接使用開源社區(qū)的版本，我們希望Red Hat的開源版本能夠幫助解決大部分的系統(tǒng)問題。我們也發(fā)現(xiàn)，即使部署了CentOS的開源組件，仍然有可能會碰到社區(qū)和Red Hat沒有解決的問題。從某種程度上也說明，國內大型互聯(lián)公司在技術應用的

10、場景、規(guī)模、復雜度層面已經達到了世界領先的水平，所以才會先于社區(qū)、先于Red Hat的客戶遇到這些問題。容器遇到的一些問題在容器技術本身，我們主要遇到了4個問題：隔離、穩(wěn)定性、性能和推廣。隔離包含兩個層面：第一個問題是，容器能不能正確認識自身資源配置；第二個問題是，運行在同一臺服務器上的容器會不會互相影響。比如某一臺容器的IO很高，就會導致同主機上的其它容器服務延時增加。穩(wěn)定性：這是指在高壓力、大規(guī)模、長時間運行以后，系統(tǒng)功能可能會出現(xiàn)不穩(wěn)定的問題，比如容器無法創(chuàng)建、刪除，因為軟件問題發(fā)生卡死、宕機等問題。性能：在虛擬化技術和容器技術比較時，大家普遍都認為容器的執(zhí)行效率會更高，但是在實踐中，我

11、們遇到了一些特例：同樣的代碼在同樣配置的容器上，服務的吞吐量、響應時延反而不如虛擬機。推廣：當我們把前面幾個問題基本上都解決以后，仍然可能會碰到業(yè)務不愿意使用容器的情況，其中原因一部分是技術因素，例如容器接入難易程度、周邊工具、生態(tài)等都會影響使用容器的成本。推廣也不是一個純技術問題，跟公司內部的業(yè)務發(fā)展階段、技術文化、組織設置和KPI等因素都密切相關。容器的實現(xiàn)容器本質上是把系統(tǒng)中為同一個業(yè)務目標服務的相關進程合成一組，放在一個叫做namespace的空間中，同一個namespace中的進程能夠互相通信，同時看不見其他namespace中的進程。每個namespace可以擁有自己獨立的主機名、

12、進程ID系統(tǒng)、IPC、網絡、文件系統(tǒng)、用戶等等資源，在某種程度上，實現(xiàn)了一個簡單的虛擬：讓一個主機上可以同時運行多個互不感知的系統(tǒng)。此外，為了限制namespace對物理資源的使用，對進程能使用的CPU、內存等資源需要做一定的限制，這就是Cgroup技術，Cgroup是Control group的意思。比如我們常說的4c4g的容器，實際上是限制這個容器namespace中所用的進程，最多能夠使用4核的計算資源和4GB的內存。簡而言之，Linux內核提供namespace完成隔離，Cgroup完成資源限制。namespace+Cgroup構成了容器的底層技術（rootfs是容器文件系統(tǒng)層技術）。

13、美團的解法、改進和優(yōu)化隔離之前一直和虛擬機打交道，但直到用上容器，才發(fā)現(xiàn)在容器里面看到的CPU、Memory的信息都是服務器主機的信息，而不是容器自身的配置信息，直到現(xiàn)在，社區(qū)版的容器還是這樣。比如一個4c4g的容器，在容器內部可以看到有40顆CPU、196GB內存的資源，這些資源其實是容器所在宿主機的信息。這給人的感覺，就像是容器的“自我膨脹”，覺得自己能力很強，但實際上并沒有，而且還會帶來很多問題。上圖是一個內存信息隔離的例子。獲取系統(tǒng)內存信息時，社區(qū)Linux無論在主機上還是在容器中，內核都是統(tǒng)一返回主機的內存信息，如果容器內的應用，按照它發(fā)現(xiàn)的宿主機內存來進行配置的話，實際資源是遠遠不

14、夠的，導致的結果就是：系統(tǒng)很快會發(fā)生OOM異常。我們做的隔離工作，是在容器中獲取內存信息時，內核根據容器的Cgroup信息返回容器的內存信息（類似LXCFS的工作）。CPU信息隔離的實現(xiàn)和內存的類似，不再贅述，這里舉一個CPU數(shù)目影響應用性能例子。大家都知道，JVM GC（垃圾對象回收）對Java程序執(zhí)行性能有一定的影響。默認的JVM使用公式“ParallelGCThreads = (ncpus = 8) ? ncpus : 3 + (ncpus * 5) / 8)” 來計算做并行GC的線程數(shù)，其中ncpus是JVM發(fā)現(xiàn)的系統(tǒng)CPU個數(shù)。一旦容器中JVM發(fā)現(xiàn)了宿主機的CPU個數(shù)（通常比容器實際

15、CPU限制多很多），這就會導致JVM啟動過多的GC線程，直接的結果就導致GC性能下降。Java服務的感受就是延時增加，TP監(jiān)控曲線突刺增加，吞吐量下降。針對這個問題有各種解法：顯式的傳遞JVM啟動參數(shù)“-XX:ParallelGCThreads”告訴JVM應該啟動幾個并行GC線程。它的缺點是需要業(yè)務感知，為不同配置的容器傳不同的JVM參數(shù)。在容器內使用Hack過的glibc，使JVM（通過sysconf系統(tǒng)調用）能正確獲取容器的CPU資源數(shù)。我們在一段時間內使用的就是這種方法。其優(yōu)點是業(yè)務不需要感知，并且能自動適配不同配置的容器。缺點是必須使用改過的glibc，有一定的升級維護成本，如果使用的

16、鏡像是原生的glibc，問題也仍然存在。我們在新平臺上通過對內核的改進，實現(xiàn)了容器中能獲取正確CPU資源數(shù)，做到了對業(yè)務、鏡像和編程語言都透明（類似問題也可能影響OpenMP、Node.js等應用的性能）。有一段時間，我們的容器是使用root權限進行運行，實現(xiàn)的方法是在docker run的時候加入privileged=true參數(shù)。這種粗放的使用方式，使容器能夠看到所在服務器上所有容器的磁盤，導致了安全問題和性能問題。安全問題很好理解，為什么會導致性能問題呢？可以試想一下，每個容器都做一次磁盤狀態(tài)掃描的場景。當然，權限過大的問題還體現(xiàn)在可以隨意進行mount操作，可以隨意的修改NTP時間等等

17、。在新版本中，我們去掉了容器的root權限，發(fā)現(xiàn)有一些副作用，比如導致一些系統(tǒng)調用失敗。我們默認給容器額外增加了sys_ptrace和sys_admin兩個權限，讓容器可以運行GDB和更改主機名。如果有特例容器需要更多的權限，可以在我們的平臺上按服務粒度進行配置。Linux有兩種IO：Direct IO和Buffered IO。Direct IO直接寫磁盤，Duffered IO會先寫到緩存再寫磁盤，大部分場景下都是Buffered IO。我們使用的Linux內核3.X，社區(qū)版本中所有容器Buffer IO共享一個內核緩存，并且緩存不隔離，沒有速率限制，導致高IO容器很容易影響同主機上的其他容

18、器。Buffer IO緩存隔離和限速在Linux 4.X里通過Cgroup V2實現(xiàn)，有了明顯的改進，我們還借鑒了Cgroup V2的思想，在我們的Linux 3.10內核實現(xiàn)了相同的功能：每個容器根據自己的內存配置有對應比例的IO Cache，Cache的數(shù)據寫到磁盤的速率受容器Cgroup IO配置的限制。Docker本身支持較多對容器的Cgroup資源限制，但是K8s調用Docker時可以傳遞的參數(shù)較少，為了降低容器間的互相影響，我們基于服務畫像的資源分配，對不同服務的容器設定不同的資源限制。除了常見的CPU、內存外，還有IO的限制、ulimit限制、PID限制等等，所以我們擴展了K8s

19、來完成這些工作。業(yè)務在使用容器的過程中產生core dump文件是常見的事。比如C/C+程序內存訪問越界，或者系統(tǒng)OOM時，系統(tǒng)選擇占用內存多的進程殺死，默認都會生成一個core dump文件。社區(qū)容器系統(tǒng)默認的core dump文件會生成在宿主機上。由于一些core dump文件比較大，比如JVM的core dump通常是幾個GB，或者有些存在Bug的程序，其頻發(fā)的core dump，很容易快速寫滿宿主機的存儲，并且會導致高磁盤IO，也會影響到其他容器。還有一個問題是：業(yè)務容器的使用者沒有權限訪問宿主機，從而拿不到dump文件進行下一步的分析。為此，我們對core dump的流程進行了修改，

20、讓dump文件寫到容器自身的文件系統(tǒng)中，并且使用容器自己的Cgroup IO吞吐限制。穩(wěn)定性我們在實踐中發(fā)現(xiàn)，影響系統(tǒng)穩(wěn)定性的主要是Linux Kernel和Docker。雖然它們本身是很可靠的系統(tǒng)軟件，但是在大規(guī)模、高強度的場景中，還是會存在一些Bug。這也從側面說明，我們國內互聯(lián)網公司在應用規(guī)模和應用復雜度層面也屬于全球領先。在內核方面，美團發(fā)現(xiàn)了Kernel 4.x Buffer IO限制的實現(xiàn)問題，得到了社區(qū)的確認和修復。我們還跟進了一系列CentOS的Ext4補丁，解決了一段時間內進程頻繁卡死的問題。我們碰到了兩個比較關鍵的Red Hat版Docker穩(wěn)定性問題：在Docker服務重

21、啟以后，Docker exec無法進入容器，這個問題比較復雜。在解決之前我們用nsenter來代替Docker exec并積極反饋給Red Hat。后來Red Hat在今年初的一個更新解決了這個問題。/errata/RHBA-2017:1620是在特定條件下Docker Daemon會Panic，導致容器無法刪除。經過我們自己Debug，并對比最新的代碼，發(fā)現(xiàn)問題已經在Docker upstream中得到解決，反饋給Red Hat也很快得到了解決。/projectatomic/containerd/issues/2面對系統(tǒng)內核、Docker、K8S這些開源社區(qū)的系統(tǒng)軟件，存在一種觀點是：我們不

22、需要自己分析問題，只需要拿社區(qū)的最新更新就行了。但是我們并不認同，我們認為技術團隊自身的能力很重要，主要是如下原因：美團的應用規(guī)模大、場景復雜，很多問題也許很多企業(yè)都沒有遇到過，不能被動的等別人來解答。對于一些實際的業(yè)務問題或者需求（例如容器內正確返回CPU數(shù)目），社區(qū)也許覺得不重要，或者不是正確的理念，可能就不會解決。社區(qū)很多時候只在Upstream解決問題，而Upstream通常不穩(wěn)定，即使有Backport到我們正在使用的版本，排期也很難進行保障。社區(qū)會發(fā)布很多補丁，通常描述都比較晦澀難懂，如果沒有對問題的深刻理解，很難把遇到的實際問題和一系列補丁聯(lián)系起來。對于一些復雜問題，社區(qū)的解決方

23、案不一定適用于我們自身的實際場景，我們需要自身有能力進行判斷和取舍。美團在解決開源系統(tǒng)問題時，一般會經歷五個階段：自己深挖、研發(fā)解決、關注社區(qū)、和社區(qū)交互，最后貢獻給社區(qū)。性能容器平臺性能，主要包括兩個方面性能：業(yè)務服務運行在容器上的性能。容器操作（創(chuàng)建、刪除等等）的性能。上圖是我們CPU分配的一個例子，我們采用的主流服務器是兩路24核服務器，包含兩個Node，每個12核，算上超線程共48顆邏輯CPU。屬于典型的NUMA（非一致訪存）架構：系統(tǒng)中每個Node有自己的內存，Node內的CPU訪問自己的內存的速度，比訪問另一個Node內存的速度快很多（差一倍左右）。過去我們曾經遇到過網絡中斷集中到

24、CPU0上的問題，在大流量下可能導致網絡延時增加甚至丟包。為保證網絡處理能力，我們從Node0上劃出了8顆邏輯CPU用來專門處理網絡中斷和宿主機系統(tǒng)上的任務，例如鏡像解壓這類高CPU的工作，這8顆邏輯CPU不運行任何容器的Workload。在容器調度方面，我們的容器CPU分配盡量不跨Node，實踐證明跨Node訪問內存對應用性能的影響比較大。在一些計算密集型的場景下，容器分配在Node內部會提升30%以上的吞吐量。當然，按Node的分配方案也存在一定的弊端：會導致CPU的碎片增加，為了更高效地利用CPU資源，在實際系統(tǒng)中，我們會根據服務畫像的信息，分配一些對CPU不敏感的服務容器跨Node使用

25、CPU資源。上圖是一個真實的服務在CPU分配優(yōu)化前后，響應延時的TP指標線對比。可以看到TP999線下降了一個數(shù)量級，并且所有的指標都更加平穩(wěn)。性能優(yōu)化：文件系統(tǒng)針對文件系統(tǒng)的性能優(yōu)化，第一步是選型，根據統(tǒng)計到的應用讀寫特征，我們選擇了Ext4文件系統(tǒng)（超過85%的文件讀寫是對小于1M文件的操作）。Ext4文件系統(tǒng)有三種日志模式：Journal：寫數(shù)據前等待Metadata和數(shù)據的日志落盤。Ordered：只記錄Metadata的日志，寫Metadata日志前確保數(shù)據已經落盤。Writeback：僅記錄Metadata日志，不保證數(shù)據比Metadata先落盤。我們選擇了Writeback模式（

26、默認是oderded），它在幾種掛載模式中速度最快，缺點是：發(fā)生故障時數(shù)據不好恢復。我們大部分容器處于無狀態(tài)，故障時在別的機器上再拉起一臺即可。因此我們在性能和穩(wěn)定性中，選擇了性能。容器內部給應用提供可選的基于內存的文件系統(tǒng)tmpfs，可以提升有大量臨時文件讀寫的服務性能。如上圖所示，在美團內部創(chuàng)建一個虛擬機至少經歷三步，平均時間超過300秒。使用鏡像創(chuàng)建容器平均時間23秒。容器的靈活、快速得到了顯著的體現(xiàn)。容器擴容23秒的平均時間包含了各個部分的優(yōu)化，如擴容鏈路優(yōu)化、鏡像分發(fā)優(yōu)化、初始化和業(yè)務拉起優(yōu)化等等。接下來，本文主要介紹一下我們做的鏡像分發(fā)和解壓相關的優(yōu)化。上圖是美團容器鏡像管理的總體

27、架構，其特點如下：存在多個Site。支持跨Site的鏡像同步，根據鏡像的標簽確定是否需要跨Site同步。每個Site有鏡像備份。每個Site內部有實現(xiàn)鏡像分發(fā)的P2P網絡。鏡像分發(fā)是影響容器擴容時長的一個重要環(huán)節(jié)?？鏢ite同步：保證服務器總能從就近的鏡像倉庫拉取到擴容用的鏡像，減少拉取時間，降低跨Site帶寬消耗?；A鏡像預分發(fā)：美團的基礎鏡像是構建業(yè)務鏡像的公共鏡像，通常有幾百兆的大小。業(yè)務鏡像層是業(yè)務的應用代碼，通常比基礎鏡像小很多。在容器擴容的時候如果基礎鏡像已經在本地，只需要拉取業(yè)務鏡像的部分，可以明顯地加快擴容速度。為達到這樣的效果，我們會把基礎鏡像事先分發(fā)到所有的服務器上。P2P鏡像分發(fā)：基礎鏡像預分發(fā)在有些場景會導致上千個服務器同時從鏡像倉庫拉取鏡像，對鏡像倉庫服務和帶寬帶來很大的壓力。因此我們開發(fā)了鏡像P2P分發(fā)的功能，服務器不僅能從鏡像倉庫中拉取鏡像，還能從其他服務器上獲取鏡像的分片。從上圖可以看出，隨著分發(fā)服務器數(shù)目的增加，原有分發(fā)時間也快速增加，而P2P鏡像分發(fā)時間基本上保持穩(wěn)定。Docker的鏡像拉取是一個并行下載，串行解壓的過程，為了提升解壓的速度，我們美團也做了一些優(yōu)化工作。對于單個層的解壓，我們使用并行解壓算法替換Docker默認的串行解壓算法，實現(xiàn)上是使用pgzip替換gzip。Docker的鏡像具有分層結構，對鏡像層的合并是一個“解壓一層