作者 |?謝瑤瑤（初揚(yáng)）
來(lái)源|阿里巴巴云原生公眾號(hào)

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

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

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

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

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

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

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

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

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

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

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

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

為什么需要自愈？

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

自愈的價(jià)值：

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

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

節(jié)點(diǎn)自愈的演進(jìn)

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

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

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

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

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

那么是否有更加統(tǒng)一的方案來(lái)覆蓋盡可能多的場(chǎng)景，同時(shí)又不會(huì)帶來(lái)經(jīng)驗(yàn)滯后問(wèn)題呢？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. 混合方案

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

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

自愈的未來(lái)

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

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

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

因此，未來(lái)不僅僅是節(jié)點(diǎn)的自愈，不僅僅是節(jié)點(diǎn)的 Replaceable。

2. 應(yīng)用標(biāo)準(zhǔn)化

應(yīng)用標(biāo)準(zhǔn)化是自動(dòng)化到智能化的前提。每個(gè)應(yīng)用、每個(gè)節(jié)點(diǎn)、每個(gè)集群在地位上都是對(duì)等的，標(biāo)準(zhǔn)的規(guī)格、標(biāo)準(zhǔn)的集裝箱。

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

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

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

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

托管節(jié)點(diǎn)池詳細(xì)信息請(qǐng)參考文檔。

總結(jié)

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

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