阿里巴巴大規模神龍裸金屬 Kubernetes 集羣運維實踐

做者 | 姚捷（嘍哥）阿里雲容器平臺集羣管理高級技術專家

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

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

集團上雲機器資源形態

阿里巴巴 雙11 採用三地五單元架構，除 2 個混部單元外，其餘 3 個均是雲單元。神龍機型通過 61八、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 的核心引擎，提供高度靈活的節點運維編排能力，支持節點運維狀態的終態維持。另外一方面，基於完整的全域數據採集和分析能力，提供極致的全鏈路監控/分析/內核診斷能力，全面提高容器基礎環境的穩定性，爲輕量化容器/不可變基礎設施架構演進提供極致性能觀測與診斷的技術保障。<br />

---

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

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

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

將爲你帶來不同的 雙11 雲原生技術亮點：

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

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