做者 | 謝瑤瑤（初揚） 來源|阿里巴巴雲原生公衆號html
隨着容器技術的不斷髮展迭代，Kubernetes 已成爲雲原生時代的標準操做系統，那麼如何構建一個穩定自愈的雲原生操做系統事關重大。尤爲是分佈式環境下，各種硬件和軟件故障已成爲常態，直接致使 Kubernetes 集羣工做節點時常處於一種不穩定的狀態，人肉運維不只效率低下，誤操做及 24 小時 OnCall 也是巨大的挑戰，所以容器服務經過託管節點池爲用戶提供了一個自愈的免運維的雲上 Kubernetes 集羣服務。本文將重點介紹如何經過託管節點池實現 Kubernetes 節點自愈能力。docker
首先，咱們須要定義什麼是節點自愈？網絡
什麼是節點自愈？
Kubernetes 集羣做爲一個典型的分佈式系統，是由一組 Master 管控節點，加上若干個運行工做負載的節點組成。其中若干個具備相同特性的節點邏輯上組成一個節點池，若是某個節點池的節點運維及生命週期管理由容器服務託管，則稱該節點池爲託管節點池。架構
節點自愈定義在 K8s 節點池之上，指無需人爲干預，工做節點便可自行從故障狀態中恢復。所以節點自愈的一個核心問題是故障狀態處置及其恢復。 好比硬件故障（內存板卡損壞、磁盤壞道、網卡控制器故障）、軟件故障（軟件 OOM、進程句柄泄露、IO hang、磁盤滿、網絡斷鏈）、機房斷電跳閘、光纜故障、系統負載太高等。運維
由此咱們抽象了幾類故障層次。分佈式
- 瞬時故障（網絡抖動，負載升高，應用請求超時，組件 OOM，異常重啓）。
- 持續故障（環境變化觸發未預期狀態）。
- 錯誤（配置錯誤，誤操做，邏輯 Bug。該類型錯誤可能被當即反應，也可能會好久後才能反應，它的特色是須要人爲的知識干預，即便替換副本也沒法解決，智能決策，智能糾錯）。
瞬時故障一般在外部條件恢復後自行恢復，此類故障一般會在能觸發響應以前已經恢復。工具
持續故障一般是咱們須要人爲干預的，一般預示着系統發生了某些比較嚴重的問題，須要專家經驗介入，一般能夠經過自動化的手段應對，屬於本文關注的重點，也是自愈的範疇。測試
錯誤層須要意識的參與，好比配置錯誤，邏輯 Bug，沒有意識參與修復，最終仍然會向錯誤的方向演化，所以不在本文討論範圍以內。人工智能
爲何須要自愈？
自愈的一個出發點是，基礎設施是不穩定的；系統環境是不斷變化的，不肯定的，所以隨時可能發生故障，須要 24 小時待命，干預修復，這對運維提出了很是大的挑戰，所以構建一個自恢復、免運維的 Kubernetes 節點管理體系意義重大。url
自愈的價值：
- 自愈的核心出發點是免運維，將工做人員從繁重的運維事務中解放出來，讓他們專一於創新和更高價值的工做，相信半夜被故障報警折騰起來是每一個運維人員都經歷過的痛。
- 規模化集羣的運維效率，提升人效與時效。（一個節點的運維與一萬個節點的運維在時間上與工做量上具備本質的區別，大規模的節點故障已徹底超出了人肉運維的可控範圍，保姆式的運維是人力資源的極大浪費，成本昂貴）。
- 自動感知節點故障，相比於人肉運維具備更短的響應時間，在故障被終端用戶感知前自行恢復。
- 程序化的工做能解決人爲誤操做引起的故障。
節點的自愈能顯著提高運維效率（時效與人效、降本），下降人爲誤操做致使的問題，加速應用業務創新。
節點自愈的演進
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. 構建智能化的系統
智能化是系統發展的終態，從工具的發展能夠看盡人類的發展史，咱們的終極目標就是發明一個工具能夠爲咱們發明工具，這即是智能化。自動化運維讓咱們向智能化的方向邁進了一小步，自愈是則是自動化的排頭兵。
一個高度自治的系統，會造成系統自愈的閉環，故障的發現到隔離，替換或重置修復，能夠是軟件故障的修復，甚至能夠是硬件故障的自我替換。或許是人類指導人工智能，也多是人工智能指導人類的決策。總之，系統會自我驅動運行。
託管節點池詳細信息請參考文檔。