作者 |?謝瑤瑤（初揚）
來源|阿里巴巴云原生公眾號

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

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

什么是節點自愈？

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

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

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

瞬時故障（網絡抖動，負載升高，應用請求超時，組件 OOM，異常重啟）。

持續故障（環境變化觸發未預期狀態）。

錯誤（配置錯誤，誤操作，邏輯 Bug。該類型錯誤可能被立即反應，也可能會很久后才能反應，它的特點是需要人為的知識干預，即使替換副本也無法解決，智能決策，智能糾錯）。

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

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

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

為什么需要自愈？

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

自愈的價值：

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

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

節點自愈的演進

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

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

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

圖 1? 專家經驗

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

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

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

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

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

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

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

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

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

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

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

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

副本替換與重置的挑戰

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

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

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

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

那么如何降低業務代價呢？

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

3. 混合方案

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

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

自愈的未來

1. 節點自愈?vs 集群自愈

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

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

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

2. 應用標準化

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

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

3. 構建智能化的系統

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

一個高度自治的系統，會形成系統自愈的閉環，故障的發現到隔離，替換或重置修復，可以是軟件故障的修復，甚至可以是硬件故障的自我替換?；蛟S是人類指導人工智能，也可能是人工智能指導人類的決策?？傊?#xff0c;系統會自我驅動運行。

托管節點池詳細信息請參考文檔。

總結

以上是生活随笔為你收集整理的托管节点池助力用户构建稳定自愈的 Kubernetes 集群的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。