![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/dfd4c2e7e5ac482b987045f79434a17b.png)

作者 | 周濤  阿里雲技術專家
來源 | [阿里巴巴雲原生公眾號](https://mp.weixin.qq.com/s/Fm_Pbz0ltu2mpFlDP74_fw)

# 阿里巴巴節點運維的挑戰

![1.png](https://ucc.alicdn.com/pic/developer-ecology/b932f96dc992452aa85f2bbf713ac67d.png)

在阿里巴巴的場景下，做節點運維面臨的挑戰主要來自於這幾個方面：規模、複雜性、穩定性。

**首先是規模大**。從 18 年第一個叢集的搭建，到現線上上共執行著數百個 ASI 叢集、數十萬個節點，其中單叢集的節點數最多有超過1萬臺。在這之上，執行著阿里巴巴集團數萬個不同的應用，比如，大家熟知的淘寶、天貓等，總容器例項數有數百萬規模。ASI 是指 Alibaba Serverless  Infrastructure，也就是阿里巴巴 Serverless 基礎設施。ASI 的概念同時包含叢集的管控面和節點兩方面。每一個 ASI 叢集都是呼叫 Aliyun 標準的 OpenAPI 建立的 ACK 託管版叢集，然後在此之上，我們自研了排程器、開發部署了很多的 addon，進行功能增強、效能最佳化，並對接集團的各個系統，並做到節點全託管，不需要應用開發運維人員關心底層的容器基礎設施。

**其次是環境非常複雜**。目前 IaaS 層執行著很多種異構的機型，有x86伺服器，也有 ARM 國產化機型，同時為了服務新計算、AI 的業務，也有 GPU、FPGA 的機型。線上的核心版本也非常多，4.19 是去年開始規模上線的核心版本，同時 3.10 / 4.9 核心版本上的節點問題也需要繼續支撐，不同的核心版本演進也需要具備規模化輪轉的運維能力。目前上萬個線上應用包含了像淘寶、天貓、菜鳥、高德、餓了麼、考拉、盒馬 等各種不同的業務，同時跟線上應用一起執行著混部、安全容器的業務，像大資料、離線計算、實時計算、搜尋等這些業務型別也都跟線上業務執行在同一個主機環境中。

**最後是對穩定性的高要求**。線上業務的特點是對延遲和抖動非常敏感，單節點的抖動、夯機、當機等故障都可能會影響某個使用者在淘寶的下單付款，引發使用者的吐槽和投訴，所以整體對穩定性的要求非常高，要求對單節點故障的處理有很高的及時性和有效性。

# KubeNode：雲原生節點運維底座介紹

![2.png](https://ucc.alicdn.com/pic/developer-ecology/617ea60e090b4eaa94ff342241da1aeb.png)

KubeNode，是阿里巴巴自研的基於雲原生方式來管理和運維節點的底座專案，相比於傳統的過程式的運維手段，KubeNode 透過 K8s 擴充套件 CRD 以及對應的一組 Operator，能提供完整的節點生命週期和節點元件生命週期管理，透過申明式、面向終態的方式，把節點及節點元件的管理變得跟管理 K8s 中的一個應用一樣簡單，並實現節點的高度一致性以及自愈修復的能力。

上圖右側是 KubeNode 一個簡化的架構，整體是由這幾個部分組成的：

中心端有 Machine Operator 負責節點和節點元件管理，Remedy Operator 負責節點的故障自愈修復。節點側有 Kube Node Agent，這個單機 agent 元件負責 watch 中心 Machine Operator、Remedy Operator 生成的 CRD 物件例項，並執行相應的操作，像節點元件的安裝、故障自愈任務的執行等。

配合著 KubeNode，阿里巴巴還使用 NPD 進行單機的故障檢測，以及對接 Kube Defender (阿里自研元件)  進行統一風控。當然社群版本的 NPD 提供的故障檢測項是比較有限的，阿里巴巴在社群的基礎上進行了擴充套件，結合阿里巴巴多年節點、容器運維的實踐，加入了很多節點的故障檢測項，大大豐富了單機故障檢測的能力。

## 1. KubeNode 和社群專案關係

- github.com / kube-node：不相關，該專案 2018 年初已停止。

- ClusterAPI：KubeNode 可以作為 ClusterAPI 節點終態的補充。

功能對比：

![3.jpg](https://ucc.alicdn.com/pic/developer-ecology/55f098937bb249b2ab251f7c481cd556.jpg)

這裡解釋下阿里巴巴自研的 KubeNode 專案跟社群專案的關係。大家看到 kube-node 這個名字的時候，可能會覺得有點似曾相識，在 github 上是有一個同名的專案 github.com/kube-node，但其實這個專案早在 2018 年初的時候就已經停止了，所以只是名字相同，兩者並沒有關係。

另外社群的 ClusterAPI 是一個建立並管理 K8s 叢集和節點的專案，這裡對比了兩個專案的關係：

- 叢集建立：ClusterAPI 負責叢集的建立，KubeNode 不提供此功能。
- 節點建立：ClusterAPI 和 KubeNode 都可以建立節點。
- 節點元件管理和終態維持：ClusterAPI 沒有提供相應的功能，KubeNode 可以管理節點元件並保持終態。
- 節點故障自愈：ClusterAPI 主要提供基於節點健康狀態重建節點的自愈能力；KubeNode 提供了更豐富的節點元件自愈功能，能對節點上的各種軟硬體故障進行自愈修復。

總的來說，KubeNode 可以和 ClusterAPI 一起配合工作，是對 ClusterAPI 的一個很好補充。

這裡提到的節點元件，是指執行在節點上的 kubelet，Docker 的軟體，阿里內部使用 Pouch 作為我們的容器執行時。除了 kubelet，Pouch 這些排程必須的元件外，還有用於分散式容器儲存、監控採集、安全容器、故障檢測等總共十多個元件。

通常安裝升級 kubelet，Docker 是透過類似 Ansible 等程式導向的一次性動作來完成的。在長時間執行過程中，軟體版本被意外修改或是碰到 bug 不能工作的問題是很常見的，同時這些元件在阿里巴巴的迭代速度非常快，往往一兩週就需要釋出推平一個版本。為了滿足元件快速迭代又能安全升級、版本一致的需求，阿里巴巴自研了 KubeNode，透過將節點以及節點元件透過 K8s CRD 的方式進行描述，並進行面向終態的管理，從而確保版本一致性，配置一致性以及執行態正確性。

## 2. KubeNode - Machine Operator

![4.jpg](https://ucc.alicdn.com/pic/developer-ecology/7b4aa45aa653455995f1cbe5b53a6dfb.jpg)

![5.jpg](https://ucc.alicdn.com/pic/developer-ecology/bcf54bfd62224426b3f9c45124a3780e.jpg)

上圖是 Machine Operator 的架構，一個標準的 Operator 設計：擴充套件的一組 CRD 再加上中心的控制器。
CRD 定義包括：跟節點相關的 Machine、MachineSet，以及跟節點元件相關的 MachineComponent、MachineComponentSet。

中心端的控制器包括：Machine Controller、MachineSet Controller、MachineComponentSet Controller，分別用來控制節點的建立、匯入，節點元件的安裝、升級。

Infra Provider 具有可擴充套件性，可以對接不同的雲廠商，目前只對接了阿里雲，但是也可透過實現相應的 Provider 實現對接 AWS、Azure 等不同的雲廠商。

單機上的 KubeNode 負責 watch CRD 資源，當發現有新的物件例項時，則進行節點元件的安裝升級，定期檢查各個元件是否執行正常，並上報元件的執行狀態。

### 1）Use Case：節點匯入

![6.jpg](https://ucc.alicdn.com/pic/developer-ecology/a0bf4116d0d34f5f9a59151247658076.jpg)

下面分享基於 KubeNode 對已有節點的匯入過程。

首先使用者會在我們的多叢集管理系統中提交一個已有節點的匯入操作，接下來系統先下發證書，並安裝 KubeNode Agent，等 agent 正常執行並啟動之後，第3步會提交 Machine CRD，接下來 Machine Controller 會修改狀態為匯入 phase，並等 Node ready 之後從 Machine 上同步 label / taint 到 Node。第 5 步是 MachineComponentSet， 根據 Machine 的資訊確定要安裝的節點元件，並同步到 Machine 上。最後 Kube Node Agent 會 watch 到 Machine、MachineComponent 的資訊，完成節點元件的安裝，並等所有元件執行正常後，節點匯入操作完成。整個過程跟使用者提交一個 Deployment 並最終啟動一個業務 Pod 是類似的。

節點元件的終態一致主要包含了軟體版本、軟體配置和執行狀態的正確、一致。

### 2）Use Case：元件升級

![7.jpg](https://ucc.alicdn.com/pic/developer-ecology/e2fd4b041713462c8abf98acda2443ff.jpg)

這裡介紹下元件的升級過程，主要依賴的是 MachineComponentSet Controller 提供的分批次升級的能力。

首先使用者在多叢集管理系統上面提交一個元件升級操作，然後就進入一個逐批次迴圈升級的過程：先更新 MachineComponentSet 一個批次升級的機器數量是多少，之後 MachineComponentSet Controller 會計算並更新相應數量的節點上元件的版本資訊。接下來 Kube Node Agent watch 到元件的變化，執行新版本的安裝，並檢查狀態正常後上報元件狀態正常。當這個批次所有的元件都升級成功後，再開始下一個批次的升級操作。

上面描述的單叢集單個元件的升級流程是比較簡單的，但對於線上十多個元件、上百個叢集，要在所有的叢集都完成版本推平工作就不那麼簡單了，我們透過 ASIOps 叢集統一運維平臺進行操作。在 ASIOps 系統中，將上百個叢集配置到了有限的幾個釋出流水線，每條釋出流水線都按照：測試 -> 預發 -> 正式 的順序編排。一次正常的釋出流程，就是選定一條釋出流水線，按其預先設定好的叢集順序進行釋出，在每個叢集內部，又按照 1/5/10/50/100/... 的順序進行自動釋出，每一個批次釋出完成，會觸發健康巡檢，如果有問題則暫停自動釋出，沒問題的話等觀察期結束，則自動開始下一個批次的釋出。透過這樣的方式，做到了既安全又高效的完成一個元件新版本釋出上線的過程。

## 3. KubeNode - Remedy Operator

![8.jpg](https://ucc.alicdn.com/pic/developer-ecology/94ec69b9caaa4d79b1e14b5d1e33ccf3.jpg)

![9.jpg](https://ucc.alicdn.com/pic/developer-ecology/634d9845919749a684d6621f68c672a5.jpg)

接下來分享 KubeNode 裡面的 Remedy Operator，也是一個標準的 Operator，用來做故障自愈修復。

Remedy Operator 也是由一組 CRD 以及對應的控制器組成。CRD 定義包括：NodeRemedier 和 RemedyOperationJob，控制器包括：Remedy Controller、RemedyJob Controller，同時也有故障自愈規則的註冊中心，在單機側有 NPD 和 Kube Node Agent。

Host Doctor 是在中心側的一個獨立的故障診斷系統，對接雲廠商獲取主動運維事件並轉換為節點上的故障 Condition。在阿里雲公有云上，ECS 所在的物理機發生的硬體類的故障或是計劃中的運維操作，都會透過標準 OpenAPI 的形式獲取，對接後就可以提前感知節點的問題，並提前自動遷移節點上的業務來避免故障。

### Use Case：夯機自愈

![10.png](https://ucc.alicdn.com/pic/developer-ecology/9ef8fd58b7164478a1321bf76bd294c5.png)

這裡以夯機自愈的案例來介紹一個典型的自愈流程。

首先我們會在多叢集管理系統 ASI Captain 上配置下發 CRD 描述的自愈規則，並且這些規則是可以靈活動態增加的，針對每一種 Node Condition 都可以配置一條對應的修復操作。

接下來節點上的 NPD 會週期性的檢查是否有發生各種型別的故障，當發現核心日誌中有出現 "task xxx blocked for more than 120 seconds" 的異常日誌之後，判定節點夯機，並給 Node 上報故障 Condition，Remedy Controller watch 到變化後，就觸發自愈修復流程：首先會呼叫 Kube Defender 風控中心介面判斷當前自愈操作是否允許執行，透過後就生成 RemedyOperationJob 自愈任務，Kube Node Agent watch 到 job 後執行自愈操作。

可以看到整個自愈流程不依賴於外部第三方系統，透過 NPD 做故障檢測，Remedy Operator 執行自愈修復，以雲原生的方式完成了整個的自愈修復流程，最快可以做到分鐘級的故障發現並修復。同時，透過對 NPD 檢測規則的增強，處理的故障範圍覆蓋了從硬體故障、OS 核心故障、到元件故障的全鏈路修復。值得強調的是，所有的自愈操作都會對接 Kube Defender 統一風控中心，進行分鐘級、小時級、天級別的自愈修復流控，防止當出現 Region / Zone 級別斷網、大規模 io hang、或是其他大面積軟體 bug 的情況下，觸發對整個 Region 所有節點的故障自愈，引發更嚴重的二次故障。

# KubeNode 資料體系

![11.jpg](https://ucc.alicdn.com/pic/developer-ecology/2162c71bd26849819cc4d159aa9ecff9.jpg)

KubeNode 資料體系建設的好壞對整體度量並提升 SLO 起著非常重要的作用。

在節點側，NPD 會檢測故障並上報事件中心，同時 walle 是單機側的指標採集元件，會採集節點以及容器的各種指標項資訊，包括像 CPU / Memory / IO / Network 等常見的指標，以及很多其他的像核心、安全容器等的指標項。中心側 Promethes (阿里雲公有云上的 ARMS 產品) 會採集所有節點的指標並進行儲存，同時也採集擴充套件過的 Kube State Metrics 的資料，獲取 Machine Operator 和 Remedy Operator 的關鍵指標資訊。在獲取到這些資料的基礎之上，再在上層面向使用者，配置監控大盤、故障報警、以及全鏈路診斷的能力。

透過資料體系的建設，我們就可以用來做資源利用率的分析統計，可以提供實時的監控報警，進行故障分析統計，也可以分析整體 KubeNode 中的節點以及節點元件的覆蓋率、一致率、節點自愈的效率，並提供針對節點的全鏈路診斷功能，當排查節點問題時，可以檢視該節點上歷史發生過的所有的事件，從而幫助使用者快速定位原因。

# 未來展望

目前 KubeNode 已經覆蓋了阿里巴巴集團的所有的 ASI 叢集，接下來，將隨著阿里巴巴集團“統一資源池”的專案，推進 KubeNode 覆蓋更大的範圍、更多的場景，讓雲原生的容器基礎設施運維架構發揮更大的價值。

### **作者簡介**

周濤  阿里雲技術專家，2017 年加入的阿里，過去幾年一直負責阿里巴巴數十萬規模叢集節點管控系統的研發工作，參與了歷年的雙十一大促。隨著 2018 年底開始的集團上雲專案，管理的節點從雲下的物理機覆蓋到了阿里雲公有云上的神龍裸金屬伺服器，並支撐 雙11 大促實現了交易核心系統的全面雲原生化改造。

KubeNode：阿里巴巴雲原生容器基礎設施運維實踐

相關文章

KubeNode：阿里巴巴雲原生 容器基礎設施運維實踐

相關文章

KubeNode：阿里巴巴雲原生容器基礎設施運維實踐