作者 | 姚捷（嘍哥）阿里雲容器平臺叢集管理高階技術專家

本文節選自《不一樣的 雙11 技術：阿里巴巴經濟體雲原生實踐》一書，點選即可完成下載。

導讀：值得阿里巴巴技術人驕傲的是 2019 年阿里巴巴 雙11 核心系統 100% 以雲原生的方式上雲，完美支撐了 54.4w 峰值流量以及 2684 億的成交量。背後承載海量交易的計算力就是來源於容器技術與神龍裸金屬的完美融合。

集團上雲機器資源形態

阿里巴巴 雙11 採用三地五單元架構，除 2 個混部單元外，其他 3 個均是雲單元。神龍機型經過 618、99 大促的驗證，效能和穩定性已大幅提升，可以穩定支撐 雙11。今年 雙11 的 3 個交易雲單元，已經 100% 基於神龍裸金屬，核心交易電商神龍叢集規模已達到數萬臺。

神龍架構

阿里雲 ECS 虛擬化技術歷經三代，前二代是 Xen 與 KVM，神龍是阿里巴巴自研的第三代 ECS 虛擬化技術產品，它具備以下四大技術特徵：

• 儲存和網路 VMM 以及 ECS 管控，和計算虛擬化分離部署；
• 計算虛擬化進一步演化至 Near
  Metal Hypervisor；
• 儲存和網路 VMM 通過晶片專用 IP 業務加速；
• 並池支援彈性裸金屬和 ECS 虛擬機器生產。

簡而言之，神龍將網路/儲存的虛擬化開銷 offload 到一張叫 MOC 卡的 FPGA 硬體加速卡上，降低了原 ECS 約 8% 的計算虛擬化的開銷，同時通過大規模 MOC 卡的製造成本優勢，攤平了神龍整體的成本開銷。神龍類物理機特性，可進行二次虛擬化，使得對於新技術的演進發展留足了空間，對於採用一些多樣的虛擬化的技術，像 Kata、Firecracker 等成為了可能。

在阿里巴巴 雙11 大規模遷移到神龍架構前，通過在 618/99 大促的驗證，我們發現集團電商的容器執行在雲上神龍反而比非雲物理機的效能要好 10%～15%，這令我們非常詫異。經過分析，我們發現主要是因為虛擬化開銷已經 offload 到 MOC 卡上，神龍的 CPU/Mem 是無虛擬化開銷的，而上雲後執行在神龍上的每個容器都獨享 ENI 彈性網絡卡，效能優勢明顯。同時每個容器獨享一塊 ESSD 塊儲存雲盤，單盤 IOPS 高達 100 萬，比 SSD 雲盤快 50 倍，效能超過了非雲的 SATA 和 SSD 本地盤。這也讓我們堅定了大規模採用神龍來支撐 雙11 的決心。

神龍+容器+Kubernetes

在 All in Cloud 的時代企業 IT 架構正在被重塑，而云原生已經成為釋放雲端計算價值的最短路徑。2019 年阿里巴巴 雙11 核心系統 100% 以雲原生的方式上雲，基於神龍伺服器、輕量級雲原生容器以及相容 Kubernetes 的排程的新的 ASI（alibaba serverless infra.）排程平臺。其中 Kubernetes Pod 容器執行時與神龍裸金屬完美融合，Pod 容器作為業務的交付切面，執行在神龍例項上。

下面是 Pod 執行在神龍上的形態：

• ASI Pod 執行在神龍裸金屬節點上，將網路虛擬化和儲存虛擬化 offload 到獨立硬體節點 MOC 卡上，並採用 FPGA 晶片加速技術，儲存與網路效能均超過普通物理機和 ECS；MOC 有獨立的作業系統與核心，可為 AVS（網路處理）與 TDC（儲存處理）分配獨立的 CPU 核；
• ASI Pod 由 Main 容器（業務主容器），運維容器（star-agent side-car 容器）和其它輔助容器（例如某應用的 Local 快取容器）構成。Pod 內通過 Pause 容器共享網路名稱空間，UTS 名稱空間和 PID 名稱空間（ASI 關閉了 PID 名稱空間的共享）；
• Pod 的 Main 容器和運維容器共享資料卷，並通過 PVC 宣告雲盤，將資料卷掛載到對應的雲盤掛載點上。在 ASI 的儲存架構下，每一個 Pod 都有一塊獨立的雲盤空間，可支援讀寫隔離和限制磁碟大小；
• ASI Pod 通過 Pause 容器直通 MOC 卡上的 ENI 彈性網絡卡；
• ASI Pod 無論內部有多少容器，對外只佔用獨立的資源，例如 16C（CPU）/60G（記憶體）/60G（磁碟）。

大規模神龍運維

2019 年 雙11 雲上核心交易的神龍叢集規模已達到數萬臺，管理和運維如此大規模神龍叢集極具挑戰，這其中包括雲上各類業務例項規格的選擇、大規模叢集彈性擴縮容、節點資源劃分與管控、核心指標統計分析、基礎環境監控、宕機分析、節點標籤管理、節點重啟/鎖定/釋放、節點自愈、故障機輪轉、核心補丁升級、大規模巡檢等能力建設。

下面就幾個領域細化展開：

例項規格

首先需要針對不同型別業務規劃不同的例項規格，包括入口層、核心業務系統、中介軟體、資料庫、快取服務這些不同特性的基礎設施和業務，有些需要高效能的計算、有些需要高網路收發包能力，有些需要高效能的磁碟讀寫能力。在前期需要系統性整體規劃，避免例項規格選擇不當影響業務效能和穩定性。例項規格的核心配置引數包括 vcpu、記憶體、彈性網絡卡數，雲盤數、系統盤大小、資料盤大小、網路收發包能力 (PPS)。

電商核心系統應用的主力機型為 96C/527G，每個 Kubernetes Pod 容器佔用一塊彈性網絡卡和一塊 EBS 雲盤，所以彈性網絡卡和雲盤的限制數非常關鍵，此次電商上雲，神龍將彈性網絡卡和 EBS 雲盤的限制數提高到 64 與 40，有效避免了 CPU 與記憶體的資源浪費。另外對於不同型別的業務，核心配置也會略有差異，例如入口層 aserver 神龍例項由於需要承擔大量的入口流量，對 MOC 的網路收發包能力的要求極高，為避免 AVS 網路軟交換 CPU 打滿，對於神龍 MOC 卡里的網路和儲存的 CPU 分配引數的需求不同，常規計算型神龍例項的 MOC 卡網路/儲存的 CPU 分配是 4+8，而 aserver 神龍例項需要配置為 6:6；例如對於雲上混部機型，需要為離線任務提供獨立的 nvme 本盤例項。為不同型別業務合理規劃機型和規格，會極大程度的降低成本，保證效能和穩定性。

資源彈性

雙11 需要海量的計算資源來扛住洪峰流量，但這部分資源不可能常態化持有，所以需要合理劃分日常叢集與大促叢集，並在 雙11 前幾周，通過大規模節點彈性擴容能力，從阿里雲彈性申請大批量神龍，部署在獨立的大促叢集分組裡，並大規模擴容 Kubernetes Pod 交付業務計算資源。在 雙11 過後，立即將大促叢集中的 Pod 容器批量縮容下線，大促叢集神龍例項整體銷燬下線，日常只持有常態化神龍例項，通過大規模叢集彈性擴縮容能力，可大幅節約大促成本。另外從神龍交付週期而言，今年上雲後從申請到建立機器，從小時/天級別縮短到了分鐘級，上千臺神龍可在 5 分鐘內完成申請，包括計算、網路、儲存資源；在 10 分鐘內完成建立並匯入 Kubernetes 叢集，叢集建立效率大幅度提高，為未來常態化彈性資源池奠定基礎。

核心指標

對於大規模神龍叢集運維，有三個非常核心的指標可以來衡量叢集整體健康度，分別是宕機率、可排程率、線上率。

雲上神龍宕機原因通常分為硬體問題和核心問題。通過對日宕機率趨勢統計和宕機根因分析，可量化叢集的穩定性，避免出現潛在的大規模宕機風險出現。可排程率是衡量叢集健康度的關鍵指標，叢集機器會因為各種軟硬體原因出現容器無法排程到這些異常機器上，例如 Load 大於 1000、磁碟出現壓力、docker 程序不存在，kubelet 程序不存在等，在 Kubernetes 叢集中，這批機器的狀態會是 notReady。2019 年 雙11，我們通過神龍宕機重啟與冷遷移特性，極大提升了故障機輪轉效率，使神龍叢集的可排程率始終維持在 98% 以上，大促資源備容從容。而 雙11 神龍的宕機率維持在 0.2‰ 以下，表現相當穩定。

標籤管理

隨著叢集規模的增加，管理難度也隨之變大。例如如何能篩選出 "cn-shanghai"Region 下生產環境，且例項規格為 "ecs.ebmc6-inc.26xlarge" 的所有機器。我們通過定義大量的預置標籤來實現批量資源管理。在 Kubernetes 架構下，通過定義 Label 來管理機器。Label 是一個 Key-Value 健值對，可在神龍節點上使用標準 Kubernetes 的介面打 Label。例如機器例項規格的 Label 可定義 "sigma.ali/machine-model":"ecs.ebmc6-inc.26xlarge", 機器所在的 Region 可定義為 "sigma.ali/ecs-region-id":"cn-shanghai"。通過完善的標籤管理系統，可從幾萬臺神龍節點中快速篩選機器，執行諸如灰度分批次服務釋出、批量重啟、批量釋放等常規運維操作。

宕機分析

對於超大規模叢集，日常宕機是非常普遍的事情，對宕機的統計與分析非常關鍵，可以甄別出是否存在系統性風險。宕機的情況分為很多種，硬體故障會導致宕機，核心的 bug 等也會導致宕機，一旦宕機以後，業務就會中斷，有些有狀態應用就會受到影響。我們通過 ssh 與埠 ping 巡檢對資源池的宕機情況進行了監控，統計宕機歷史趨勢，一旦有突增的宕機情況就會報警；同時對宕機的機器進行關聯分析，如根據機房、環境、單元、分組 進行歸類，看是否跟某個特定的機房有關；對機型、CPU 進行分類統計，看是否跟特定的硬體有關係；同時 OS 版本、核心版本進行歸類，看是否都發生在某些特定的核心上。

對宕機的根因，也進行了綜合的分析，看是硬體故障，還是有主動運維事件。核心的 kdump 機制會在發生 crash 的時候生成 vmcore，我們也對 vmcore 裡面提取的資訊進行歸類，看某一類特定的 vmcore 關聯的宕機數有多少。核心日誌有些出錯的資訊，如 mce 日誌、soft lockup 的出錯資訊等，也能發現系統在宕機前後是否有異常。

通過這一系列的宕機分析工作，把相應的問題提交給核心團隊，核心專家就會分析 vmcore，屬於核心的缺陷會給出 hotfix 解決這些導致宕機的問題。

節點自愈

運維大規模神龍叢集不可避免地會遇到軟硬體故障，而在雲上技術棧更厚，出現問題會更為複雜。如果出問題單純依靠人工來處理是不現實的，必須依賴自動化能力來解決。1-5-10 節點自愈可提供 1 分鐘異常問題發現，5 分鐘定位，10 分鐘修復的能力。主要的神龍機器異常包括宕機、夯機、主機 load 高、磁碟空間滿、too many openfiles、核心服務（Kubelet、Pouch、Star-Agent）不可用等。主要的修復動作包括宕機重啟、業務容器驅逐、異常軟體重啟、磁碟自動清理，其中 80% 以上的問題可通過重啟宕機機器與將業務容器驅逐到其他節點完成節點自愈。另外我們通過監聽神龍 Reboot 重啟與 Redepoly 例項遷移兩個系統事件來實現 NC 側系統或硬體故障的自動化修復。

未來展望

2020 年 雙11，阿里巴巴經濟體基礎設施將會 100% 基於 Kubernetes，基於 runV 安全容器的下一代混部架構將會大規模落地，輕量化容器架構會演進到下一階段。

在此大背景下，一方面 Kubernetes 節點管理將會朝向阿里巴巴經濟體並池管理方向發展，打通雲庫存管理，提升節點彈效能力，根據業務特性錯峰資源利用，進一步降低機器持有時間從而大幅降低成本。

在技術目標上，我們會採用基於 Kubernetes Machine-Operator 的核心引擎，提供高度靈活的節點運維編排能力，支援節點運維狀態的終態維持。另一方面，基於完整的全域資料採集和分析能力，提供極致的全鏈路監控/分析/核心診斷能力，全面提升容器基礎環境的穩定性，為輕量化容器/不可變基礎設施架構演進提供極致效能觀測與診斷的技術保障。

《不一樣的 雙11 技術：阿里巴巴經濟體雲原生實踐》

雙11 的 2684 億成交額背後是對一個個技術問題的反覆嘗試與實踐。

這一次，我們對雲原生技術在 雙11 的實踐細節進行深挖，篩選了其中 22 篇有代表性的文章進行重新編排，整理成《不一樣的 雙11 技術：阿里巴巴經濟體雲原生實踐》一書。

將為你帶來不一樣的 雙11 雲原生技術亮點：

• 雙11 超大規模 K8s 叢集實踐中，遇到的問題及解決方法詳述；
• 雲原生化最佳組合：Kubernetes+容器+神龍，實現核心系統 100% 上雲的技術細節；
• 雙 11 Service Mesh 超大規模落地解決方案。

“阿里巴巴雲原生微信公眾號（ID：Alicloudnative）關注微服務、Serverless、容器、Service Mesh等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術公眾號。”