美團點評Kubernetes集羣管理實踐

背景

做爲國內領先的生活服務平臺，美團點評不少業務都具備很是顯著、規律的」高峯「和」低谷「特徵。尤爲遇到節假日或促銷活動，流量還會在短期內出現爆發式的增加。這對集羣中心的資源彈性和可用性有很是高的要求，同時也會使系統在支撐業務流量時的複雜度和成本支出呈現指數級增加。而咱們須要作的，就是利用有限的資源最大化地提高集羣的吞吐能力，以保障用戶體驗。

本文將介紹美團點評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內核方面的人才，有興趣的同窗能夠發送簡歷到tech@meituan.com。