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

作者 | 謝瑤瑤（初揚）
來源|[阿里巴巴雲原生公眾號](https://mp.weixin.qq.com/s/CLoALO6r9bb3cE7CLTvZUQ)

隨著容器技術的不斷髮展迭代，Kubernetes 已成為雲原生時代的標準作業系統，那麼如何構建一個穩定自愈的雲原生作業系統事關重大。尤其是分散式環境下，各類硬體和軟體故障已成為常態，直接導致 Kubernetes 叢集工作節點時常處於一種不穩定的狀態，人肉運維不僅效率低下，誤操作及 24 小時 OnCall 也是巨大的挑戰，因此容器服務透過託管節點池為使用者提供了一個自愈的免運維的雲上 Kubernetes 叢集服務。本文將重點介紹如何透過託管節點池實現 Kubernetes 節點自愈能力。

首先，我們需要定義什麼是節點自愈？

# 什麼是節點自愈？

**Kubernetes 叢集作為一個典型的分散式系統，是由一組 Master 管控節點，加上若干個執行工作負載的節點組成。其中若干個具有相同特性的節點邏輯上組成一個節點池，如果某個節點池的節點運維及生命週期管理由容器服務託管，則稱該節點池為託管節點池**。

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

**節點自愈**定義在 K8s 節點池之上，指無需人為干預，工作節點即可自行從故障狀態中恢復。因此節點自愈的一個核心問題是故障狀態處置及其恢復。 比如硬體故障（記憶體板卡損壞、磁碟壞道、網路卡控制器故障）、軟體故障（軟體 OOM、程式控制程式碼洩露、IO hang、磁碟滿、網路斷鏈）、機房斷電跳閘、光纜故障、系統負載過高等。

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

由此我們抽象了幾類故障層次。

1. 瞬時故障（網路抖動，負載升高，應用請求超時，元件 OOM，異常重啟）。
1. 持續故障（環境變化觸發未預期狀態）。
1. 錯誤（配置錯誤，誤操作，邏輯 Bug。該型別錯誤可能被立即反應，也可能會很久後才能反應，它的特點是需要人為的知識干預，即使替換副本也無法解決，智慧決策，智慧糾錯）。

瞬時故障通常在外部條件恢復後自行恢復，此類故障通常會在能觸發響應之前已經恢復。

持續故障通常是我們需要人為干預的，通常預示著系統發生了某些比較嚴重的問題，需要專家經驗介入，通常可以透過自動化的手段應對，屬於本文關注的重點，也是自愈的範疇。

錯誤層需要意識的參與，比如配置錯誤，邏輯 Bug，沒有意識參與修復，最終仍然會向錯誤的方向演化，因此不在本文討論範圍之內。

# 為什麼需要自愈？

自愈的一個出發點是，基礎設施是不穩定的；系統環境是不斷變化的，不確定的，因此隨時可能發生故障，需要 24 小時待命，干預修復，這對運維提出了非常大的挑戰，因此構建一個自恢復、免運維的 Kubernetes 節點管理體系意義重大。

**自愈的價值**：

- 自愈的核心出發點是免運維，將工作人員從繁重的運維事務中解放出來，讓他們專注於創新和更高價值的工作，相信半夜被故障報警折騰起來是每個運維人員都經歷過的痛。
- 規模化叢集的運維效率，提高人效與時效。（一個節點的運維與一萬個節點的運維在時間上與工作量上具有本質的區別，大規模的節點故障已完全超出了人肉運維的可控範圍，保姆式的運維是人力資源的極大浪費，成本昂貴）。
- 自動感知節點故障，相比於人肉運維具有更短的響應時間，在故障被終端使用者感知前自行恢復。
- 程式化的工作能解決人為誤操作引發的故障。

節點的自愈能顯著提升運維效率（時效與人效、降本），降低人為誤操作導致的問題，加速應用業務創新。

# 節點自愈的演進

## 1. 第一階段：基於專家經驗的進化

自愈的第一種方式是基於專家經驗，將專家經驗應用於自愈系統是最顯而易見的方案。

專家經驗方案是指將過往的專家運維經驗打包成規則列表，形成故障到解法的預案，當匹配到具體故障的時候觸發對應的修復方案。

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

圖 1  專家經驗

基於專家經驗的好處是，一線運維人員對故障的細節最清楚，因此也成功總結了相應故障解決方案的最優流程，精準把控細節。但不能忽視的一個缺點就是：專家經驗的覆蓋面是相當有限的，不能覆蓋未知故障的解法，而現實場景中已知的故障場景會慢慢收斂，未知故障會逐漸增多，這就造成專家經驗會逐漸滯後，從而自愈的效果會被大打折扣。

那麼是否有更加統一的方案來覆蓋儘可能多的場景，同時又不會帶來經驗滯後問題呢？

### 自愈問題的本質（自愈困境）

這裡我們需要探尋一下自愈難度大的根源。從一個開發運維熟知的 Devops 例子開始。

我們在講 DevOps 的時候會強調開發測試和運維的鴻溝，運維抱怨應用沒有充分測試就提交部署，而開發則抱怨我這裡明明執行的好好的一定是你的使用姿勢不對，然後經過一番痛苦的排查後，會發現問題是開發和運維執行應用的環境差異導致的，這樣的事情在 Devops 時代頻繁發生。Docker 的出現為開發和運維遮蔽了這個問題，docker 透過標準的映象格式，將應用依賴的執行時環境統一打包成標準映象作為交付，完美解決了這個環境問題。當然，裡面還涉及其他的一些應用執行時標準。 當我們回頭看看構建持久穩定的自愈系統時，其實也面臨著同樣的問題。執行時環境的變化給系統帶來了極大的不確定性，這種不確定性（或者叫環境變化）是自愈難度大的根源。系統在執行的過程中會產生不穩定性，系統垃圾、未處理告警堆積、程式碼 Bug 累積、未處理的邊緣異常 Case、一些人為故障源、都會引發的系統 Fail，無法窮舉這些不確定性進一步決定了不可能 100% 的覆蓋所有修復 CASE，因此需要人為時刻照看。

所以我們說自愈難度大，原因在於我們無法事先窮舉所有可能的故障，也就無法完全覆蓋故障解法。並且維護複雜多樣的自愈方案對人類的腦容量來講將會是災難。千奇百怪的故障總會突破任何一個人腦容量的上限。

## 2. 第二階段：基於 Replaceable 的重生

因此，如果想要解決這個問題，我們就需要轉換思路。我們不需要窮舉每個可能引發故障的 Case 逐個修復，只需要在故障發生的時候**驅逐**故障節點上的應用，然後使用一個全新的標準副本簡單地**替換**掉故障源即可。
全新的副本替換與重置方式無需考慮複雜而未知的錯誤，只需要確認錯誤屬於同一類別即可，因此能顯著的縮小自愈的問題域，求解的複雜度大大降低。

與標準的 docker 映象異曲同工之處在於，他們都使用標準的環境來重新初始化節點，這樣不會有執行時的 Surprise，結果可預期。

下圖是 K8s 叢集下節點自愈的整體方案架構：

![4.png](https://ucc.alicdn.com/pic/developer-ecology/92bb2dfb560f43abad7a974cca3dd0e9.png)

這裡我們有意淡化故障的發現方式、面向不同基礎設施的控制通道、metrics 收集、智慧決策、任務編排等介紹，這是一些自愈方案的共性要素。我們重點關注修復方案，即精細化的專家經驗修復（Pets）還是副本替換與重置（Cattle）。

這也是 Kubernetes 哲學基礎，也是我們常說的 Cattle vs Pet. 節點資源在叢集中應當被當做標準化的副本（無差別 Box），因此故障副本替換與重置是最經濟成本的方式，最能達到效用最大化。

### 副本替換與重置的挑戰

副本替換與重置方案會使用一個乾淨的副本重新初始化節點，其結果可控（參考 Docker 映象的思路）。它能夠保證提供一個全新的執行時環境，一個工作符合預期的叢集，符合最終一致性原則。同時相比於專家經驗能夠覆蓋更加廣泛的故障場景，結果可控。

**但同時也面臨著兩大重點挑戰**：

第一個是**時間成本**，當節點替換能夠在 1s 內完成，這可以稱為幾乎沒有成本，當副本的替換需要 5 分鐘才能完成的話，我們會覺得這簡直不可忍受，還是原地修一下更快。那麼造成這種差異的因素又是什麼呢？沒錯，就是人們的預期：對於不同故障判定時間的預期，修復故障所花費時間的預期。所以你的系統在故障持續多久後會失去耐心？**這需要我們儘可能降低副本替換與重置的時間成本**，比如副本要足夠輕量，使替換的時間成本可控。 第二個是**業務代價**。副本替換是否會造成業務的抖動、中斷？這個影響在多大程度上是我們能夠接受的？是否有解決業務影響的相關方案。一般業務影響的來源主要有幾個方面，應用被重啟後已有連線會被迫中斷，應用重啟中間狀態可能丟失，應用遷移時未儲存的臨時資料丟失等。因此需要應用在設計上能夠容忍重啟，具備響應驅逐訊號的能力。

從另一個角度來說，即使不做副本替換，故障一定還會存在，業務代價也不會消除，所以最壞的情況是副本替換不會讓事情變的更糟。

**那麼如何降低業務代價呢？**

答案是構建一套全新的雲原生應用標準，面向失敗的應用設計。必須假定環境是不可信的，隨時面臨故障重啟遷移等等，需要定義並解決流量平滑遷移，資料與狀態遷移等的標準。但這仍然有一段很長的路要走，也是未來智慧化的必經之路。

## 3. 混合方案

**專家經驗和副本替換並不是兩種水火不容的方案，它們各有優點，因此我們可以充分取長補短，對於已知的問題我們透過精細化的專家經驗方式執行修復，能充分保留原有節點的狀態（臨時資料、長連線等）；當故障範疇已超出專家經驗庫的時候，我們啟動應用驅逐與故障副本替換的方式來嘗試兜底修復，從而保證系統的穩定性、業務的連續性**。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/7154600271cc43a39b5dbfe1d8398b45.png)

容器服務 ACK 託管節點池透過這種混合的方式實現了靈活可配置的節點自愈，讓使用者從節點的運維中解放出來，對應用提供一個統一的池化檢視，無需關心底層基礎設施。

# 自愈的未來

## 1. 節點自愈 vs 叢集自愈

我們今天重點討論的是節點維度的自愈，如果我們跳出節點維度，在更大的範圍看待這個事情，是否也有同樣的效果？比如叢集維度（叢集自愈）、PaaS 維度（PaaS 自愈）、公共雲維度（公共雲自愈）。

如果每個維度都是一個無差別化的副本，那麼透過副本替換與重置是否能達到最佳的自愈效果？如何解決時間成本與業務代價？那些我們曾經以為絕對不可能的事，是否也會隨著技術的進步被一次次突破？比如 IP 地址數、記憶體地址。

因此，未來不僅僅是節點的自愈，不僅僅是節點的 Replaceable。

## 2. 應用標準化

應用標準化是自動化到智慧化的前提。每個應用、每個節點、每個叢集在地位上都是對等的，標準的規格、標準的集裝箱。

沒有規矩不成方圓，一套全新的雲原生應用標準勢在必行，讓應用的重啟、流量的平滑遷移、資料狀態儲存與遷移成為常態，應用標準化促成規模效應。應用的標準化為自愈提供堅實的實踐基礎。

## 3. 構建智慧化的系統

智慧化是系統發展的終態，從工具的發展可以看盡人類的發展史，我們的終極目標就是發明一個工具可以為我們發明工具，這便是智慧化。自動化運維讓我們向智慧化的方向邁進了一小步，自愈是則是自動化的排頭兵。

一個高度自治的系統，會形成系統自愈的閉環，故障的發現到隔離，替換或重置修復，可以是軟體故障的修復，甚至可以是硬體故障的自我替換。或許是人類指導人工智慧，也可能是人工智慧指導人類的決策。總之，系統會自我驅動執行。

**託管節點池**詳細資訊請[參考文件](https://help.aliyun.com/document_detail/190616.html?spm=a2c4g.11186623.6.697.61f69041PeDhKG)。

託管節點池助力使用者構建穩定自愈的 Kubernetes 叢集

相關文章