K8s如何改變美團(tuán)的云基礎(chǔ)設(shè)施？

一、背景與現(xiàn)狀

Kubernetes是讓容器應(yīng)用進(jìn)入大規(guī)模工業(yè)生產(chǎn)環(huán)境的開源系統(tǒng)，也是集群調(diào)度領(lǐng)域的事實標(biāo)準(zhǔn)，目前已被業(yè)界廣泛接受并得到了大規(guī)模的應(yīng)用。

從2013年開始，美團(tuán)就以虛擬化技術(shù)為核心構(gòu)建了云基礎(chǔ)設(shè)施平臺；2016年，開始探索容器技術(shù)并在內(nèi)部進(jìn)行落地，在原有OpenStack的資源管理能力之上構(gòu)建了Hulk1.0容器平臺；2018年，美團(tuán)開始打造以Kubernetes技術(shù)為基礎(chǔ)的Hulk2.0平臺；2019年年底，我們基本完成了美團(tuán)云基礎(chǔ)設(shè)施的容器化改造；2020年，我們堅信Kubernetes才是未來的云基礎(chǔ)設(shè)施標(biāo)準(zhǔn)，又開始探索云原生架構(gòu)落地和演進(jìn)。

當(dāng)前，我們構(gòu)建了以Kubernetes、Docker等技術(shù)為代表的云基礎(chǔ)設(shè)施，支持整個美團(tuán)的服務(wù)和應(yīng)用管理，容器化率達(dá)到98%以上，目前已有數(shù)十個大小Kubernetes集群，數(shù)萬的管理節(jié)點以及幾十萬的Pod。不過出于容災(zāi)考慮，我們最大單集群設(shè)置為5K個節(jié)點。

下圖是當(dāng)前我們基于Kubrnetes引擎的調(diào)度系統(tǒng)架構(gòu)，構(gòu)建了以Kubernetes為核心的統(tǒng)一的資源管理系統(tǒng)，服務(wù)于各個PaaS平臺和業(yè)務(wù)。除了直接支持Hulk容器化之外，也直接支持了Serverless、Blade等平臺，實現(xiàn)了PaaS平臺的容器化和云原生化。

二、OpenStack到Kubernetes轉(zhuǎn)變的障礙和收益

對于一個技術(shù)棧比較成熟的公司而言，整個基礎(chǔ)設(shè)施的轉(zhuǎn)變并不是一帆風(fēng)順的，在OpenStack云平臺時期，我們面臨的主要問題包括以下幾個方面：

• 架構(gòu)復(fù)雜，運(yùn)維和維護(hù)比較困難 ：OpenStack的整個架構(gòu)中計算資源的管理模塊是非常龐大和復(fù)雜，問題排查和可靠性一直是很大的問題。
• 環(huán)境不一致問題突出 ：環(huán)境不一致問題是容器鏡像出現(xiàn)之前業(yè)界的通用問題，不利于業(yè)務(wù)的快速上線和穩(wěn)定性。
• 虛擬化本身資源占用多 ：虛擬化本身大概占用10%的宿主機(jī)資源消耗，在集群規(guī)模足夠大的時候，這是一塊非常大的資源浪費。
• 資源交付和回收周期長，不易靈活調(diào)配 ：一方面是整個虛擬機(jī)創(chuàng)建流程冗長；另一方面各種初始化和配置資源準(zhǔn)備耗時長且容易出錯，所以就導(dǎo)致整個機(jī)器資源從申請到交付周期長，快速的資源調(diào)配是個難題。

• 高低峰明顯，資源浪費嚴(yán)重：隨著移動互聯(lián)網(wǎng)的高速發(fā)展，公司業(yè)務(wù)出現(xiàn)高低峰的時間越來越多，為了保障服務(wù)穩(wěn)定不得不按照最高的資源需求來準(zhǔn)備資源，這就導(dǎo)致低峰時資源空閑嚴(yán)重，進(jìn)而造成浪費。

2.1 容器化的過程和障礙

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

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

• 穩(wěn)定性差 ：因為復(fù)用了OpenStack的底層資源管理能力，整個擴(kuò)容過程包括兩層的資源調(diào)度，且數(shù)據(jù)同步流程復(fù)雜，機(jī)房的隔離性也比較差，經(jīng)常出現(xiàn)一個機(jī)房出現(xiàn)問題，其他機(jī)房的擴(kuò)縮容也受到影響。
• 能力欠缺 ：由于涉及的系統(tǒng)多，并且是跨部門協(xié)作，故障節(jié)點的遷移和恢復(fù)能力不易實現(xiàn)，資源類型也比較單一，整個故障排查和溝通效率低下。
• 擴(kuò)展性差 ：Hulk1.0的控制層面對底層資源的管理能力受限，無法根據(jù)場景和需求快速擴(kuò)展。
• 性能 ：業(yè)務(wù)對于擴(kuò)縮容和彈性資源的交付速度需求進(jìn)一步提高，且容器技術(shù)的弱隔離性導(dǎo)致業(yè)務(wù)的服務(wù)受到的干擾增多，負(fù)面反饋增加。

容器化的核心思路是讓Kubernetes做好資源層面的管理，而通過上層的控制層解決對美團(tuán)應(yīng)用管理系統(tǒng)和運(yùn)維系統(tǒng)的依賴問題，保持Kubernetes的原生兼容性，減少后續(xù)的維護(hù)成本，并完成了快速收斂資源管理的需求。同時，也減少了用戶基于新平臺的資源申請的學(xué)習(xí)成本，這點非常重要，也是后續(xù)我們能快速大規(guī)模遷移基礎(chǔ)設(shè)施資源的“基礎(chǔ)”。

2.2 容器化過程的挑戰(zhàn)和應(yīng)對策略

2.2.1 復(fù)雜靈活、動態(tài)和可配置的調(diào)度策略

美團(tuán)產(chǎn)品眾多，業(yè)務(wù)線和應(yīng)用特點五花八門，所以相應(yīng)的，我們對于資源類型和調(diào)度策略的需求也是非常多。例如，有些業(yè)務(wù)需要特定的資源類型（SSD、高內(nèi)存、高IO等等），有些業(yè)務(wù)需要特定的打散策略（例如機(jī)房、服務(wù)依賴等），所以如何很好地應(yīng)對這些多樣化的需求，就是一個很大的問題。

為了解決這些問題，我們?yōu)閿U(kuò)容鏈路增加了策略引擎，業(yè)務(wù)可以對自己的應(yīng)用APPKEY自定義錄入策略需求，同時基于大數(shù)據(jù)分析的服務(wù)畫像，也會根據(jù)業(yè)務(wù)特點和公司的應(yīng)用管理策略為業(yè)務(wù)策略推薦，最終這些策略會保存到策略中心。在擴(kuò)容過程中，我們會自動為應(yīng)用的實例打上對應(yīng)的需求標(biāo)簽，并最終在Kubenretes中生效，完成預(yù)期的資源交付。

2.2.2 精細(xì)化的資源調(diào)度和運(yùn)營

精細(xì)化的資源調(diào)度和運(yùn)營，之所以做精細(xì)化運(yùn)營主要是出于兩點考慮：業(yè)務(wù)的資源需求場景復(fù)雜，以及資源不足的情況較多。

我們依托私有云和公有云資源，部署多個Kubenretes集群，這些集群有些是承載通用業(yè)務(wù)，有些是為特定應(yīng)用專有的集群，在集群維度對云端資源進(jìn)行調(diào)配，包括機(jī)房的劃分、機(jī)型的區(qū)分等。在集群之下，我們又根據(jù)不同的業(yè)務(wù)需要，建設(shè)不同業(yè)務(wù)類型的專區(qū)，以便做到資源池的隔離來應(yīng)對業(yè)務(wù)的需要。更細(xì)的維度，我們針對應(yīng)用層面的資源需求、容災(zāi)需求以及穩(wěn)定性等做集群層的資源調(diào)度，最后基于底層不同硬件以及軟件，實現(xiàn)CPU、MEM和磁盤等更細(xì)粒度的資源隔離和調(diào)度。

2.2.3 應(yīng)用穩(wěn)定性的提升和治理

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

2.2.3.1 容器復(fù)用

在生產(chǎn)環(huán)境中，宿主機(jī)的發(fā)生重啟是一種非常常見的場景，可能是主動重啟也可能是被動，但用戶角度來看，宿主機(jī)重啟意味著用戶的一些系統(tǒng)數(shù)據(jù)就可能丟失，代價還是比較高的。我們需要避免容器的遷移或重建，直接重啟恢復(fù)。但我們都知道，在Kubernetes中，對于Pod中的容器的重啟策略有以下幾種：Always、OnFailure和Never，宿主機(jī)重啟后容器會重新被創(chuàng)建。

為了解決這個問題，我們?yōu)槿萜鞯闹貑⒉呗灶愋驮黾恿薘euse策略。流程如下：

• kubelet在SyncPod時，重啟策略如果是Reuse則會獲取對應(yīng)Pod已退出狀態(tài)的App容器，如果存在則拉起最新的App容器（ 可能有多個 ），如果不存在則直接新建。
• 更新App容器映射的pauseID為新的pause容器ID，這樣就建立了Pod下新的pause容器和原先App容器的映射。

• 重新拉起App容器即可完成Pod狀態(tài)同步，最終即使宿主機(jī)重啟或內(nèi)核升級，容器數(shù)據(jù)也不會丟失。

2.2.3.2 Numa感知與綁定

用戶的另一個痛點與容器性能和穩(wěn)定性相關(guān)。我們不斷收到業(yè)務(wù)反饋，同樣配置的容器性能存在不小的差異，主要表現(xiàn)為部分容器請求延遲很高，經(jīng)過我們測試和深入分析發(fā)現(xiàn)：這些容器存在跨Numa Node訪問CPU，在我們將容器的CPU使用限制在同一個Numa Node后問題消失。所以，對于一些延遲敏感型的業(yè)務(wù)，我們要保證應(yīng)用性能表現(xiàn)的一致性和穩(wěn)定性，需要做到在調(diào)度側(cè)感知Numa Node的使用情況。

為了解決這個問題，我們在Node層采集了Numa Node的分配情況，在調(diào)度器層增加了對Numa Node的感知和調(diào)度，并保證資源使用的均衡性。對于一些強(qiáng)制需要綁定Node的敏感型應(yīng)用，如果找不到合適的Node則擴(kuò)容失?。粚τ谝恍┎恍枰壎∟uma Node的應(yīng)用，則可以選擇盡量滿足的策略。

2.2.3.3 其他穩(wěn)定性優(yōu)化

1. 在調(diào)度層面，我們?yōu)檎{(diào)度器增加了負(fù)載感知和基于服務(wù)畫像應(yīng)用特征的打散和優(yōu)選策略。
2. 在故障容器發(fā)現(xiàn)和處理上，基于特征庫落地的告警自愈組件，能夠秒級發(fā)現(xiàn)-分析-處理告警。

3. 對于一些有特殊資源需求，例如高IO、高內(nèi)存等應(yīng)用采用專區(qū)隔離，避免對其他應(yīng)用造成影響。

2.2.4 平臺型業(yè)務(wù)容器化

相信做過ToB業(yè)務(wù)的同學(xué)應(yīng)該都了解，任何產(chǎn)品都存在大客戶方案，那么對于美團(tuán)這樣的公司，內(nèi)部也會存在這種情況。平臺型業(yè)務(wù)的容器化有個特點是：實例數(shù)多，以千或萬計，所以資源成本就比較高；業(yè)務(wù)地位比較高，一般都是非常核心的業(yè)務(wù)，對性能和穩(wěn)定性要求很高。所以，如果想要通過“一招鮮”的方式解決此類業(yè)務(wù)的問題，就有些不切實際。

這里，我們以MySQL平臺為例，數(shù)據(jù)庫業(yè)務(wù)對于穩(wěn)定性、性能和可靠性要求非常高，業(yè)務(wù)自己又主要以物理機(jī)為主，所以成本壓力非常大。針對數(shù)據(jù)庫的容器化，我們主要是從宿主機(jī)端的資源分配定制和優(yōu)化為切入口。

1. 針對CPU資源分配，采用獨占CPU集合的方式，避免Pod之間發(fā)生爭搶。
2. 通過允許自定義SWAP大小來應(yīng)對短暫的高流量，并關(guān)閉Numa Node和PageCache來提升穩(wěn)定性。
3. 在磁盤分配中采用Pod獨占磁盤進(jìn)行IOPS的隔離，以及通過預(yù)分配和格式化磁盤來提升擴(kuò)容的速度，提升資源交付效率。
4. 調(diào)度支持獨有的打散策略和縮容確認(rèn)，規(guī)避縮容風(fēng)險。

最終，我們將數(shù)據(jù)庫的交付效率提升了60倍，并且在大多數(shù)情況下性能比之前的物理機(jī)器還要好。

2.2.5 業(yè)務(wù)資源優(yōu)先級保障

對于一個企業(yè)而言，基于成本考慮，資源一直會處于不足的狀態(tài)，那么如何保障資源的供給和分配就顯得非常重要。

1. 業(yè)務(wù)預(yù)算配額確定資源供給，通過專區(qū)來做專有資源專用。
2. 建設(shè)彈性資源池和打通公有云來應(yīng)對突發(fā)資源需求。
3. 按照業(yè)務(wù)和應(yīng)用類型的優(yōu)先級保障資源使用，確保核心業(yè)務(wù)先拿到資源。

4. 多個Kubenretes集群和多機(jī)房來做容災(zāi)，應(yīng)對集群或機(jī)房的故障。

2.2.6 云原生架構(gòu)的落地

在遷移到Kubernetes之后，我們進(jìn)一步實現(xiàn)了云原生架構(gòu)的落地。

為了解決云原生應(yīng)用管理的障礙，我們設(shè)計實現(xiàn)了美團(tuán)特色的云原生應(yīng)用管理引擎——KubeNative，將應(yīng)用的配置和信息管理對平臺透明化，業(yè)務(wù)平臺只需要創(chuàng)建原生的Pod資源即可，不需要關(guān)注應(yīng)用的信息同步和管理細(xì)節(jié)，并支持各PaaS平臺自己來擴(kuò)展控制層面的能力，運(yùn)行自己的Operator。

下圖就是目前我們整個的云原生應(yīng)用管理架構(gòu)，已支持Hulk容器平臺、Serverless以及TiDB等平臺的落地。

2.3 基礎(chǔ)設(shè)施遷移后的收益

1. 完成全公司業(yè)務(wù)98%的容器化，顯著提升了資源管理的效率和業(yè)務(wù)穩(wěn)定性。
2. Kubernetes穩(wěn)定性99.99%以上。

3. Kubernetes成為美團(tuán)內(nèi)部集群管理平臺的標(biāo)準(zhǔn)。

三、運(yùn)營大規(guī)模Kubernetes集群的挑戰(zhàn)和應(yīng)對策略

在整個基礎(chǔ)設(shè)施遷移過程中，除了解決歷史遺留問題和系統(tǒng)建設(shè)，隨著Kubernetes集群規(guī)模和數(shù)量快速增長，我們遇到的新的挑戰(zhàn)是：如何穩(wěn)定、高效地運(yùn)營大規(guī)模Kubernetes集群。我們在這幾年的Kubernetes運(yùn)營中，也逐漸摸索出了一套驗證可行的運(yùn)營經(jīng)驗。

3.1 核心組件優(yōu)化與升級

我們最初使用的Kubernetes是1.6版本，性能和穩(wěn)定性是比較差的，當(dāng)我們達(dá)到1K節(jié)點的時候就逐漸出現(xiàn)問題，達(dá)到5K節(jié)點時基本集群不可用。例如，調(diào)度性能非常差，集群吞吐量也比較低，偶爾還發(fā)生“雪崩”的情況，擴(kuò)縮容鏈路耗時也在變長。

針對核心組件的分析和優(yōu)化，這里從kube-apiserver、kube-scheduler、etcd以及容器等四個方面來概括下。

1. 針對kube-apiserver，為了減少重啟過程長時間地發(fā)生429請求重試，我們實現(xiàn)了多級的流量控制，將不可用窗口從15min降低為1min，并通過減少和避免外部系統(tǒng)的List操作降低集群負(fù)載，通過內(nèi)部的VIP來做節(jié)點的負(fù)載均衡，保障控制節(jié)點的穩(wěn)定性。
2. 在kube-scheduler層，我們增強(qiáng)了調(diào)度的感知策略，調(diào)度效果相比之前更穩(wěn)定；對調(diào)度性能的優(yōu)化提出的預(yù)選中斷和局部最優(yōu)策略也已合并到社區(qū)，并成為通用的策略。
3. 針對etcd的運(yùn)營，通過拆分出獨立的Event集群降低主庫的壓力，并且基于高配的SSD物理機(jī)器部署可以達(dá)到日常5倍的高流量訪問。
4. 在容器層面，容器復(fù)用提升了容器的故障容忍能力，并通過精細(xì)化的CPU分配提升應(yīng)用穩(wěn)定性；通過容器的磁盤預(yù)掛載提升Node的故障恢復(fù)速度。

另外，社區(qū)版本的迭代是非常快的，高版本在穩(wěn)定性和特性支持上更好，不可避免我們需要進(jìn)行版本的升級，但如何確保升級成功是一個很大的挑戰(zhàn)，尤其是我們在沒有足夠的Buffer資源進(jìn)行資源騰挪情況下。

集群升級，業(yè)界通用的方案是直接基于原有集群升級，方案存在以下幾點問題：

1. 升級版本有限制，不能跨大版本升級：只能一點點從低版本升級到高版本，耗時費力，而且成功率低。
2. 控制平面升級風(fēng)險不可控：尤其是有API變更的時候，會覆蓋之前的數(shù)據(jù)，甚至是不可回滾的。

3. 用戶有感知，容器需要新建，成本和影響較高：這個是比較痛的點，無可避免會發(fā)生容器新建。

為此，我們深入研究了Kubernetes對容器層面的控制方式，設(shè)計實現(xiàn)了一種能夠平滑將容器數(shù)據(jù)從低版本集群遷移到高版本集群的方案，將集群升級細(xì)化為Node粒度的逐個宿主機(jī)上容器的原地?zé)嵘?，隨時可以暫停和回滾。新方案主要是通過外部工具將Node和Pod數(shù)據(jù)從低版本集群遷移到高版本集群，并解決Pod對象和容器的兼容性問題。核心思路是兩點：通過低版本兼容高版本的API，通過刷新容器的Hash保障Pod下的容器不會被新；通過工具實現(xiàn)Pod和Node資源數(shù)據(jù)從低版本集群遷移到高版本集群。

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

1. 大規(guī)模生產(chǎn)環(huán)境的集群升級不再是難題。
2. 解決了現(xiàn)有技術(shù)方案風(fēng)險不可控的問題，風(fēng)險降到了宿主機(jī)級別，升級更為安全。
3. 通用性強(qiáng)，可做到任意版本的升級，且方案生命周期長。

4. 優(yōu)雅地解決了升級過程中容器新建問題，真正做到了原地?zé)嵘墶?/span>

3.2 平臺化與運(yùn)營效率

大規(guī)模的集群運(yùn)營是非常有挑戰(zhàn)的事情，滿足業(yè)務(wù)的快速發(fā)展和用戶需求也是對團(tuán)隊極大的考驗，我們需要從不同緯度的考慮集群的運(yùn)營和研發(fā)能力。

在Kubernetes與etcd集群的整個運(yùn)營和運(yùn)維能力建設(shè)上，我們關(guān)注的目標(biāo)是安全運(yùn)營、高效運(yùn)維、標(biāo)準(zhǔn)化管理以及節(jié)約成本。所以針對Kubernetes與etcd集群，我們已經(jīng)完成了平臺化的管理運(yùn)營，覆蓋了特性擴(kuò)展、性能與穩(wěn)定性、日常運(yùn)維、故障恢復(fù)、數(shù)據(jù)運(yùn)營以及安全管控等6個方面。

對于一個非公有云業(yè)務(wù)的Kubernetes團(tuán)隊，人力還是非常有限的，除了集群的日常運(yùn)營還有研發(fā)任務(wù)，所以我們對于運(yùn)營效率的提升非常關(guān)注。我們將日常運(yùn)維逐步的沉淀轉(zhuǎn)換，構(gòu)建了一套美團(tuán)內(nèi)部的Kubernetes集群管理平臺。

1. 將集群的管理標(biāo)準(zhǔn)化、可視化，避免了黑白屏的運(yùn)維操作。
2. 通過告警自愈和自動巡檢將問題處理收斂掉，所以雖然我們有大幾十個集群，但我們的運(yùn)維效率還是比較高的，值班同學(xué)很少需要關(guān)注。
3. 全部的運(yùn)維操作流程化，不僅提升了運(yùn)維效率，人為操作導(dǎo)致的故障的概率也減小了。

4. 通過運(yùn)營數(shù)據(jù)的分析進(jìn)一步做了資源的精細(xì)化調(diào)度和故障預(yù)測，進(jìn)一步提前發(fā)現(xiàn)風(fēng)險，提升了運(yùn)營的質(zhì)量。

3.3 風(fēng)險控制和可靠性保障

規(guī)模大、覆蓋業(yè)務(wù)廣，任何的集群故障都會直接影響到服務(wù)的穩(wěn)定性甚至用戶的體驗，在經(jīng)歷了多次運(yùn)維故障和安全壓力下，我們形成了一套可復(fù)制的風(fēng)險控制和可靠性保障策略。

在整個風(fēng)險管控鏈路中，我們分為指標(biāo)、告警、工具、機(jī)制&措施和人員5個層面：

1. 指標(biāo)數(shù)據(jù)采集，從節(jié)點、集群、組件以及資源層面采集核心指標(biāo)作為數(shù)據(jù)源。
2. 風(fēng)險推送，覆蓋核心指標(biāo)的多級、多維度的告警機(jī)制。
3. 在工具支持上，通過主動、被動以及流程化等減少誤操作風(fēng)險。
4. 機(jī)制保障上，打通測試、灰度驗證、發(fā)布確認(rèn)以及演練等降低疏忽大意的情況。
5. 人是風(fēng)險的根本，這塊我們一直也在努力建設(shè)和輪值，確保問題的響應(yīng)。

在可靠性驗證和運(yùn)營方面，我們篤信需要把功夫用在評審，通過集群巡檢來評估集群的健康情況，并推送報表；定期的宕機(jī)演練保障真實故障能夠快速恢復(fù)，并將日常問題補(bǔ)全到全鏈路測試中，形成閉環(huán)。

四、總結(jié)與未來展望

4.1 經(jīng)驗心得

1. Kubernetes的落地完全兼容社區(qū)的Kubernetes API；只會做插件化的擴(kuò)展，并盡量不改控制層面的原有行為。
2. 對社區(qū)的一些特性，取長補(bǔ)短，并且有預(yù)期的升級，不盲目升級和跟進(jìn)社區(qū)版本，盡量保持每年度的一個核心穩(wěn)定版本。
3. 落地以用戶痛點為突破口，業(yè)務(wù)是比較實際的，為什么需要進(jìn)行遷移？業(yè)務(wù)會怕麻煩、不配合，所以推進(jìn)要找到業(yè)務(wù)痛點，從幫助業(yè)務(wù)的角度出發(fā)，效果就會不一樣。

4. 內(nèi)部的集群管理運(yùn)營的價值展現(xiàn)也是很重要的一環(huán)，讓用戶看到價值，業(yè)務(wù)看到潛在的收益，他們會主動來找你。

在容器時代，不能只看Kubernetes本身，對于企業(yè)內(nèi)的基礎(chǔ)設(shè)施，“向上”和“向下”的融合和兼容問題也很關(guān)鍵。“向上”是面向業(yè)務(wù)場景為用戶提供對接，因為容器并不能直接服務(wù)于業(yè)務(wù)，它還涉及到如何部署應(yīng)用、服務(wù)治理、調(diào)度等諸多層面。“向下”，即容器與基礎(chǔ)設(shè)施相結(jié)合的問題，這里更多的是兼容資源類型、更強(qiáng)大的隔離性、更高的資源使用效率等都是關(guān)鍵問題。

4.2 未來展望

1. 統(tǒng)一調(diào)度 ：VM會少量長期存在一段時間，但如果同時維護(hù)兩套基礎(chǔ)設(shè)施產(chǎn)品成本是非常高的，所以我們也在落地Kubernetes來統(tǒng)一管理VM和容器。
2. VPA ：探索通過VPA來進(jìn)一步提升整個資源的使用效率。
3. 云原生應(yīng)用管理 ：當(dāng)前，我們已將云原生應(yīng)用管理在生產(chǎn)環(huán)境落地，未來我們會進(jìn)一步擴(kuò)大云原生應(yīng)用的覆蓋面，不斷提升研發(fā)效率。

4. 云原生架構(gòu)落地：推進(jìn)各個中間件、存儲系統(tǒng)、大數(shù)據(jù)以及搜索業(yè)務(wù)合作落地各個領(lǐng)域的云原生系統(tǒng)。

作者簡介

國梁，美團(tuán)技術(shù)專家，現(xiàn)負(fù)責(zé)美團(tuán)Kubernetes集群的整體運(yùn)營和維護(hù)以及云原生技術(shù)落地支持。