作者 | 周濤 阿里雲技術專家
來源 | 阿里巴巴雲原生公眾號
阿里巴巴節點運維的挑戰
在阿里巴巴的場景下，做節點運維面臨的挑戰主要來自於這幾個方面：規模、復雜性、穩定性。
首先是規模大。從 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 大促實現了交易核心系統的全面雲原生化改造。