「運維」一文講清 K8s 如何改變美團的雲基礎設施

Kubernetes已經成為美團雲基礎設施的管理引擎，它帶來的不僅僅是高效的資源管理，同時也大幅降低了成本，而且為美團雲原生架構的推進打下了堅實的基礎，支援了Serverless、雲原生分布式資料庫等一些平台完成容器化和雲原生化的建設。歡迎閱讀~

一、背景與現狀

Kubernetes是讓容器應用進入大規模工業生産環境的開源系統，也是叢集排程領域的事實标準，目前已被業界廣泛接受并得到了大規模的應用。

從2013年開始，美團就以虛拟化技術為核心建構了雲基礎設施平台；2016年，開始探索容器技術并在内部進行落地，在原有OpenStack的資源管理能力之上建構了Hulk1.0容器平台；2018年，美團開始打造以Kubernetes技術為基礎的Hulk2.0平台；2019年年底，我們基本完成了美團雲基礎設施的容器化改造；2020年，我們堅信Kubernetes才是未來的雲基礎設施标準，又開始探索雲原生架構落地和演進。

目前，我們建構了以Kubernetes、Docker等技術為代表的雲基礎設施，支援整個美團的服務和應用管理，容器化率達到98%以上，目前已有數十個大小Kubernetes叢集，數萬的管理節點以及幾十萬的Pod。不過出于容災考慮，我們最大單叢集設定為5K個節點。

下圖是目前我們基于Kubrnetes引擎的排程系統架構，建構了以Kubernetes為核心的統一的資源管理系統，服務于各個PaaS平台和業務。除了直接支援Hulk容器化之外，也直接支援了Serverless、Blade等平台，實作了PaaS平台的容器化和雲原生化。

二、OpenStack到Kubernetes轉變的障礙和收益

對于一個技術棧比較成熟的公司而言，整個基礎設施的轉變并不是一帆風順的，在OpenStack雲平台時期，我們面臨的主要問題包括以下幾個方面：

• 架構複雜，運維和維護比較困難：OpenStack的整個架構中計算資源的管理子產品是非常龐大和複雜，問題排查和可靠性一直是很大的問題。
• 環境不一緻問題突出：環境不一緻問題是容器鏡像出現之前業界的通用問題，不利于業務的快速上線和穩定性。
• 虛拟化本身資源占用多：虛拟化本身大概占用10%的主控端資源消耗，在叢集規模足夠大的時候，這是一塊非常大的資源浪費。
• 資源傳遞和回收周期長，不易靈活調配：一方面是整個虛拟機建立流程冗長；另一方面各種初始化和配置資源準備耗時長且容易出錯，是以就導緻整個機器資源從申請到傳遞周期長，快速的資源調配是個難題。
• 高低峰明顯，資源浪費嚴重：随着移動網際網路的高速發展，公司業務出現高低峰的時間越來越多，為了保障服務穩定不得不按照最高的資源需求來準備資源，這就導緻低峰時資源空閑嚴重，進而造成浪費。

2.1 容器化的過程和障礙

為了解決虛拟機存在的問題，美團開始探索更加輕量級的容器技術的落地，也就是Hulk1.0項目。不過基于當時的資源環境和架構，Hulk1.0是以原有的OpenStack為基礎資源管理層實作的容器平台，OpenStack提供底層的主控端的資源管理能力，解決了業務對彈性資源的需求，并且整個資源傳遞周期從分鐘級别降低到了秒級。

但是，随着Hulk1.0的推廣和落地，也暴露出一些新的問題：

• 穩定性差：因為複用了OpenStack的底層資源管理能力，整個擴容過程包括兩層的資源排程，且資料同步流程複雜，機房的隔離性也比較差，經常出現一個機房出現問題，其他機房的擴縮容也受到影響。
• 能力欠缺：由于涉及的系統多，并且是跨部門協作，故障節點的遷移和恢複能力不易實作，資源類型也比較單一，整個故障排查和溝通效率低下。
• 擴充性差：Hulk1.0的控制層面對底層資源的管理能力受限，無法根據場景和需求快速擴充。
• 性能：業務對于擴縮容和彈性資源的傳遞速度需求進一步提高，且容器技術的弱隔離性導緻業務的服務受到的幹擾增多，負面回報增加。

上述的問題經過一段時間的優化和改善，始終不能徹底解決。在這種情況下，我們不得不重新思考整個容器平台的架構合理性，而此時Kubernetes已逐漸被業界認可和應用，它清晰的架構和先進的設計思路讓我們看到了希望。是以我們基于Kubernetes建構了新的容器平台，在新的平台中Hulk完全基于原生的Kubernetes API，通過Hulk API來對接内部的釋出部署系統，這樣兩層API将整個架構解耦開來，領域明确，應用管理和資源管理可以獨立疊代，Kubernetes強大的編排和資源管理能力凸顯。

容器化的核心思路是讓Kubernetes做好資源層面的管理，而通過上層的控制層解決對美團應用管理系統和運維系統的依賴問題，保持Kubernetes的原生相容性，減少後續的維護成本，并完成了快速收斂資源管理的需求。同時，也減少了使用者基于新平台的資源申請的學習成本，這點非常重要，也是後續我們能快速大規模遷移基礎設施資源的“基礎”。

2.2 容器化過程的挑戰和應對政策

2.2.1 複雜靈活、動态和可配置的排程政策

美團産品衆多，業務線和應用特點五花八門，是以相應的，我們對于資源類型和排程政策的需求也是非常多。例如，有些業務需要特定的資源類型（SSD、高記憶體、高IO等等），有些業務需要特定的打散政策（例如機房、服務依賴等），是以如何很好地應對這些多樣化的需求，就是一個很大的問題。

為了解決這些問題，我們為擴容鍊路增加了政策引擎，業務可以對自己的應用APPKEY自定義錄入政策需求，同時基于大資料分析的服務畫像，也會根據業務特點和公司的應用管理政策為業務政策推薦，最終這些政策會儲存到政策中心。在擴容過程中，我們會自動為應用的執行個體打上對應的需求标簽，并最終在Kubenretes中生效，完成預期的資源傳遞。

2.2.2 精細化的資源排程和營運

精細化的資源排程和營運，之是以做精細化營運主要是出于兩點考慮：業務的資源需求場景複雜，以及資源不足的情況較多。

我們依托私有雲和公有雲資源，部署多個Kubenretes叢集，這些叢集有些是承載通用業務，有些是為特定應用專有的叢集，在叢集次元對雲端資源進行調配，包括機房的劃分、機型的區分等。在叢集之下，我們又根據不同的業務需要，建設不同業務類型的專區，以便做到資源池的隔離來應對業務的需要。更細的次元，我們針對應用層面的資源需求、容災需求以及穩定性等做叢集層的資源排程，最後基于底層不同硬體以及軟體，實作CPU、MEM和磁盤等更細粒度的資源隔離和排程。

2.2.3 應用穩定性的提升和治理

不管是VM，還是最初的容器平台，在應用穩定性方面一直都存在問題。為此，我們需要在保障應用的SLA上做出更多的努力。

2.2.3.1 容器複用

在生産環境中，主控端的發生重新開機是一種非常常見的場景，可能是主動重新開機也可能是被動，但使用者角度來看，主控端重新開機意味着使用者的一些系統資料就可能丢失，代價還是比較高的。我們需要避免容器的遷移或重建，直接重新開機恢複。但我們都知道，在Kubernetes中，對于Pod中的容器的重新開機政策有以下幾種：Always、OnFailure和Never，主控端重新開機後容器會重新被建立。

為了解決這個問題，我們為容器的重新開機政策類型增加了Reuse政策。流程如下：

• kubelet在SyncPod時，重新開機政策如果是Reuse則會擷取對應Pod已退出狀态的App容器，如果存在則拉起最新的App容器（可能有多個），如果不存在則直接建立。
• 更新App容器映射的pauseID為新的pause容器ID，這樣就建立了Pod下新的pause容器和原先App容器的映射。
• 重新拉起App容器即可完成Pod狀态同步，最終即使主控端重新開機或核心更新，容器資料也不會丢失。

2.2.3.2 Numa感覺與綁定

使用者的另一個痛點與容器性能和穩定性相關。我們不斷收到業務回報，同樣配置的容器性能存在不小的差異，主要表現為部分容器請求延遲很高，經過我們測試和深入分析發現：這些容器存在跨Numa Node通路CPU，在我們将容器的CPU使用限制在同一個Numa Node後問題消失。是以，對于一些延遲敏感型的業務，我們要保證應用性能表現的一緻性和穩定性，需要做到在排程側感覺Numa Node的使用情況。

為了解決這個問題，我們在Node層采集了Numa Node的配置設定情況，在排程器層增加了對Numa Node的感覺和排程，并保證資源使用的均衡性。對于一些強制需要綁定Node的敏感型應用，如果找不到合适的Node則擴容失敗；對于一些不需要綁定Numa Node的應用，則可以選擇盡量滿足的政策。

2.2.3.3 其他穩定性優化

1. 在排程層面，我們為排程器增加了負載感覺和基于服務畫像應用特征的打散和優選政策。
2. 在故障容器發現和處理上，基于特征庫落地的告警自愈元件，能夠秒級發現-分析-處理告警。
3. 對于一些有特殊資源需求，例如高IO、高記憶體等應用采用專區隔離，避免對其他應用造成影響。

2.2.4 平台型業務容器化

相信做過ToB業務的同學應該都了解，任何産品都存在大客戶方案，那麼對于美團這樣的公司，内部也會存在這種情況。平台型業務的容器化有個特點是：執行個體數多，以千或萬計，是以資源成本就比較高；業務地位比較高，一般都是非常核心的業務，對性能和穩定性要求很高。是以，如果想要通過“一招鮮”的方式解決此類業務的問題，就有些不切實際。

這裡，我們以MySQL平台為例，資料庫業務對于穩定性、性能和可靠性要求非常高，業務自己又主要以實體機為主，是以成本壓力非常大。針對資料庫的容器化，我們主要是從主控端端的資源配置設定定制和優化為切入口。

1. 針對CPU資源配置設定，采用獨占CPU集合的方式，避免Pod之間發生争搶。
2. 通過允許自定義SWAP大小來應對短暫的高流量，并關閉Numa Node和PageCache來提升穩定性。
3. 在磁盤配置設定中采用Pod獨占磁盤進行IOPS的隔離，以及通過預配置設定和格式化磁盤來提升擴容的速度，提升資源傳遞效率。
4. 排程支援獨有的打散政策和縮容确認，規避縮容風險。

最終，我們将資料庫的傳遞效率提升了60倍，并且在大多數情況下性能比之前的實體機器還要好。

2.2.5 業務資源優先級保障

對于一個企業而言，基于成本考慮，資源一直會處于不足的狀态，那麼如何保障資源的供給和配置設定就顯得非常重要。

1. 業務預算配額确定資源供給，通過專區來做專有資源專用。
2. 建設彈性資源池和打通公有雲來應對突發資源需求。
3. 按照業務和應用類型的優先級保障資源使用，確定核心業務先拿到資源。
4. 多個Kubenretes叢集和多機房來做容災，應對叢集或機房的故障。

2.2.6 雲原生架構的落地

在遷移到Kubernetes之後，我們進一步實作了雲原生架構的落地。

為了解決雲原生應用管理的障礙，我們設計實作了美團特色的雲原生應用管理引擎——KubeNative，将應用的配置和資訊管理對平台透明化，業務平台隻需要建立原生的Pod資源即可，不需要關注應用的資訊同步和管理細節，并支援各PaaS平台自己來擴充控制層面的能力，運作自己的Operator。

下圖就是目前我們整個的雲原生應用管理架構，已支援Hulk容器平台、Serverless以及TiDB等平台的落地。

2.3 基礎設施遷移後的收益

1. 完成全公司業務98%的容器化，顯著提升了資源管理的效率和業務穩定性。
2. Kubernetes穩定性99.99%以上。
3. Kubernetes成為美團内部叢集管理平台的标準。

三、營運大規模Kubernetes叢集的挑戰和應對政策

在整個基礎設施遷移過程中，除了解決曆史遺留問題和系統建設，随着Kubernetes叢集規模和數量快速增長，我們遇到的新的挑戰是：如何穩定、高效地營運大規模Kubernetes叢集。我們在這幾年的Kubernetes營運中，也逐漸摸索出了一套驗證可行的營運經驗。

3.1 核心元件優化與更新

我們最初使用的Kubernetes是1.6版本，性能和穩定性是比較差的，當我們達到1K節點的時候就逐漸出現問題，達到5K節點時基本叢集不可用。例如，排程性能非常差，叢集吞吐量也比較低，偶爾還發生“雪崩”的情況，擴縮容鍊路耗時也在變長。

針對核心元件的分析和優化，這裡從kube-apiserver、kube-scheduler、etcd以及容器等四個方面來概括下。

1. 針對kube-apiserver，為了減少重新開機過程長時間地發生429請求重試，我們實作了多級的流量控制，将不可用視窗從15min降低為1min，并通過減少和避免外部系統的List操作降低叢集負載，通過内部的VIP來做節點的負載均衡，保障控制節點的穩定性。
2. 在kube-scheduler層，我們增強了排程的感覺政策，排程效果相比之前更穩定；對排程性能的優化提出的預選中斷和局部最優政策也已合并到社群，并成為通用的政策。
3. 針對etcd的營運，通過拆分出獨立的Event叢集降低主庫的壓力，并且基于高配的SSD實體機器部署可以達到日常5倍的高流量通路。
4. 在容器層面，容器複用提升了容器的故障容忍能力，并通過精細化的CPU配置設定提升應用穩定性；通過容器的磁盤預挂載提升Node的故障恢複速度。

另外，社群版本的疊代是非常快的，高版本在穩定性和特性支援上更好，不可避免我們需要進行版本的更新，但如何確定更新成功是一個很大的挑戰，尤其是我們在沒有足夠的Buffer資源進行資源騰挪情況下。

叢集更新，業界通用的方案是直接基于原有叢集更新，方案存在以下幾點問題：

1. 更新版本有限制，不能跨大版本更新：隻能一點點從低版本更新到高版本，耗時費力，而且成功率低。
2. 控制平面更新風險不可控：尤其是有API變更的時候，會覆寫之前的資料，甚至是不可復原的。
3. 使用者有感覺，容器需要建立，成本和影響較高：這個是比較痛的點，無可避免會發生容器建立。

為此，我們深入研究了Kubernetes對容器層面的控制方式，設計實作了一種能夠平滑将容器資料從低版本叢集遷移到高版本叢集的方案，将叢集更新細化為Node粒度的逐個主控端上容器的原地熱更新，随時可以暫停和復原。新方案主要是通過外部工具将Node和Pod資料從低版本叢集遷移到高版本叢集，并解決Pod對象和容器的相容性問題。核心思路是兩點：通過低版本相容高版本的API，通過重新整理容器的Hash保障Pod下的容器不會被新；通過工具實作Pod和Node資源資料從低版本叢集遷移到高版本叢集。

該方案亮點主要包括以下4個方面：

1. 大規模生産環境的叢集更新不再是難題。
2. 解決了現有技術方案風險不可控的問題，風險降到了主控端級别，更新更為安全。
3. 通用性強，可做到任意版本的更新，且方案生命周期長。
4. 優雅地解決了更新過程中容器建立問題，真正做到了原地熱更新。

3.2 平台化與營運效率

大規模的叢集營運是非常有挑戰的事情，滿足業務的快速發展和使用者需求也是對團隊極大的考驗，我們需要從不同緯度的考慮叢集的營運和研發能力。

在Kubernetes與etcd叢集的整個營運和運維能力建設上，我們關注的目标是安全營運、高效運維、标準化管理以及節約成本。是以針對Kubernetes與etcd叢集，我們已經完成了平台化的管理營運，覆寫了特性擴充、性能與穩定性、日常運維、故障恢複、資料營運以及安全管控等6個方面。

對于一個非公有雲業務的Kubernetes團隊，人力還是非常有限的，除了叢集的日常營運還有研發任務，是以我們對于營運效率的提升非常關注。我們将日常運維逐漸的沉澱轉換，建構了一套美團内部的Kubernetes叢集管理平台。

1. 将叢集的管理标準化、可視化，避免了黑白屏的運維操作。
2. 通過告警自愈和自動巡檢将問題處理收斂掉，是以雖然我們有大幾十個叢集，但我們的運維效率還是比較高的，值班同學很少需要關注。
3. 全部的運維操作流程化，不僅提升了運維效率，人為操作導緻的故障的機率也減小了。
4. 通過營運資料的分析進一步做了資源的精細化排程和故障預測，進一步提前發現風險，提升了營運的品質。

3.3 風險控制和可靠性保障

規模大、覆寫業務廣，任何的叢集故障都會直接影響到服務的穩定性甚至使用者的體驗，在經曆了多次運維故障和安全壓力下，我們形成了一套可複制的風險控制和可靠性保障政策。

在整個風險管控鍊路中，我們分為名額、告警、工具、機制&措施和人員5個層面：

1. 名額資料采集，從節點、叢集、元件以及資源層面采集核心名額作為資料源。
2. 風險推送，覆寫核心名額的多級、多元度的告警機制。
3. 在工具支援上，通過主動、被動以及流程化等減少誤操作風險。
4. 機制保障上，打通測試、灰階驗證、釋出确認以及演練等降低疏忽大意的情況。
5. 人是風險的根本，這塊我們一直也在努力建設和輪值，確定問題的響應。

在可靠性驗證和營運方面，我們笃信需要把功夫用在評審，通過叢集巡檢來評估叢集的健康情況，并推送報表；定期的當機演練保障真實故障能夠快速恢複，并将日常問題補全到全鍊路測試中，形成閉環。

四、總結與未來展望

4.1 經驗心得

1. Kubernetes的落地完全相容社群的Kubernetes API；隻會做插件化的擴充，并盡量不改控制層面的原有行為。
2. 對社群的一些特性，取長補短，并且有預期的更新，不盲目更新和跟進社群版本，盡量保持每年度的一個核心穩定版本。
3. 落地以使用者痛點為突破口，業務是比較實際的，為什麼需要進行遷移？業務會怕麻煩、不配合，是以推進要找到業務痛點，從幫助業務的角度出發，效果就會不一樣。
4. 内部的叢集管理營運的價值展現也是很重要的一環，讓使用者看到價值，業務看到潛在的收益，他們會主動來找你。

在容器時代，不能隻看Kubernetes本身，對于企業内的基礎設施，“向上”和“向下”的融合和相容問題也很關鍵。“向上”是面向業務場景為使用者提供對接，因為容器并不能直接服務于業務，它還涉及到如何部署應用、服務治理、排程等諸多層面。“向下”，即容器與基礎設施相結合的問題，這裡更多的是相容資源類型、更強大的隔離性、更高的資源使用效率等都是關鍵問題。

4.2 未來展望

1. 統一排程：VM會少量長期存在一段時間，但如果同時維護兩套基礎設施産品成本是非常高的，是以我們也在落地Kubernetes來統一管理VM和容器。
2. VPA：探索通過VPA來進一步提升整個資源的使用效率。
3. 雲原生應用管理：目前，我們已将雲原生應用管理在生産環境落地，未來我們會進一步擴大雲原生應用的覆寫面，不斷提升研發效率。
4. 雲原生架構落地：推進各個中間件、存儲系統、大資料以及搜尋業務合作落地各個領域的雲原生系統。

文章來源：https://mp.weixin.qq.com/s?__biz=MzI3MzEzMDI1OQ==&mid=2651823600&idx=1&sn=61cd81c8e5039aac72d97baff5616d77&chksm=f0dccb8cc7ab429aad96733c68d72cc5b79ba25de3868c6e0ee92d4d6b7129779e61cccda89c&scene=21#wechat_redirect