作者 | 周濤 阿裡雲技術專家
來源 |
阿裡巴巴雲原生公衆号阿裡巴巴節點運維的挑戰
在阿裡巴巴的場景下，做節點運維面臨的挑戰主要來自于這幾個方面：規模、複雜性、穩定性。
首先是規模大。從 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：雲原生節點運維底座介紹
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 節點終态的補充。
功能對比：
這裡解釋下阿裡巴巴自研的 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
上圖是 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：節點導入
下面分享基于 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：元件更新
這裡介紹下元件的更新過程，主要依賴的是 MachineComponentSet Controller 提供的分批次更新的能力。
首先使用者在多叢集管理系統上面送出一個元件更新操作，然後就進入一個逐批次循環更新的過程：先更新 MachineComponentSet 一個批次更新的機器數量是多少，之後 MachineComponentSet Controller 會計算并更新相應數量的節點上元件的版本資訊。接下來 Kube Node Agent watch 到元件的變化，執行新版本的安裝，并檢查狀态正常後上報元件狀态正常。當這個批次所有的元件都更新成功後，再開始下一個批次的更新操作。
上面描述的單叢集單個元件的更新流程是比較簡單的，但對于線上十多個元件、上百個叢集，要在所有的叢集都完成版本推平工作就不那麼簡單了，我們通過 ASIOps 叢集統一運維平台進行操作。在 ASIOps 系統中，将上百個叢集配置到了有限的幾個釋出流水線，每條釋出流水線都按照：測試 -> 預發 -> 正式 的順序編排。一次正常的釋出流程，就是標明一條釋出流水線，按其預先設定好的叢集順序進行釋出，在每個叢集内部，又按照 1/5/10/50/100/... 的順序進行自動釋出，每一個批次釋出完成，會觸發健康巡檢，如果有問題則暫停自動釋出，沒問題的話等觀察期結束，則自動開始下一個批次的釋出。通過這樣的方式，做到了既安全又高效的完成一個元件新版本釋出上線的過程。
3. KubeNode - Remedy Operator
接下來分享 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：夯機自愈
這裡以夯機自愈的案例來介紹一個典型的自愈流程。
首先我們會在多叢集管理系統 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 資料體系
KubeNode 資料體系建設的好壞對整體度量并提升 SLO 起着非常重要的作用。
在節點側，NPD 會檢測故障并上報事件中心，同時 walle 是單機側的名額采集元件，會采集節點以及容器的各種名額項資訊，包括像 CPU / Memory / IO / Network 等常見的名額，以及很多其他的像核心、安全容器等的名額項。中心側 Promethes (阿裡雲公有雲上的 ARMS 産品) 會采集所有節點的名額并進行存儲，同時也采集擴充過的 Kube State Metrics 的資料，擷取 Machine Operator 和 Remedy Operator 的關鍵名額資訊。在擷取到這些資料的基礎之上，再在上層面向使用者，配置監控大盤、故障報警、以及全鍊路診斷的能力。
通過資料體系的建設，我們就可以用來做資源使用率的分析統計，可以提供實時的監控報警，進行故障分析統計，也可以分析整體 KubeNode 中的節點以及節點元件的覆寫率、一緻率、節點自愈的效率，并提供針對節點的全鍊路診斷功能，當排查節點問題時，可以檢視該節點上曆史發生過的所有的事件，進而幫助使用者快速定位原因。
未來展望
目前 KubeNode 已經覆寫了阿裡巴巴集團的所有的 ASI 叢集，接下來，将随着阿裡巴巴集團“統一資源池”的項目，推進 KubeNode 覆寫更大的範圍、更多的場景，讓雲原生的容器基礎設施運維架構發揮更大的價值。
作者簡介
周濤 阿裡雲技術專家，2017 年加入的阿裡，過去幾年一直負責阿裡巴巴數十萬規模叢集節點管控系統的研發工作，參與了曆年的雙十一大促。随着 2018 年底開始的集團上雲項目，管理的節點從雲下的實體機覆寫到了阿裡雲公有雲上的神龍裸金屬伺服器，并支撐 雙11 大促實作了交易核心系統的全面雲原生化改造。