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

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

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

什么是節(jié)點自愈？

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

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

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

瞬時故障（網(wǎng)絡(luò)抖動，負載升高，應(yīng)用請求超時，組件 OOM，異常重啟）。

持續(xù)故障（環(huán)境變化觸發(fā)未預(yù)期狀態(tài)）。

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

瞬時故障通常在外部條件恢復(fù)后自行恢復(fù)，此類故障通常會在能觸發(fā)響應(yīng)之前已經(jīng)恢復(fù)。

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

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

為什么需要自愈？

自愈的一個出發(fā)點是，基礎(chǔ)設(shè)施是不穩(wěn)定的；系統(tǒng)環(huán)境是不斷變化的，不確定的，因此隨時可能發(fā)生故障，需要 24 小時待命，干預(yù)修復(fù)，這對運維提出了非常大的挑戰(zhàn)，因此構(gòu)建一個自恢復(fù)、免運維的 Kubernetes 節(jié)點管理體系意義重大。

自愈的價值：

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

節(jié)點的自愈能顯著提升運維效率（時效與人效、降本），降低人為誤操作導(dǎo)致的問題，加速應(yīng)用業(yè)務(wù)創(chuàng)新。

節(jié)點自愈的演進

1. 第一階段：基于專家經(jīng)驗的進化

自愈的第一種方式是基于專家經(jīng)驗，將專家經(jīng)驗應(yīng)用于自愈系統(tǒng)是最顯而易見的方案。

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

圖 1? 專家經(jīng)驗

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

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

自愈問題的本質(zhì)（自愈困境）

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

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

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

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

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

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

下圖是 K8s 集群下節(jié)點自愈的整體方案架構(gòu)：

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

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

副本替換與重置的挑戰(zhàn)

副本替換與重置方案會使用一個干凈的副本重新初始化節(jié)點，其結(jié)果可控（參考 Docker 鏡像的思路）。它能夠保證提供一個全新的運行時環(huán)境，一個工作符合預(yù)期的集群，符合最終一致性原則。同時相比于專家經(jīng)驗?zāi)軌蚋采w更加廣泛的故障場景，結(jié)果可控。

但同時也面臨著兩大重點挑戰(zhàn)：

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

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

那么如何降低業(yè)務(wù)代價呢？

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

3. 混合方案

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

容器服務(wù) ACK 托管節(jié)點池通過這種混合的方式實現(xiàn)了靈活可配置的節(jié)點自愈，讓用戶從節(jié)點的運維中解放出來，對應(yīng)用提供一個統(tǒng)一的池化視圖，無需關(guān)心底層基礎(chǔ)設(shè)施。

自愈的未來

1. 節(jié)點自愈?vs 集群自愈

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

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

因此，未來不僅僅是節(jié)點的自愈，不僅僅是節(jié)點的 Replaceable。

2. 應(yīng)用標準化

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

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

3. 構(gòu)建智能化的系統(tǒng)

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

一個高度自治的系統(tǒng)，會形成系統(tǒng)自愈的閉環(huán)，故障的發(fā)現(xiàn)到隔離，替換或重置修復(fù)，可以是軟件故障的修復(fù)，甚至可以是硬件故障的自我替換。或許是人類指導(dǎo)人工智能，也可能是人工智能指導(dǎo)人類的決策。總之，系統(tǒng)會自我驅(qū)動運行。

托管節(jié)點池詳細信息請參考文檔。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。