Kubernetes是如何改變云基礎設施

這篇文章給大家介紹Kubernetes是如何改變云基礎設施，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

一、背景與現狀

Kubernetes是讓容器應用進入大規模工業生產環境的開源系統，也是集群調度領域的事實標準，目前已被業界廣泛接受并得到了大規模的應用。Kubernetes已經成為美團云基礎設施的管理引擎，它帶來的不僅僅是高效的資源管理，同時也大幅降低了成本，而且為美團云原生架構的推進打下了堅實的基礎，支持了Serverless、云原生分布式數據庫等一些平臺完成容器化和云原生化的建設。

從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云平臺時期，我們面臨的主要問題包括以下幾個方面：

1. 架構復雜，運維和維護比較困難：OpenStack的整個架構中計算資源的管理模塊是非常龐大和復雜，問題排查和可靠性一直是很大的問題。

2. 環境不一致問題突出：環境不一致問題是容器鏡像出現之前業界的通用問題，不利于業務的快速上線和穩定性。

3. 虛擬化本身資源占用多：虛擬化本身大概占用10%的宿主機資源消耗，在集群規模足夠大的時候，這是一塊非常大的資源浪費。

4. 資源交付和回收周期長，不易靈活調配：一方面是整個虛擬機創建流程冗長；另一方面各種初始化和配置資源準備耗時長且容易出錯，所以就導致整個機器資源從申請到交付周期長，快速的資源調配是個難題。

5. 高低峰明顯，資源浪費嚴重：隨著移動互聯網的高速發展，公司業務出現高低峰的時間越來越多，為了保障服務穩定不得不按照最高的資源需求來準備資源，這就導致低峰時資源空閑嚴重，進而造成浪費。

2.1 容器化的過程和障礙

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

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

1. 穩定性差：因為復用了OpenStack的底層資源管理能力，整個擴容過程包括兩層的資源調度，且數據同步流程復雜，機房的隔離性也比較差，經常出現一個機房出現問題，其他機房的擴縮容也受到影響。

2. 能力欠缺：由于涉及的系統多，并且是跨部門協作，故障節點的遷移和恢復能力不易實現，資源類型也比較單一，整個故障排查和溝通效率低下。

3. 擴展性差：Hulk1.0的控制層面對底層資源的管理能力受限，無法根據場景和需求快速擴展。

4. 性能：業務對于擴縮容和彈性資源的交付速度需求進一步提高，且容器技術的弱隔離性導致業務的服務受到的干擾增多，負面反饋增加。

上述的問題經過一段時間的優化和改善，始終不能徹底解決。在這種情況下，我們不得不重新思考整個容器平臺的架構合理性，而此時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策略。流程如下：

1. kubelet在SyncPod時，重啟策略如果是Reuse則會獲取對應Pod已退出狀態的App容器，如果存在則拉起最新的App容器（可能有多個），如果不存在則直接新建。

2. 更新App容器映射的pauseID為新的pause容器ID，這樣就建立了Pod下新的pause容器和原先App容器的映射。

3. 重新拉起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. 內部的集群管理運營的價值展現也是很重要的一環，讓用戶看到價值，業務看到潛在的收益，他們會主動來找你。

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

4.2 未來展望

1. 統一調度：VM會少量長期存在一段時間，但如果同時維護兩套基礎設施產品成本是非常高的，所以我們也在落地Kubernetes來統一管理VM和容器。

2. VPA：探索通過VPA來進一步提升整個資源的使用效率。

3. 云原生應用管理：當前，我們已將云原生應用管理在生產環境落地，未來我們會進一步擴大云原生應用的覆蓋面，不斷提升研發效率。

4. 云原生架構落地：推進各個中間件、存儲系統、大數據以及搜索業務合作落地各個領域的云原生系統。

關于Kubernetes是如何改變云基礎設施就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。