阿里巴巴大規(guī)模神龍裸金屬 Kubernetes 集群運(yùn)維實(shí)踐

作者 | 姚捷（嘍哥）阿里云容器平臺(tái)集群管理高級(jí)技術(shù)專家

本文節(jié)選自《不一樣的 雙11 技術(shù)：阿里巴巴經(jīng)濟(jì)體云原生實(shí)踐》一書，點(diǎn)擊即可完成下載。

cdn.com/2d3f2c0a733aa3bc75c82319f10a13c2f82b3771.jpeg">

導(dǎo)讀：值得阿里巴巴技術(shù)人驕傲的是 2019 年阿里巴巴 雙11?核心系統(tǒng) 100% 以云原生的方式上云，完美支撐了?54.4w 峰值流量以及?2684 億的成交量。背后承載海量交易的計(jì)算力就是來(lái)源于容器技術(shù)與神龍裸金屬的完美融合。

集團(tuán)上云機(jī)器資源形態(tài)

阿里巴巴 雙11 采用三地五單元架構(gòu)，除 2 個(gè)混部單元外，其他 3 個(gè)均是云單元。神龍機(jī)型經(jīng)過(guò) 618、99 大促的驗(yàn)證，性能和穩(wěn)定性已大幅提升，可以穩(wěn)定支撐 雙11。今年 雙11 的 3 個(gè)交易云單元，已經(jīng) 100% 基于神龍裸金屬，核心交易電商神龍集群規(guī)模已達(dá)到數(shù)萬(wàn)臺(tái)。

神龍架構(gòu)

阿里云 ECS 虛擬化技術(shù)歷經(jīng)三代，前二代是 Xen 與 KVM，神龍是阿里巴巴自研的第三代 ECS 虛擬化技術(shù)產(chǎn)品，它具備以下四大技術(shù)特征：

• 存儲(chǔ)和網(wǎng)絡(luò) VMM?以及?ECS?管控，和計(jì)算虛擬化分離部署；
• 計(jì)算虛擬化進(jìn)一步演化至 Near
  Metal Hypervisor；
• 存儲(chǔ)和網(wǎng)絡(luò) VMM?通過(guò)芯片專用?IP?業(yè)務(wù)加速；
• 并池支持彈性裸金屬和 ECS?虛擬機(jī)生產(chǎn)。

簡(jiǎn)而言之，神龍將網(wǎng)絡(luò)/存儲(chǔ)的虛擬化開銷 offload 到一張叫 MOC 卡的 FPGA 硬件加速卡上，降低了原 ECS 約 8% 的計(jì)算虛擬化的開銷，同時(shí)通過(guò)大規(guī)模 MOC 卡的制造成本優(yōu)勢(shì)，攤平了神龍整體的成本開銷。神龍類物理機(jī)特性，可進(jìn)行二次虛擬化，使得對(duì)于新技術(shù)的演進(jìn)發(fā)展留足了空間，對(duì)于采用一些多樣的虛擬化的技術(shù)，像 Kata、Firecracker 等成為了可能。

在阿里巴巴 雙11 大規(guī)模遷移到神龍架構(gòu)前，通過(guò)在 618/99 大促的驗(yàn)證，我們發(fā)現(xiàn)集團(tuán)電商的容器運(yùn)行在云上神龍反而比非云物理機(jī)的性能要好 10%～15%，這令我們非常詫異。經(jīng)過(guò)分析，我們發(fā)現(xiàn)主要是因?yàn)樘摂M化開銷已經(jīng) offload 到 MOC?卡上，神龍的 CPU/Mem 是無(wú)虛擬化開銷的，而上云后運(yùn)行在神龍上的每個(gè)容器都獨(dú)享 ENI 彈性網(wǎng)卡，性能優(yōu)勢(shì)明顯。同時(shí)每個(gè)容器獨(dú)享一塊 ESSD 塊存儲(chǔ)云盤，單盤 IOPS 高達(dá) 100 萬(wàn)，比 SSD 云盤快 50 倍，性能超過(guò)了非云的 SATA 和 SSD 本地盤。這也讓我們堅(jiān)定了大規(guī)模采用神龍來(lái)支撐 雙11 的決心。

神龍+容器+Kubernetes

在 All in Cloud 的時(shí)代企業(yè) IT 架構(gòu)正在被重塑，而云原生已經(jīng)成為釋放云計(jì)算價(jià)值的最短路徑。2019 年阿里巴巴 雙11 核心系統(tǒng) 100% 以云原生的方式上云，基于神龍服務(wù)器、輕量級(jí)云原生容器以及兼容 Kubernetes?的調(diào)度的新的 ASI（alibaba serverless infra.）調(diào)度平臺(tái)。其中 Kubernetes Pod 容器運(yùn)行時(shí)與神龍裸金屬完美融合，Pod 容器作為業(yè)務(wù)的交付切面，運(yùn)行在神龍實(shí)例上。

下面是 Pod 運(yùn)行在神龍上的形態(tài)：

• ASI Pod 運(yùn)行在神龍裸金屬節(jié)點(diǎn)上，將網(wǎng)絡(luò)虛擬化和存儲(chǔ)虛擬化 offload 到獨(dú)立硬件節(jié)點(diǎn) MOC 卡上，并采用 FPGA 芯片加速技術(shù)，存儲(chǔ)與網(wǎng)絡(luò)性能均超過(guò)普通物理機(jī)和 ECS；MOC 有獨(dú)立的操作系統(tǒng)與內(nèi)核，可為 AVS（網(wǎng)絡(luò)處理）與 TDC（存儲(chǔ)處理）分配獨(dú)立的 CPU 核；
• ASI Pod 由 Main 容器（業(yè)務(wù)主容器），運(yùn)維容器（star-agent side-car 容器）和其它輔助容器（例如某應(yīng)用的 Local 緩存容器）構(gòu)成。Pod 內(nèi)通過(guò) Pause 容器共享網(wǎng)絡(luò)命名空間，UTS 命名空間和 PID 命名空間（ASI 關(guān)閉了 PID 命名空間的共享）；
• Pod 的 Main 容器和運(yùn)維容器共享數(shù)據(jù)卷，并通過(guò) PVC 聲明云盤，將數(shù)據(jù)卷掛載到對(duì)應(yīng)的云盤掛載點(diǎn)上。在 ASI 的存儲(chǔ)架構(gòu)下，每一個(gè) Pod 都有一塊獨(dú)立的云盤空間，可支持讀寫隔離和限制磁盤大??；
• ASI Pod 通過(guò) Pause 容器直通 MOC 卡上的 ENI 彈性網(wǎng)卡；
• ASI Pod 無(wú)論內(nèi)部有多少容器，對(duì)外只占用獨(dú)立的資源，例如 16C（CPU）/60G（內(nèi)存）/60G（磁盤）。

大規(guī)模神龍運(yùn)維

2019 年 雙11 云上核心交易的神龍集群規(guī)模已達(dá)到數(shù)萬(wàn)臺(tái)，管理和運(yùn)維如此大規(guī)模神龍集群極具挑戰(zhàn)，這其中包括云上各類業(yè)務(wù)實(shí)例規(guī)格的選擇、大規(guī)模集群彈性擴(kuò)縮容、節(jié)點(diǎn)資源劃分與管控、核心指標(biāo)統(tǒng)計(jì)分析、基礎(chǔ)環(huán)境監(jiān)控、宕機(jī)分析、節(jié)點(diǎn)標(biāo)簽管理、節(jié)點(diǎn)重啟/鎖定/釋放、節(jié)點(diǎn)自愈、故障機(jī)輪轉(zhuǎn)、內(nèi)核補(bǔ)丁升級(jí)、大規(guī)模巡檢等能力建設(shè)。

下面就幾個(gè)領(lǐng)域細(xì)化展開：

實(shí)例規(guī)格

首先需要針對(duì)不同類型業(yè)務(wù)規(guī)劃不同的實(shí)例規(guī)格，包括入口層、核心業(yè)務(wù)系統(tǒng)、中間件、數(shù)據(jù)庫(kù)、緩存服務(wù)這些不同特性的基礎(chǔ)設(shè)施和業(yè)務(wù)，有些需要高性能的計(jì)算、有些需要高網(wǎng)絡(luò)收發(fā)包能力，有些需要高性能的磁盤讀寫能力。在前期需要系統(tǒng)性整體規(guī)劃，避免實(shí)例規(guī)格選擇不當(dāng)影響業(yè)務(wù)性能和穩(wěn)定性。實(shí)例規(guī)格的核心配置參數(shù)包括 vcpu、內(nèi)存、彈性網(wǎng)卡數(shù)，云盤數(shù)、系統(tǒng)盤大小、數(shù)據(jù)盤大小、網(wǎng)絡(luò)收發(fā)包能力 (PPS)。

電商核心系統(tǒng)應(yīng)用的主力機(jī)型為 96C/527G，每個(gè) Kubernetes Pod 容器占用一塊彈性網(wǎng)卡和一塊 EBS 云盤，所以彈性網(wǎng)卡和云盤的限制數(shù)非常關(guān)鍵，此次電商上云，神龍將彈性網(wǎng)卡和 EBS 云盤的限制數(shù)提高到?64 與 40，有效避免了 CPU 與內(nèi)存的資源浪費(fèi)。另外對(duì)于不同類型的業(yè)務(wù)，核心配置也會(huì)略有差異，例如入口層 aserver 神龍實(shí)例由于需要承擔(dān)大量的入口流量，對(duì) MOC 的網(wǎng)絡(luò)收發(fā)包能力的要求極高，為避免 AVS 網(wǎng)絡(luò)軟交換 CPU 打滿，對(duì)于神龍 MOC 卡里的網(wǎng)絡(luò)和存儲(chǔ)的 CPU 分配參數(shù)的需求不同，常規(guī)計(jì)算型神龍實(shí)例的 MOC 卡網(wǎng)絡(luò)/存儲(chǔ)的 CPU 分配是 4+8，而 aserver 神龍實(shí)例需要配置為 6:6；例如對(duì)于云上混部機(jī)型，需要為離線任務(wù)提供獨(dú)立的 nvme 本盤實(shí)例。為不同類型業(yè)務(wù)合理規(guī)劃?rùn)C(jī)型和規(guī)格，會(huì)極大程度的降低成本，保證性能和穩(wěn)定性。

資源彈性

雙11 需要海量的計(jì)算資源來(lái)扛住洪峰流量，但這部分資源不可能常態(tài)化持有，所以需要合理劃分日常集群與大促集群，并在 雙11 前幾周，通過(guò)大規(guī)模節(jié)點(diǎn)彈性擴(kuò)容能力，從阿里云彈性申請(qǐng)大批量神龍，部署在獨(dú)立的大促集群分組里，并大規(guī)模擴(kuò)容 Kubernetes Pod 交付業(yè)務(wù)計(jì)算資源。在 雙11 過(guò)后，立即將大促集群中的 Pod 容器批量縮容下線，大促集群神龍實(shí)例整體銷毀下線，日常只持有常態(tài)化神龍實(shí)例，通過(guò)大規(guī)模集群彈性擴(kuò)縮容能力，可大幅節(jié)約大促成本。另外從神龍交付周期而言，今年上云后從申請(qǐng)到創(chuàng)建機(jī)器，從小時(shí)/天級(jí)別縮短到了分鐘級(jí)，上千臺(tái)神龍可在 5 分鐘內(nèi)完成申請(qǐng)，包括計(jì)算、網(wǎng)絡(luò)、存儲(chǔ)資源；在 10 分鐘內(nèi)完成創(chuàng)建并導(dǎo)入 Kubernetes 集群，集群創(chuàng)建效率大幅度提高，為未來(lái)常態(tài)化彈性資源池奠定基礎(chǔ)。

核心指標(biāo)

對(duì)于大規(guī)模神龍集群運(yùn)維，有三個(gè)非常核心的指標(biāo)可以來(lái)衡量集群整體健康度，分別是宕機(jī)率、可調(diào)度率、在線率。

云上神龍宕機(jī)原因通常分為硬件問(wèn)題和內(nèi)核問(wèn)題。通過(guò)對(duì)日宕機(jī)率趨勢(shì)統(tǒng)計(jì)和宕機(jī)根因分析，可量化集群的穩(wěn)定性，避免出現(xiàn)潛在的大規(guī)模宕機(jī)風(fēng)險(xiǎn)出現(xiàn)?？烧{(diào)度率是衡量集群健康度的關(guān)鍵指標(biāo)，集群機(jī)器會(huì)因?yàn)楦鞣N軟硬件原因出現(xiàn)容器無(wú)法調(diào)度到這些異常機(jī)器上，例如 Load 大于 1000、磁盤出現(xiàn)壓力、docker 進(jìn)程不存在，kubelet 進(jìn)程不存在等，在 Kubernetes?集群中，這批機(jī)器的狀態(tài)會(huì)是 notReady。2019 年 雙11，我們通過(guò)神龍宕機(jī)重啟與冷遷移特性，極大提升了故障機(jī)輪轉(zhuǎn)效率，使神龍集群的可調(diào)度率始終維持在 98% 以上，大促資源備容從容。而 雙11 神龍的宕機(jī)率維持在?0.2‰ 以下，表現(xiàn)相當(dāng)穩(wěn)定。

標(biāo)簽管理

隨著集群規(guī)模的增加，管理難度也隨之變大。例如如何能篩選出 "cn-shanghai"Region 下生產(chǎn)環(huán)境，且實(shí)例規(guī)格為 "ecs.ebmc6-inc.26xlarge" 的所有機(jī)器。我們通過(guò)定義大量的預(yù)置標(biāo)簽來(lái)實(shí)現(xiàn)批量資源管理。在 Kubernetes 架構(gòu)下，通過(guò)定義 Label 來(lái)管理機(jī)器。Label 是一個(gè) Key-Value 健值對(duì)，可在神龍節(jié)點(diǎn)上使用標(biāo)準(zhǔn) Kubernetes 的接口打 Label。例如機(jī)器實(shí)例規(guī)格的 Label 可定義 "sigma.ali/machine-model":"ecs.ebmc6-inc.26xlarge", 機(jī)器所在的 Region 可定義為?"sigma.ali/ecs-region-id":"cn-shanghai"。通過(guò)完善的標(biāo)簽管理系統(tǒng)，可從幾萬(wàn)臺(tái)神龍節(jié)點(diǎn)中快速篩選機(jī)器，執(zhí)行諸如灰度分批次服務(wù)發(fā)布、批量重啟、批量釋放等常規(guī)運(yùn)維操作。

宕機(jī)分析

對(duì)于超大規(guī)模集群，日常宕機(jī)是非常普遍的事情，對(duì)宕機(jī)的統(tǒng)計(jì)與分析非常關(guān)鍵，可以甄別出是否存在系統(tǒng)性風(fēng)險(xiǎn)。宕機(jī)的情況分為很多種，硬件故障會(huì)導(dǎo)致宕機(jī)，內(nèi)核的 bug 等也會(huì)導(dǎo)致宕機(jī)，一旦宕機(jī)以后，業(yè)務(wù)就會(huì)中斷，有些有狀態(tài)應(yīng)用就會(huì)受到影響。我們通過(guò) ssh 與端口 ping 巡檢對(duì)資源池的宕機(jī)情況進(jìn)行了監(jiān)控，統(tǒng)計(jì)宕機(jī)歷史趨勢(shì)，一旦有突增的宕機(jī)情況就會(huì)報(bào)警；同時(shí)對(duì)宕機(jī)的機(jī)器進(jìn)行關(guān)聯(lián)分析，如根據(jù)機(jī)房、環(huán)境、單元、分組 進(jìn)行歸類，看是否跟某個(gè)特定的機(jī)房有關(guān)；對(duì)機(jī)型、CPU 進(jìn)行分類統(tǒng)計(jì)，看是否跟特定的硬件有關(guān)系；同時(shí) OS 版本、內(nèi)核版本進(jìn)行歸類，看是否都發(fā)生在某些特定的內(nèi)核上。

對(duì)宕機(jī)的根因，也進(jìn)行了綜合的分析，看是硬件故障，還是有主動(dòng)運(yùn)維事件。內(nèi)核的 kdump 機(jī)制會(huì)在發(fā)生 crash 的時(shí)候生成 vmcore，我們也對(duì) vmcore 里面提取的信息進(jìn)行歸類，看某一類特定的 vmcore 關(guān)聯(lián)的宕機(jī)數(shù)有多少。內(nèi)核日志有些出錯(cuò)的信息，如 mce 日志、soft lockup 的出錯(cuò)信息等，也能發(fā)現(xiàn)系統(tǒng)在宕機(jī)前后是否有異常。

通過(guò)這一系列的宕機(jī)分析工作，把相應(yīng)的問(wèn)題提交給內(nèi)核團(tuán)隊(duì)，內(nèi)核專家就會(huì)分析 vmcore，屬于內(nèi)核的缺陷會(huì)給出 hotfix 解決這些導(dǎo)致宕機(jī)的問(wèn)題。

節(jié)點(diǎn)自愈

運(yùn)維大規(guī)模神龍集群不可避免地會(huì)遇到軟硬件故障，而在云上技術(shù)棧更厚，出現(xiàn)問(wèn)題會(huì)更為復(fù)雜。如果出問(wèn)題單純依靠人工來(lái)處理是不現(xiàn)實(shí)的，必須依賴自動(dòng)化能力來(lái)解決。1-5-10 節(jié)點(diǎn)自愈可提供 1 分鐘異常問(wèn)題發(fā)現(xiàn)，5 分鐘定位，10 分鐘修復(fù)的能力。主要的神龍機(jī)器異常包括宕機(jī)、夯機(jī)、主機(jī) load 高、磁盤空間滿、too many openfiles、核心服務(wù)（Kubelet、Pouch、Star-Agent）不可用等。主要的修復(fù)動(dòng)作包括宕機(jī)重啟、業(yè)務(wù)容器驅(qū)逐、異常軟件重啟、磁盤自動(dòng)清理，其中 80% 以上的問(wèn)題可通過(guò)重啟宕機(jī)機(jī)器與將業(yè)務(wù)容器驅(qū)逐到其他節(jié)點(diǎn)完成節(jié)點(diǎn)自愈。另外我們通過(guò)監(jiān)聽神龍?Reboot 重啟與 Redepoly 實(shí)例遷移兩個(gè)系統(tǒng)事件來(lái)實(shí)現(xiàn) NC 側(cè)系統(tǒng)或硬件故障的自動(dòng)化修復(fù)。

未來(lái)展望

2020 年 雙11，阿里巴巴經(jīng)濟(jì)體基礎(chǔ)設(shè)施將會(huì) 100% 基于 Kubernetes，基于 runV 安全容器的下一代混部架構(gòu)將會(huì)大規(guī)模落地，輕量化容器架構(gòu)會(huì)演進(jìn)到下一階段。

在此大背景下，一方面 Kubernetes 節(jié)點(diǎn)管理將會(huì)朝向阿里巴巴經(jīng)濟(jì)體并池管理方向發(fā)展，打通云庫(kù)存管理，提升節(jié)點(diǎn)彈性能力，根據(jù)業(yè)務(wù)特性錯(cuò)峰資源利用，進(jìn)一步降低機(jī)器持有時(shí)間從而大幅降低成本。

在技術(shù)目標(biāo)上，我們會(huì)采用基于?Kubernetes Machine-Operator 的核心引擎，提供高度靈活的節(jié)點(diǎn)運(yùn)維編排能力，支持節(jié)點(diǎn)運(yùn)維狀態(tài)的終態(tài)維持。另一方面，基于完整的全域數(shù)據(jù)采集和分析能力，提供極致的全鏈路監(jiān)控/分析/內(nèi)核診斷能力，全面提升容器基礎(chǔ)環(huán)境的穩(wěn)定性，為輕量化容器/不可變基礎(chǔ)設(shè)施架構(gòu)演進(jìn)提供極致性能觀測(cè)與診斷的技術(shù)保障。<br />

《不一樣的 雙11 技術(shù)：阿里巴巴經(jīng)濟(jì)體云原生實(shí)踐》

雙11 的 2684 億成交額背后是對(duì)一個(gè)個(gè)技術(shù)問(wèn)題的反復(fù)嘗試與實(shí)踐。

這一次，我們對(duì)云原生技術(shù)在 雙11 的實(shí)踐細(xì)節(jié)進(jìn)行深挖，篩選了其中 22 篇有代表性的文章進(jìn)行重新編排，整理成《不一樣的 雙11 技術(shù)：阿里巴巴經(jīng)濟(jì)體云原生實(shí)踐》一書。

將為你帶來(lái)不一樣的 雙11 云原生技術(shù)亮點(diǎn)：

• 雙11 超大規(guī)模 K8s 集群實(shí)踐中，遇到的問(wèn)題及解決方法詳述；
• 云原生化最佳組合：Kubernetes+容器+神龍，實(shí)現(xiàn)核心系統(tǒng) 100% 上云的技術(shù)細(xì)節(jié)；
• 雙 11 Service Mesh 超大規(guī)模落地解決方案。

“阿里巴巴云原生微信公眾號(hào)（ID：Alicloudnative）關(guān)注微服務(wù)、Serverless、容器、Service Mesh等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢(shì)、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開發(fā)者的技術(shù)公眾號(hào)。”