在大規(guī)模 Kubernetes 集群上實(shí)現(xiàn)高 SLO 的方法

作者 |?

螞蟻金服技術(shù)專家 姚菁華

螞蟻金服高級(jí)開(kāi)發(fā)工程師 范康

導(dǎo)讀：隨著 Kubernetes 集群規(guī)模和復(fù)雜性的增加，集群越來(lái)越難以保證高效率、低延遲的交付 pod。本文將分享螞蟻金服在設(shè)計(jì) SLO?架構(gòu)和實(shí)現(xiàn)高 SLO 的方法和經(jīng)驗(yàn)。

Why SLO?

Gartner 對(duì) SLO 的定義：在 SLA 框架下，SLO 是系統(tǒng)必須要達(dá)到的目標(biāo)；需要盡可能地保障調(diào)用方的成功。有些人可能會(huì)對(duì) SLI/SLO/SLA 有困惑，可以先來(lái)看下三者的關(guān)系：

• SLI 定義一個(gè)指標(biāo)，來(lái)描述一個(gè)服務(wù)有多好算達(dá)到好的標(biāo)準(zhǔn)。比如 Pod 在 1min 內(nèi)交付。我們通常從遲延、可用性、吞吐率及成功率這些角度來(lái)制定 SLI。

• SLO 定義了一個(gè)小目標(biāo)，來(lái)衡量一個(gè) SLI 指標(biāo)在一段時(shí)間內(nèi)達(dá)到好的標(biāo)準(zhǔn)的比例。比如說(shuō)，99% 的 Pod 在 1min 內(nèi)交付。當(dāng)一項(xiàng)服務(wù)公布了其 SLO 的以后，用戶方就會(huì)對(duì)該服務(wù)的質(zhì)量有了期望。

• SLA 是 SLO 衍生出來(lái)的協(xié)議，常用于 SLO 定義的目標(biāo)比例沒(méi)有完成時(shí)，服務(wù)方要賠多少錢。通常來(lái)說(shuō)，SLA 的協(xié)議會(huì)具體白紙黑字形成有法律效率的合同，常用于服務(wù)供應(yīng)商和外部客戶之間（例如阿里云和阿里云的使用者）。一般來(lái)說(shuō)對(duì)于內(nèi)部服務(wù)之間的 SLO 被打破，通常不會(huì)是經(jīng)濟(jì)上的賠償，可能更多的是職責(zé)上的認(rèn)定。

所以，我們?cè)谙到y(tǒng)內(nèi)部更多關(guān)注的是 SLO。

What?we concern?about Larger?K8s?Cluster?

隨著生產(chǎn)環(huán)境不斷發(fā)展、K8s 集群越來(lái)越復(fù)雜、集群規(guī)模不斷增大。如何保障大規(guī)模環(huán)境 K8s 集群的可用性？是擺在眾多廠家面前的一個(gè)難題。對(duì)于 K8s 集群，我們通常關(guān)心以下幾個(gè)問(wèn)題：

• 第一個(gè)問(wèn)題就是集群是否健康，所有組件是否正常工作，集群中 Pod 創(chuàng)建的失敗數(shù)量有多少，這是一個(gè)整體指標(biāo)的問(wèn)題。

• 第二個(gè)問(wèn)題就是集群中發(fā)生了什么，集群中是否有異常發(fā)生了，用戶在集群中做了些什么事情，這是一個(gè)追蹤能力的問(wèn)題。

• 第三個(gè)問(wèn)題就是有了異常后，是哪個(gè)組件出了問(wèn)題導(dǎo)致成功率降低，這是一個(gè)原因定位的問(wèn)題。

那么，我們?cè)撊绾谓鉀Q上面的問(wèn)題呢？

• 首先，我們要定義一套 SLO，來(lái)描述集群的可用性。

• 接著，我們必須有能力對(duì)集群中 Pod 的生命周期進(jìn)行追蹤；對(duì)于失敗的 Pod，還需要分析出失敗原因，以快速定位異常組件。

• 最后，我們要通過(guò)優(yōu)化手段，消除集群的異常。

SLls?on Large K8s Cluster

我們先來(lái)看下集群的一些指標(biāo)。

• 第一項(xiàng)指標(biāo)：集群健康度。目前有 Healthy/Warning/Fatal 三個(gè)值來(lái)描述，Warning 和 Fatal 對(duì)應(yīng)著告警體系，比如 P2 告警發(fā)生，那集群就是 Warning；如果 P0 告警發(fā)生，那集群就是 Fatal，必須進(jìn)行處理。

• 第二項(xiàng)指標(biāo)：成功率。這里的成功率是指 Pod 的創(chuàng)建成功率。Pod 成功率是一個(gè)非常重要的指標(biāo)，螞蟻一周 Pod 創(chuàng)建量是百萬(wàn)級(jí)的，成功率的波動(dòng)會(huì)造成大量 Pod 的失敗；而且 Pod 成功率的下跌，是集群異常的最直觀反應(yīng)。

• 第三項(xiàng)指標(biāo)：殘留 Terminating Pod 的數(shù)量。為什么不用刪除成功率呢？因?yàn)樵诎偃f(wàn)級(jí)別的時(shí)候，即使 Pod 刪除成功率達(dá)到 99.9%，那么 Terminating Pod 的數(shù)量也是千級(jí)別的。殘留如此多的 Pod，會(huì)占著應(yīng)用的容量，在生產(chǎn)環(huán)境中是不可接受的。

• 第四項(xiàng)指標(biāo)：服務(wù)在線率。服務(wù)在線率是通過(guò)探針來(lái)衡量的，探針失敗，意味著集群不可用。服務(wù)在線率是會(huì)對(duì) Master 組件來(lái)設(shè)計(jì)的。

• 最后一項(xiàng)指標(biāo)：故障機(jī)數(shù)量，這是一個(gè)節(jié)點(diǎn)維度的指標(biāo)。故障機(jī)通常是指那些無(wú)法正確交付 Pod 的物理機(jī)，可能是磁盤滿了，可能是 load 太高了。集群故障機(jī)并須做到“快速發(fā)現(xiàn)，快速隔離，及時(shí)修復(fù)”，畢竟故障機(jī)會(huì)對(duì)集群容量造成影響。

The success standard and reason classification

有了集群的指標(biāo)后，我們需要把這些指標(biāo)進(jìn)行細(xì)化，定義出成功的標(biāo)準(zhǔn)。

先來(lái)看 Pod 創(chuàng)建成功率指標(biāo)。我們把 Pod 分為了普通 Pod 和 Job 類 Pob。普通 Pod 的 RestartPolicy 為 Always，Job 類 Pod 的 RestartPlicy 為 Never 或 OnFailure。兩者都設(shè)定有交付時(shí)間，比如必須在 1 分鐘以內(nèi)完成交付。普通 Pod 的交付標(biāo)準(zhǔn)是 1min 內(nèi) Pod 已經(jīng) Ready；Job 類 Pod 的交付標(biāo)準(zhǔn)是 1min 內(nèi) Pod 的狀態(tài)已達(dá) Running、Succeeded 或 Failed。當(dāng)然創(chuàng)建的時(shí)間需要把 PostStartHook 執(zhí)行時(shí)間排除。

對(duì)于 Pod 的刪除，成功的標(biāo)準(zhǔn)為：在規(guī)定時(shí)間內(nèi)，Pod 從 ETCD 內(nèi)刪除。當(dāng)然，刪除的時(shí)間需要把 PreStopHookPeriod 時(shí)間排除。

對(duì)于故障機(jī)，要盡快的發(fā)現(xiàn)并進(jìn)行隔離和降級(jí)。比如物理機(jī)磁盤只讀，那必須在 1min 內(nèi)完成對(duì)該 Pod 打 taint。至于故障機(jī)的恢復(fù)時(shí)間，需要按不同的故障原因，制定不同的恢復(fù)時(shí)間。比如系統(tǒng)故障需要重要安裝系統(tǒng)，那恢復(fù)時(shí)間就會(huì)長(zhǎng)些。

有了這些標(biāo)準(zhǔn)后，我們也對(duì) Pod 失敗的原因進(jìn)行了整理，有些失敗原因是系統(tǒng)引起的，是我們需要關(guān)心的；有些失敗原因是用戶引發(fā)的，是我們不需要關(guān)心的。

比如 RuntimeError，就是一個(gè)系統(tǒng)錯(cuò)誤，底層 Runtime 有問(wèn)題了；ImagePullFailed，Kubelet 下載鏡像失敗，由于螞蟻有 Webhook 對(duì)鏡像準(zhǔn)入做了校驗(yàn)，所有鏡像下載失敗一般都是系統(tǒng)原因造成的。

對(duì)于用戶原因，在系統(tǒng)側(cè)無(wú)法解決，我們只把這些失敗原因以接口查詢的方式提供給用戶，讓用戶自己解決。比如 ContainerCrashLoopBackOff，通常是由用戶容器退出引起的。

The infrastructure

圍繞 SLO 目標(biāo)，我們構(gòu)建了一整套體系，一方面用于向終端用戶、運(yùn)維人員展示當(dāng)前集群各項(xiàng)指標(biāo)狀；另一方面，各個(gè)組件相互協(xié)作，通過(guò)分析當(dāng)前集群狀態(tài)，得到影響 SLO 的各項(xiàng)因素，為提升集群 pod 交付成功率提供數(shù)據(jù)支持。

自頂向下而看，頂層組件主要面向各種指標(biāo)數(shù)據(jù)， 如集群健康狀態(tài)、pod 創(chuàng)建、刪除、升級(jí)成功率，殘留 pods 數(shù)量、不健康節(jié)點(diǎn)數(shù)量等指標(biāo)。其中 Display Board 就是我們常說(shuō)的監(jiān)控大盤。

我們同樣構(gòu)建了 Alert 告警子系統(tǒng)，支持靈活的配置方式，可以為不同的指標(biāo)，根據(jù)指標(biāo)的下跌百分比，指標(biāo)下跌絕對(duì)值等配置多種告警方式，如電話，短信，郵件等。

Analysis System 通過(guò)分析指標(biāo)歷史數(shù)據(jù)，以及采集到的節(jié)點(diǎn) metrics 和 master 組件指標(biāo)，給出更詳細(xì)的集群運(yùn)營(yíng)報(bào)告。其中：

• Weekly Report 子系統(tǒng)給出當(dāng)前集群本周 pod 創(chuàng)建/刪除/升級(jí)的數(shù)據(jù)統(tǒng)計(jì)，以及失敗案例原因匯總。

• Terminating Pods Number 給出一段時(shí)間內(nèi)集群內(nèi)新增的無(wú)法通過(guò) K8s 機(jī)制刪除的 pods 列表和 pods 殘留原因。

• Unhealthy Nodes 則給出一個(gè)周期內(nèi)集群所有節(jié)點(diǎn)的總可用時(shí)間占比，每個(gè)節(jié)點(diǎn)的可用時(shí)間，運(yùn)維記錄，以及不能自動(dòng)恢復(fù)，需要人工介入恢復(fù)的節(jié)點(diǎn)列表。

為了支撐上述這些功能，我們開(kāi)發(fā)了 Trace System，用來(lái)分析展示單個(gè) pod 創(chuàng)建/刪除/升級(jí)失敗的具體原因。其中包含日志和事件采集、數(shù)據(jù)分析和 pod 生命周期展示三個(gè)模塊：

• 日志和事件采集模塊采集各 master 組件以及節(jié)點(diǎn)組件的運(yùn)行日志和 pod/node 事件，分別以 pod/node 為索引存儲(chǔ)日志和事件。

• 數(shù)據(jù)分析模塊分析還原出 pod 生命周期中各階段用時(shí)，以及判斷 pod 失敗原因及節(jié)點(diǎn)不可用原因。

• 最后，由 Report 模塊向終端用戶暴露接口和 UI，向終端用戶展示 pod 生命周期以及出錯(cuò)原因。

The trace system

接下來(lái)，以一個(gè) pod 創(chuàng)建失敗案例為例，向大家展示下 tracing 系統(tǒng)的工作流程。

用戶輸入 pod uid 之后，tracing system 通過(guò) pod 索引，查找到 pod 對(duì)應(yīng)生命周期分析記錄、交付成功與否判定結(jié)果。當(dāng)然，storage 存儲(chǔ)的數(shù)據(jù)不僅為終端用戶提供基礎(chǔ)數(shù)據(jù)，更重要的是通過(guò)對(duì)集群內(nèi) pods 生命周期，分析出周期內(nèi)集群的運(yùn)營(yíng)狀況及每個(gè)節(jié)點(diǎn)的運(yùn)營(yíng)狀況。比如說(shuō)集群內(nèi)太多 pods 調(diào)度到熱點(diǎn)節(jié)點(diǎn)，不同 pods 的交付引起節(jié)點(diǎn)上資源競(jìng)爭(zhēng)，導(dǎo)致節(jié)點(diǎn)負(fù)載太高，而交付能力卻在下降，最終表現(xiàn)為節(jié)點(diǎn)上 pods 交付超時(shí)。

再舉個(gè)例子，通過(guò)歷史統(tǒng)計(jì)數(shù)據(jù)，分析出 pods 生命周期中各階段的執(zhí)行時(shí)間基線，以基線為評(píng)估標(biāo)準(zhǔn)，比較組件不同版本的平均用時(shí)、用時(shí)分布，給出組件改進(jìn)建議。另外，通過(guò)整體的 pods 生命周期中各組件負(fù)責(zé)的步驟時(shí)間占比，找出占比較多的步驟，為后續(xù)優(yōu)化 pod 交付時(shí)間提供數(shù)據(jù)支持。

Node Metrics

一個(gè)運(yùn)行狀況良好的集群，不僅需要 master 組件保持高可用，節(jié)點(diǎn)穩(wěn)定性也不容忽視。

如果把 pod 創(chuàng)建比作是 rpc 調(diào)用，則每個(gè)節(jié)點(diǎn)就是一個(gè) rpc 服務(wù)提供者，集群的總?cè)萘康扔诿總€(gè)節(jié)點(diǎn)能處理的 pod 創(chuàng)建請(qǐng)求的總和。每多一個(gè)不可用的節(jié)點(diǎn)，都代表著集群交付能力的下降，也代表著集群可用資源的下降，這就要求盡量保證集群內(nèi)節(jié)點(diǎn)高可用；每一次 pod 交付/刪除/升級(jí)失敗，也意味著用戶使用成本上升，體驗(yàn)下降，這就要求集群節(jié)點(diǎn)只有保證良好的健康度，調(diào)度到節(jié)點(diǎn)上的 pods 才能成功交付。

換句話說(shuō)，不僅要盡早發(fā)現(xiàn)節(jié)點(diǎn)異常，也要盡快修復(fù)節(jié)點(diǎn)。通過(guò)分析各組件在 pod 交付鏈路上的功能，我們補(bǔ)充了各種不同類型的組件的 metrics，以及將 host 運(yùn)行狀態(tài)轉(zhuǎn)換為 metrics，一并采集到數(shù)據(jù)庫(kù)之后，結(jié)合每個(gè)節(jié)點(diǎn)上 pod 交付結(jié)果，可以構(gòu)建模型預(yù)測(cè)節(jié)點(diǎn)可用性，分析節(jié)點(diǎn)是否存在不可恢復(fù)異常，適當(dāng)調(diào)整節(jié)點(diǎn)在調(diào)度器中比重，從而提升 pod 交付成功率。

Pod 創(chuàng)建/升級(jí)失敗，用戶可以通過(guò)重試來(lái)解決，但 pod 刪除失敗，雖然有著 K8s 面向終態(tài)的理念，組件會(huì)不斷重試，但終究也會(huì)存在臟數(shù)據(jù)，如 pod 在 etcd 上刪除，但是節(jié)點(diǎn)上還殘留著臟數(shù)據(jù)。我們?cè)O(shè)計(jì)實(shí)現(xiàn)了一個(gè)巡檢系統(tǒng)，通過(guò)查詢 apiserver 獲取調(diào)度到當(dāng)前節(jié)點(diǎn)上的 pods，通過(guò)對(duì)比，找到節(jié)點(diǎn)上殘留的進(jìn)程/容器/volumes 目錄/cgroup /網(wǎng)絡(luò)設(shè)備等，通過(guò)其他途徑嘗試釋放殘留資源。

Unhealthy node

接下來(lái)描述故障機(jī)的處理流程。

故障機(jī)判斷的數(shù)據(jù)來(lái)源有很多，主要有節(jié)點(diǎn)的監(jiān)控指標(biāo)，比如：

• 某類 Volume 掛載失敗

• NPD(Node Problem Detector)，這是社區(qū)的一個(gè)框架

• Trace 系統(tǒng)，比如某個(gè)節(jié)點(diǎn)上 Pod 創(chuàng)建持續(xù)報(bào)鏡像下載失敗

• SLO，比如單機(jī)上殘留大量 Pod

我們開(kāi)發(fā)了多個(gè) Controller 對(duì)這些某類故障進(jìn)行巡檢，形成故障機(jī)列表。一個(gè)故障機(jī)可以有好幾項(xiàng)故障。對(duì)于故障機(jī)，會(huì)按照故障進(jìn)行不同的操作。主要的操作有：打 Taint，防止 Pod 調(diào)度上去；降低 Node 的優(yōu)先級(jí)；直接自動(dòng)處理進(jìn)行恢復(fù)。對(duì)于一些特殊原因，比如磁盤滿，那就需要人工介入排查。

故障機(jī)系統(tǒng)每天都會(huì)產(chǎn)生一個(gè)日?qǐng)?bào)，來(lái)表明故障機(jī)系統(tǒng)今天做了哪些事情。開(kāi)發(fā)人員可以通過(guò)不斷地添加 Controller 和處理規(guī)則完善整個(gè)故障機(jī)處理系統(tǒng)。

Tips on increasing SLO

接下來(lái)，我們來(lái)分享下達(dá)到高 SLO 的一些方法。

• 第一點(diǎn)，在提升成功率的進(jìn)程中，我們面臨的最大問(wèn)題就是鏡像下載的問(wèn)題。要知道，Pod 必須在規(guī)定時(shí)間內(nèi)交付，而鏡像下載通常需要非常多的時(shí)間。為此，我們通過(guò)計(jì)算鏡像下載時(shí)間，還專門設(shè)置了一個(gè) ImagePullCostTime 的錯(cuò)誤，即鏡像下載時(shí)間太長(zhǎng)，導(dǎo)致 Pod 無(wú)法按時(shí)交付。

還好，阿里鏡像分發(fā)平臺(tái) Dragonfly 支持了 Image lazyload 技術(shù)，也就是支持遠(yuǎn)程鏡像，在 Kubelet 創(chuàng)建容器時(shí)，不用再下載鏡像。所以，這大大加速了 Pod 的交付速度。有關(guān) Image lazyload 技術(shù)，大家可以看下阿里 Dragonfly 的分享。

• 第二點(diǎn)，對(duì)于提升單個(gè) Pod 成功率，隨著成功率的提升，難度也越來(lái)越難。可以引入一些 workload 進(jìn)行重試。在螞蟻，paas 平臺(tái)會(huì)不斷重試，直到 Pod 成功交付或者超時(shí)。當(dāng)然，在重試時(shí)，之前的失敗的節(jié)點(diǎn)需要排除。

• 第三點(diǎn)，關(guān)鍵的 Daemonset 一定要進(jìn)行檢查，如果關(guān)鍵 Daemonset 缺失，而把 Pod 調(diào)度上去，就非常容易出問(wèn)題，從而影響創(chuàng)建/刪除鏈路。這需要接入故障機(jī)體系。

• 第四點(diǎn)，很多 Plugin，如 CSI Plugin，是需要向 Kubelet 注冊(cè)的。可能存在節(jié)點(diǎn)上一切正常，但向 Kubelet 注冊(cè)的時(shí)候失敗，這個(gè)節(jié)點(diǎn)同樣無(wú)法提供 Pod 交付的服務(wù)，需要接入故障機(jī)體系。

• 最后一點(diǎn)，由于集群中的用戶數(shù)量是非常多的，所以隔離非常重要。在權(quán)限隔離的基礎(chǔ)上，還需要做到 QPS 隔離，及容量的隔離，防止一個(gè)用戶的 Pod 把集群能力耗盡，從而保障其他用戶的利益。

?點(diǎn)擊屏末?|?閱讀原文?|?即刻學(xué)習(xí)