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

本文根據(jù)美團(tuán)基礎(chǔ)架構(gòu)部王國(guó)梁在KubeCon 2020云原生開(kāi)源峰會(huì)Cloud Native + Open Source Virtual Summit China 2020上的演講內(nèi)容整理而成。

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

Kubernetes是讓容器應(yīng)用進(jìn)入大規(guī)模工業(yè)生產(chǎn)環(huán)境的開(kāi)源系統(tǒng)，也是集群調(diào)度領(lǐng)域的事實(shí)標(biāo)準(zhǔn)，目前已被業(yè)界廣泛接受并得到了大規(guī)模的應(yīng)用。Kubernetes已經(jīng)成為美團(tuán)云基礎(chǔ)設(shè)施的管理引擎，它帶來(lái)的不僅僅是高效的資源管理，同時(shí)也大幅降低了成本，而且為美團(tuán)云原生架構(gòu)的推進(jìn)打下了堅(jiān)實(shí)的基礎(chǔ)，支持了Serverless、云原生分布式數(shù)據(jù)庫(kù)等一些平臺(tái)完成容器化和云原生化的建設(shè)。

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

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

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

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

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

架構(gòu)復(fù)雜，運(yùn)維和維護(hù)比較困難：OpenStack的整個(gè)架構(gòu)中計(jì)算資源的管理模塊是非常龐大和復(fù)雜，問(wèn)題排查和可靠性一直是很大的問(wèn)題。 環(huán)境不一致問(wèn)題突出：環(huán)境不一致問(wèn)題是容器鏡像出現(xiàn)之前業(yè)界的通用問(wèn)題，不利于業(yè)務(wù)的快速上線和穩(wěn)定性。 虛擬化本身資源占用多：虛擬化本身大概占用10%的宿主機(jī)資源消耗，在集群規(guī)模足夠大的時(shí)候，這是一塊非常大的資源浪費(fèi)。 資源交付和回收周期長(zhǎng)，不易靈活調(diào)配：一方面是整個(gè)虛擬機(jī)創(chuàng)建流程冗長(zhǎng);另一方面各種初始化和配置資源準(zhǔn)備耗時(shí)長(zhǎng)且容易出錯(cuò)，所以就導(dǎo)致整個(gè)機(jī)器資源從申請(qǐng)到交付周期長(zhǎng)，快速的資源調(diào)配是個(gè)難題。 高低峰明顯，資源浪費(fèi)嚴(yán)重：隨著移動(dòng)互聯(lián)網(wǎng)的高速發(fā)展，公司業(yè)務(wù)出現(xiàn)高低峰的時(shí)間越來(lái)越多，為了保障服務(wù)穩(wěn)定不得不按照最高的資源需求來(lái)準(zhǔn)備資源，這就導(dǎo)致低峰時(shí)資源空閑嚴(yán)重，進(jìn)而造成浪費(fèi)。

2.1 容器化的過(guò)程和障礙

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

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

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

上述的問(wèn)題經(jīng)過(guò)一段時(shí)間的優(yōu)化和改善，始終不能徹底解決。在這種情況下，我們不得不重新思考整個(gè)容器平臺(tái)的架構(gòu)合理性，而此時(shí)Kubernetes已逐步被業(yè)界認(rèn)可和應(yīng)用，它清晰的架構(gòu)和先進(jìn)的設(shè)計(jì)思路讓我們看到了希望。所以我們基于Kubernetes構(gòu)建了新的容器平臺(tái)，在新的平臺(tái)中Hulk完全基于原生的Kubernetes API，通過(guò)Hulk API來(lái)對(duì)接內(nèi)部的發(fā)布部署系統(tǒng)，這樣兩層API將整個(gè)架構(gòu)解耦開(kāi)來(lái)，領(lǐng)域明確，應(yīng)用管理和資源管理可以獨(dú)立迭代，Kubernetes強(qiáng)大的編排和資源管理能力凸顯。

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

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

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

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

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

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

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

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

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

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

2.2.3.1 容器復(fù)用

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

為了解決這個(gè)問(wèn)題，我們?yōu)槿萜鞯闹貑⒉呗灶?lèi)型增加了Reuse策略。流程如下：

kubelet在SyncPod時(shí)，重啟策略如果是Reuse則會(huì)獲取對(duì)應(yīng)Pod已退出狀態(tài)的App容器，如果存在則拉起最新的App容器(可能有多個(gè))，如果不存在則直接新建。 更新App容器映射的pauseID為新的pause容器ID，這樣就建立了Pod下新的pause容器和原先App容器的映射。 重新拉起App容器即可完成Pod狀態(tài)同步，最終即使宿主機(jī)重啟或內(nèi)核升級(jí)，容器數(shù)據(jù)也不會(huì)丟失。

2.2.3.2 Numa感知與綁定

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

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

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

在調(diào)度層面，我們?yōu)檎{(diào)度器增加了負(fù)載感知和基于服務(wù)畫(huà)像應(yīng)用特征的打散和優(yōu)選策略。

在故障容器發(fā)現(xiàn)和處理上，基于特征庫(kù)落地的告警自愈組件，能夠秒級(jí)發(fā)現(xiàn)-分析-處理告警。

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

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

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

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

針對(duì)CPU資源分配，采用獨(dú)占CPU集合的方式，避免Pod之間發(fā)生爭(zhēng)搶。

通過(guò)允許自定義SWAP大小來(lái)應(yīng)對(duì)短暫的高流量，并關(guān)閉Numa Node和PageCache來(lái)提升穩(wěn)定性。

在磁盤(pán)分配中采用Pod獨(dú)占磁盤(pán)進(jìn)行IOPS的隔離，以及通過(guò)預(yù)分配和格式化磁盤(pán)來(lái)提升擴(kuò)容的速度，提升資源交付效率。

調(diào)度支持獨(dú)有的打散策略和縮容確認(rèn)，規(guī)避縮容風(fēng)險(xiǎn)。

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

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

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

業(yè)務(wù)預(yù)算配額確定資源供給，通過(guò)專(zhuān)區(qū)來(lái)做專(zhuān)有資源專(zhuān)用。

建設(shè)彈性資源池和打通公有云來(lái)應(yīng)對(duì)突發(fā)資源需求。

按照業(yè)務(wù)和應(yīng)用類(lèi)型的優(yōu)先級(jí)保障資源使用，確保核心業(yè)務(wù)先拿到資源。

多個(gè)Kubenretes集群和多機(jī)房來(lái)做容災(zāi)，應(yīng)對(duì)集群或機(jī)房的故障。

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

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

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

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

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

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

Kubernetes穩(wěn)定性99.99%以上。 Kubernetes成為美團(tuán)內(nèi)部集群管理平臺(tái)的標(biāo)準(zhǔn)。

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

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

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

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

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

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

另外，社區(qū)版本的迭代是非?？斓模甙姹驹诜€(wěn)定性和特性支持上更好，不可避免我們需要進(jìn)行版本的升級(jí)，但如何確保升級(jí)成功是一個(gè)很大的挑戰(zhàn)，尤其是我們?cè)跊](méi)有足夠的Buffer資源進(jìn)行資源騰挪情況下。

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

升級(jí)版本有限制，不能跨大版本升級(jí)：只能一點(diǎn)點(diǎn)從低版本升級(jí)到高版本，耗時(shí)費(fèi)力，而且成功率低。 控制平面升級(jí)風(fēng)險(xiǎn)不可控：尤其是有API變更的時(shí)候，會(huì)覆蓋之前的數(shù)據(jù)，甚至是不可回滾的。 用戶有感知，容器需要新建，成本和影響較高：這個(gè)是比較痛的點(diǎn)，無(wú)可避免會(huì)發(fā)生容器新建。

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

該方案亮點(diǎn)主要包括以下4個(gè)方面：

大規(guī)模生產(chǎn)環(huán)境的集群升級(jí)不再是難題。 解決了現(xiàn)有技術(shù)方案風(fēng)險(xiǎn)不可控的問(wèn)題，風(fēng)險(xiǎn)降到了宿主機(jī)級(jí)別，升級(jí)更為安全。 通用性強(qiáng)，可做到任意版本的升級(jí)，且方案生命周期長(zhǎng)。 優(yōu)雅地解決了升級(jí)過(guò)程中容器新建問(wèn)題，真正做到了原地?zé)嵘?jí)。

3.2 平臺(tái)化與運(yùn)營(yíng)效率

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

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

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

將集群的管理標(biāo)準(zhǔn)化、可視化，避免了黑白屏的運(yùn)維操作。

通過(guò)告警自愈和自動(dòng)巡檢將問(wèn)題處理收斂掉，所以雖然我們有大幾十個(gè)集群，但我們的運(yùn)維效率還是比較高的，值班同學(xué)很少需要關(guān)注。

全部的運(yùn)維操作流程化，不僅提升了運(yùn)維效率，人為操作導(dǎo)致的故障的概率也減小了。

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

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

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

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

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

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

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

4.1 經(jīng)驗(yàn)心得

Kubernetes的落地完全兼容社區(qū)的Kubernetes API;只會(huì)做插件化的擴(kuò)展，并盡量不改控制層面的原有行為。

對(duì)社區(qū)的一些特性，取長(zhǎng)補(bǔ)短，并且有預(yù)期的升級(jí)，不盲目升級(jí)和跟進(jìn)社區(qū)版本，盡量保持每年度的一個(gè)核心穩(wěn)定版本。

落地以用戶痛點(diǎn)為突破口，業(yè)務(wù)是比較實(shí)際的，為什么需要進(jìn)行遷移?業(yè)務(wù)會(huì)怕麻煩、不配合，所以推進(jìn)要找到業(yè)務(wù)痛點(diǎn)，從幫助業(yè)務(wù)的角度出發(fā)，效果就會(huì)不一樣。

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

在容器時(shí)代，不能只看 Ku1. bernetes 本身，對(duì)于企業(yè)內(nèi)的基礎(chǔ)設(shè)施，“向上”和“向下”的融合和兼容問(wèn)題也很關(guān)鍵?！跋蛏稀笔敲嫦驑I(yè)務(wù)場(chǎng)景為用戶提供對(duì)接，因?yàn)槿萜鞑⒉荒苤苯臃?wù)于業(yè)務(wù)，它還涉及到如何部署應(yīng)用、服務(wù)治理、調(diào)度等諸多層面?！跋蛳隆?，即容器與基礎(chǔ)設(shè)施相結(jié)合的問(wèn)題，這里更多的是兼容資源類(lèi)型、更強(qiáng)大的隔離性、更高的資源使用效率等都是關(guān)鍵問(wèn)題。

4.2 未來(lái)展望

統(tǒng)一調(diào)度：VM會(huì)少量長(zhǎng)期存在一段時(shí)間，但如果同時(shí)維護(hù)兩套基礎(chǔ)設(shè)施產(chǎn)品成本是非常高的，所以我們也在落地Kubernetes來(lái)統(tǒng)一管理VM和容器。 VPA：探索通過(guò)VPA來(lái)進(jìn)一步提升整個(gè)資源的使用效率。 云原生應(yīng)用管理：當(dāng)前，我們已將云原生應(yīng)用管理在生產(chǎn)環(huán)境落地，未來(lái)我們會(huì)進(jìn)一步擴(kuò)大云原生應(yīng)用的覆蓋面，不斷提升研發(fā)效率。 云原生架構(gòu)落地：推進(jìn)各個(gè)中間件、存儲(chǔ)系統(tǒng)、大數(shù)據(jù)以及搜索業(yè)務(wù)合作落地各個(gè)領(lǐng)域的云原生系統(tǒng)。

作者介紹

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