背景
作爲國內領先的生活服務平臺，美團點評很多業務都具有非常顯著、規律的”高峯“和”低谷“特徵。尤其遇到節假日或促銷活動，流量還會在短時間內出現爆發式的增長。這對集羣中心的資源彈性和可用性有非常高的要求，同時也會使系統在支撐業務流量時的複雜度和成本支出呈現指數級增長。而我們需要做的，就是利用有限的資源最大化地提升集羣的吞吐能力，以保障用戶體驗。
本文將介紹美團點評Kubernetes集羣管理與使用實踐，包括美團點評集羣管理與調度系統介紹、Kubernetes管理與實踐、Kubernetes優化與改造以及資源管理與優化等。
美團點評集羣管理與調度系統
美團點評在集羣管理和資源優化這條道路上已經“摸爬滾打”多年。2013年，開始構建基於傳統虛擬化技術的資源交付方式；2015年7月，開始建立完善的集羣管理與調度系統——HULK，目標是推動美團點評服務容器化；2016年，完成基於Docker容器技術自研實現了彈性伸縮能力，來提升交付速度和應對快速擴縮容的需求，實現彈性擴容、縮容，提升資源利用率，提升業務運維效率，合理有效的降低企業IT運維成本；2018年，開始基於Kubernetes來進行資源管理和調度，進一步提升資源的使用效率。
最初，美團點評通過基於Docker容器技術自研實現了彈性伸縮能力，主要是爲了解決基於虛擬化技術的管理及部署機制在應對服務快速擴容、縮容需求時存在的諸多不足。例如資源實例創建慢、無法統一運行環境、實例部署和交付流程長、資源回收效率低、彈性能力差等等。經過調研與測試，結合業界的實踐經驗，我們決定基於Docker容器技術自研集羣管理與調度系統，有效應對快速擴縮容的需求，提升資源的利用效率。我們把它叫做"綠巨人"——HULK，這個階段可以看作是HULK1.0。
之後，在生產環境中經過不斷摸索和嘗試，我們逐漸意識到，僅僅滿足於集羣的彈性伸縮能力是不夠的，成本和效率肯定是未來必將面臨且更爲棘手的問題。我們吸取了2年來HULK 1.0的開發和運維經驗，在架構和支撐系統層面做了進一步優化和改進，並藉助於生態和開源的力量來爲HULK賦能，即引入了開源的集羣管理與調度系統Kubernetes，期望能進一步提升集羣管理、運行的效率和穩定性，同時降低資源成本。所以我們從自研平臺轉向了開源的Kubernetes系統，並基於Kubernetes系統打造了更加智能化的集羣管理與調度系統——HULK2.0。
架構全覽
在架構層面，HULK2.0如何能與上層業務和底層Kubernetes平臺更好地分層和解耦，是我們在設計之初就優先考慮的問題。我們期望它既要能對業務使用友好，又能最大限度地發揮Kubernetes的調度能力，使得業務層和使用方毋需關注資源關係細節，所求即所得；同時使發佈、配置、計費、負載等邏輯層與底層的Kubernetes平臺解耦分層，並保持兼容原生Kubernetes API來訪問Kubernetes集羣。從而可以藉助於統一的、主流的、符合業界規範的標準，來解決美團點評基礎架構面臨的複雜的、多樣的、不統一的管理需求。
架構介紹
自上而下來看，美團集羣管理與調度平臺面向全公司服務，有各個主要業務線、統一的OPS平臺以及Portal平臺，HULK不可能針對每個平臺定製化接口和解決方案，所以需要將多樣的業務和需求抽象收斂,最終統一通過HULK API來屏蔽HULK系統的細節，做到HULK與上層業務方的解耦。HULK API是對業務層和資源需求的抽象，是外界訪問HULK的唯一途徑。
解決了上層的問題後，我們再來看與下層Kubernetes平臺的解耦。HULK接到上層資源請求後，首先要進行一系列的初始化工作，包括參數校驗、資源餘量、IP和Hostname的分配等等，之後向Kubernetes平臺實際申請分配機器資源，最終將資源交付給用戶，Kubernetes API進一步將資源需求收斂和轉換，讓我們可以藉助於Kubernetes的資源管理優勢。Kubernetes API旨在收斂HULK的資源管理邏輯並與業界主流對齊。此外，因爲完全兼容Kubernetes API，可以讓我們藉助社區和生態的力量，共同建設和探索。
可以看到，HULK API和Kubernetes API將我們整個系統分爲三層，這樣可以讓每一層都專注於各自的模塊。
Kubernetes管理與實踐
爲什麼會選擇Kubernetes呢？Kubernetes並不是市面上唯一的集羣管理平臺（其他如Docker Swarm或Mesos），之所以選擇它，除了它本身優秀的架構設計，我們更加看重的是Kubernetes提供的不是一個解決方案，而是一個平臺和一種能力。這種能力能夠讓我們真正基於美團點評的實際情況來擴展，同時能夠依賴和複用多年來的技術積累，給予我們更多選擇的自由，包括我們可以快速地部署應用程序，而無須面對傳統平臺所具有的風險，動態地擴展應用程序以及更好的資源分配策略。
Kubernetes集羣作爲整個HULK集羣資源管理與平臺的基礎，需求是穩定性和可擴展性，風險可控性和集羣吞吐能力。
集羣運營現狀
- 集羣規模：10萬+級別線上實例，多地域部署，還在不斷快速增長中。
- 業務的監控告警：集羣對應用的啓動和狀態數據進行採集，container-init自動集成業務監控信息，業務程序毋需關注，做到可插拔、可配置。
- 資源的健康告警：從資源的角度對 Node、Pod和 Container等重要數據監控採集，及時發現它們的狀態信息，例如 Node不可用、Container不斷重啓等等。
- 定時巡檢與對賬：每天自動對所有宿主機進行狀態檢查，包括剩餘磁盤量（數據卷）、D進程數量、宿主機狀態等，並對AppKey擴容數據和實際的Pod和容器數據同步校驗，及時發現不一致情況。
- 集羣數據可視化：對當前集羣狀態，包括宿主機資源狀態、服務數、Pod數、容器化率、服務狀態、擴縮容數據等等可視化；並提供了界面化的服務配置、宿主機下線以及Pod遷移操作入口。
- 容量規劃與預測：提前感知集羣資源狀態，預先準備資源；基於規則和機器學習的方式感知流量和高峯，保證業務正常、穩定、高效地運行。
Kubernetes優化與改造
kube-scheduler性能優化
我們有集羣在使用1.6版本的調度器，隨着集羣規模的不斷增長，舊版本的Kubernetes調度器（1.10之前版本）在性能和穩定性的問題逐漸凸顯，由於調度器的吞吐量低，導致業務擴容超時失敗，在規模近3000臺的集羣上，一次Pod的調度耗時在5s左右。Kubernetes的調度器是隊列化的調度器模型，一旦擴容高峯等待的Pod數量過多就會導致後面Pod的擴容超時。爲此，我們對調度器性能進行了大幅度的優化，並取得了非常明顯的提升，根據我們的實際生產環境驗證，性能比優化前提升了400%以上。
Kubernetes調度器工作模型如下：
（kubernetes調度器，圖片來源於網絡）
預選失敗中斷機制
一次調度過程在判斷一個 Node是否可作爲目標機器時，主要分爲三個階段：
- 預選階段：硬性條件，過濾掉不滿足條件的節點，這個過程稱爲 Predicates。這是固定先後順序的一系列過濾條件，任何一個 Predicate不符合則放棄該 Node。
- 優選階段：軟性條件，對通過的節點按照優先級排序，稱之爲 Priorities。每一個Priority都是一個影響因素，都有一定的權重。
- 選定階段：從優選列表中選擇優先級最高的節點，稱爲 Select。選擇的Node即爲最終部署Pod的機器。
通過深入分析調度過程可以發現，調度器在預選階段即使已經知道當前 Node不符合某個過濾條件仍然會繼續判斷後續的過濾條件是否符合。試想如果有上萬臺 Node節點，這些判斷邏輯會浪費很多計算時間，這也是調度器性能低下的一個重要因素。
爲此，我們提出了“預選失敗中斷機制”，即一旦某個預選條件不滿足，那麼該 Node即被立即放棄，後面的預選條件不再做判斷計算，從而大大減少了計算量，調度性能也大大提升。如下圖所示：
我們把該項優化貢獻給了 Kubernetes社區(詳見PR)，增加了 alwaysCheckAllPredicates 策略選項，並在 Kubernetes1.10版本發佈並開始作爲默認的調度策略，當然你也可以通過設置alwaysCheckAllPredicates=true使用原先的調度策略。
在實際測試中，調度器至少可以提升40%的性能，如果你目前在使用的Kube-scheduler的版本低於1.10，那麼建議你嘗試升級到新的版本。
局部最優解
對於優化問題尤其是最優化問題，我們總希望找到全局最優的解或策略，但是當問題的複雜度過高，要考慮的因素和處理的信息量過多時，我們往往會傾向於接受局部最優解，因爲局部最優解的質量不一定都是差的。尤其是當我們有確定的評判標準，同時標明得出的解是可以接受的話，通常會接收局部最優的結果。這樣，從成本、效率等多方面考慮，纔是我們在實際工程中真正會採取的策略。
（圖片來源於網絡）
當前調度策略中，每次調度調度器都會遍歷集羣中所有的Node，以便找出最優的節點，這在調度領域稱之爲BestFit算法。但是在生產環境中，我們是選取最優Node還是次優Node，其實並沒有特別大的區別和影響，有時候我們還是會避免選取最優的Node（例如我們集羣爲了解決新上線機器後頻繁在該機器上創建應用的問題，就將最優解隨機化）。換句話說，找出局部最優解就能滿足需求。
假設集羣一共1000個Node，一次調度過程PodA，這其中有700個Node都能通過Predicates（預選階段），那麼我們就會把所有的Node遍歷並找出這700個Node，然後經過得分排序找出最優的Node節點NodeX。但是採用局部最優算法，即我們認爲只要能找出N個Node，並在這N個Node中選擇得分最高的Node即能滿足需求，比如默認找出100個可以通過Predicates（預選階段）的Node即可，最優解就在這100個Node中選擇。當然全局最優解NodeX也可能不在這100個Node中，但是我們在這100個Node中選擇最優的NodeY也能滿足要求。最好的情況是遍歷100個Node就找出這100個Node，也可能遍歷了200個或者300個Node等等，這樣我們可以大大減少計算時間，同時也不會對我們的調度結果產生太大的影響。
局部最優的策略是我們與社區合作共同完成的，這裏面還涉及到如何做到公平調度和計算任務優化的細節(詳見PR1,PR2)，該項優化在Kubernetes 1.12版本中發佈，並作爲當前默認調度策略，可以大幅度提升調度性能，尤其在大規模集羣中的提升，效果非常明顯。
kubelet改造
風險可控性
前面提到，穩定性和風險可控性對大規模集羣管理來說非常重要。從架構上來看，Kubelet是離真實業務最近的集羣管理組件，我們知道社區版本的Kubelet對本機資源管理有着很大的自主性，試想一下，如果某個業務正在運行，但是Kubelet由於出發了驅逐策略而把這個業務的容器幹掉了會發生什麼？這在我們的集羣中是不應該發生的，所以需要收斂和封鎖Kubelet的自決策能力，它對本機上業務容器的操作都應該從上層平臺發起。
容器重啓策略
Kernel升級是日常的運維操作，在通過重啓宿主機來升級Kernel版本的時候，我們發現宿主機重啓後，上面的容器無法自愈或者自愈後版本不對，這會引發業務的不滿，也造成了我們不小的運維壓力。後來我們爲Kubelet增加了一個重啓策略（Reuse），同時保留了原生重啓策略（Rebuild），保證容器系統盤和數據盤的信息都能保留，宿主機重啓後容器也能自愈。
IP狀態保持
根據美團點評的網絡環境，我們自研了CNI插件，並通過基於Pod唯一標識來申請和複用IP。做到了應用IP在Pod遷移和容器重啓之後也能複用，爲業務上線和運維帶來了不少的收益。
限制驅逐策略
我們知道Kubelet擁有節點自動修復的能力，例如在發現異常容器或不合規容器後，會對它們進行驅逐刪除操作，這對於我們來說風險太大，我們允許容器在一些次要因素方面可以不合規。例如當Kubelet發現當前宿主機上容器個數比設置的最大容器個數大時，會挑選驅逐和刪除某些容器，雖然正常情況下不會輕易發生這種問題，但是我們也需要對此進行控制，降低此類風險。
可擴展性
資源調配
在Kubelet的擴展性方面我們增強了資源的可操作性，例如爲容器綁定Numa從而提升應用的穩定性；根據應用等級爲容器設置CPUShare，從而調整調度權重；爲容器綁定CPUSet等等。
增強容器
我們打通並增強了業務對容器的配置能力，支持業務給自己的容器擴展ulimit、io limit、pid limit、swap等參數的同時也增強容器之間的隔離能力。
應用原地升級
大家都知道，Kubernetes默認只要Pod的關鍵信息有改動，例如鏡像信息，就會出發Pod的重建和替換，這在生產環境中代價是很大的，一方面IP和HostName會發生改變，另一方面頻繁的重建也給集羣管理帶來了更多的壓力，甚至還可能導致無法調度成功。爲了解決該問題，我們打通了自上而下的應用原地升級功能，即可以動態高效地修改應用的信息，並能在原地（宿主機）進行升級。
鏡像分發
鏡像分發是影響容器擴容時長的一個重要環節，我們採取了一系列手段來優化，保證鏡像分發效率高且穩定：
- 跨Site同步：保證服務器總能從就近的鏡像倉庫拉取到擴容用的鏡像，減少拉取時間，降低跨Site帶寬消耗。
- 基礎鏡像預分發：美團點評的基礎鏡像是構建業務鏡像的公共鏡像。業務鏡像層是業務的應用代碼，通常比基礎鏡像小很多。在容器擴容的時候如果基礎鏡像已經在本地，就只需要拉取業務鏡像的部分，可以明顯的加快擴容速度。爲達到這樣的效果，我們會把基礎鏡像事先分發到所有的服務器上。
- P2P鏡像分發：基礎鏡像預分發在有些場景會導致上千個服務器同時從鏡像倉庫拉取鏡像，對鏡像倉庫服務和帶寬帶來很大的壓力。因此我們開發了鏡像P2P分發的功能，服務器不僅能從鏡像倉庫中拉取鏡像，還能從其他服務器上獲取鏡像的分片。
資源管理與優化
優化關鍵技術
- 服務畫像：對應用的CPU、內存、網絡、磁盤和網絡 I/O 容量和負載畫像，瞭解應用的特徵、資源規格和應用類型以及不同時間對資源的真實使用，然後從服務角度和時間維度進行相關性分析，從而進行整體調度和部署優化。
- 親和性和互斥性：哪些應用放在一起使整體計算能力比較少而吞吐能力比較高，它們就存在一定親和性；反之如果應用之間存在資源競爭或相互影響，則它們之間就存在着互斥性。
- 場景優先：美團點評的業務大都是基本穩定的場景，所以場景劃分很有必要。例如一類業務對延遲非常敏感，即使在高峯時刻也不允許有太多的資源競爭產生，這種場景就要避免和減少資源競爭引起的延遲，保證資源充足；一類業務在有些時間段需要的CPU資源可能會突破配置的上限，我們通過CPU Set化的方式讓這類業務共享這部分資源，以便能夠突破申請規格的機器資源限制，不僅服務能夠獲得更高的性能表現，同時也把空閒的資源利用了起來，資源使用率進一步提升。
- 彈性伸縮：應用部署做到流量預測、自動伸縮、基於規則的高低峯伸縮以及基於機器學習的伸縮機制。
- 精細化資源調配：基於資源共享和隔離技術做到了精細化的資源調度和分配，例如Numa綁定、任務優先級、CPU Set化等等。
策略優化
調度策略的主要作用在兩方面，一方面是按照既定策略部署目標機器；二是能做到集羣資源的排布最優。
- 親和性：有調用關係和依賴的應用，或哪些應用放在一起能使整體計算能力比較少、吞吐能力比較高，這些應用間就存在一定親和性。我們的CPU Set化即是利用了對CPU的偏好構建應用的親和性約束，讓不同CPU偏好的應用互補。
- 互斥性：跟親和性相對，主要是對有競爭關係或業務干擾的應用在調度時儘量分開部署。
- 應用優先級：應用優先級的劃分是爲我們解決資源競爭提供了前提。當前當容器發生資源競爭時，我們無法決策究竟應該讓誰獲得資源，當有了應用優先級的概念後，我們可以做到，在調度層，限制單臺宿主機上重要應用的個數，減少單機的資源競爭，也爲單機底層解決資源競爭提供可能；在宿主機層，根據應用優先級分配資源，保證重要應用的資源充足，同時也可運行低優先級應用。
- 打散性：應用的打散主要是爲了容災，在這裏分爲不同級別的打散。我們提供了不同級別的打散粒度，包括宿主機、Tor、機房、Zone等等。
- 隔離與獨佔：這是一類特殊的應用，必須是獨立使用一臺宿主機或虛擬機隔離環境部署，例如搜索團隊的業務。
- 特殊資源：特殊資源是滿足某些業務對GPU、SSD、特殊網卡等特殊硬件需求。
在線集羣優化
在線集羣資源的優化問題，不像離線集羣那樣可以通過預知資源需求從而達到非常好的效果，由於未來需求的未知性，在線集羣很難在資源排布上達到離線集羣的效果。針對在線集羣的問題，我們從上層調度到底層的資源使用都採取了一系列的優化。
- Numa綁定：主要是解決業務側反饋服務不穩定的問題，通過綁定Numa，將同一個應用的CPU和Memory綁定到最合適的Numa Node上，減少跨Node訪問的開銷，提升應用性能。
- CPU Set化：將一組特性互補的應用綁定在同一組CPU上，從而讓他們能充分使用CPU資源。
- 應用錯峯：基於服務畫像數據爲應用錯開高峯，減少資源競爭和相互干擾，提升業務SLA。
- 重調度：資源排布優化，用更少的資源提升業務性能和SLA；解決碎片問題，提升資源的分配率。
- 干擾分析：基於業務監控數據指標和容器信息判斷哪些容器有異常，提升業務SLA，發現並處理異常應用。
結束語
當前，在以下幾個方面我們正在積極探索：
- 在線-離線業務混合部署，進一步提升資源使用效率。
- 智能化調度，業務流量和資源使用感知調度，提升服務SLA。
- 高性能、強隔離和更安全的容器技術。
作者簡介
國樑，美團點評基礎研發平臺集羣調度中心高級工程師。
團隊信息
美團點評基礎研發平臺集羣調度中心，致力於打造高效的業界領先的集羣管理與調度平臺，通過企業級集羣管理平臺建設業界領先的雲化解決方案，提高集羣管理能力和穩定性，同時降低IT成本，加速公司的創新發展。同時隨着Kubernetes已經成爲業界的事實標準，美團點評也在逐步擁抱社區，參與開源並且在集羣調度領域已經取得很大進展，也期待和業界同仁一起努力，共同提高集羣管理和調度能力，降低整個行業的IT成本，協同創新發展。美團點評基礎研發平臺長期招聘集羣管理與調度、彈性調度、Kubernetes以及Linux內核方面的人才，歡迎有興趣的同學加入。