![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/5a160734b6b94c14b805dc3c53f274c6.png)

作者 | 螞蟻金服技術專家 姚菁華；螞蟻金服高階開發工程師 範康

> **導讀**：隨著 Kubernetes 叢集規模和複雜性的增加，叢集越來越難以保證高效率、低延遲的交付 pod。本文將分享螞蟻金服在設計 SLO 架構和實現高 SLO 的方法和經驗。

# Why SLO?

![1.png](https://ucc.alicdn.com/pic/developer-ecology/6bac40b8fdfe4edaa234dc068fb7d0da.png)

Gartner 對 SLO 的定義：在 SLA 框架下，SLO 是系統必須要達到的目標；需要儘可能地保障呼叫方的成功。有些人可能會對 SLI/SLO/SLA 有困惑，可以先來看下三者的關係：

- **SLI** 定義一個指標，來描述一個服務有多好算達到好的標準。比如 Pod 在 1min 內交付。我們通常從遲延、可用性、吞吐率及成功率這些角度來制定 SLI。

- **SLO** 定義了一個小目標，來衡量一個 SLI 指標在一段時間內達到好的標準的比例。比如說，99% 的 Pod 在 1min 內交付。當一項服務公佈了其 SLO 的以後，使用者方就會對該服務的質量有了期望。

- **SLA **是 SLO 衍生出來的協議，常用於 SLO 定義的目標比例沒有完成時，服務方要賠多少錢。通常來說，SLA 的協議會具體白紙黑字形成有法律效率的合同，常用於服務供應商和外部客戶之間（例如阿里雲和阿里雲的使用者）。一般來說對於內部服務之間的 SLO 被打破，通常不會是經濟上的賠償，可能更多的是職責上的認定。

所以，我們在系統內部更多關注的是 SLO。

# What we concern about Larger K8s Cluster?

![2.png](https://ucc.alicdn.com/pic/developer-ecology/4e0c98ed53f2432f83a7cc57cd749dd4.png)

隨著生產環境不斷髮展、K8s 叢集越來越複雜、叢集規模不斷增大。如何保障大規模環境 K8s 叢集的可用性？是擺在眾多廠家面前的一個難題。對於 K8s 叢集，我們通常關心以下幾個問題：

- 第一個問題就是叢集是否健康，所有元件是否正常工作，叢集中 Pod 建立的失敗數量有多少，這是一個整體指標的問題。

- 第二個問題就是叢集中發生了什麼，叢集中是否有異常發生了，使用者在叢集中做了些什麼事情，這是一個追蹤能力的問題。

- 第三個問題就是有了異常後，是哪個元件出了問題導致成功率降低，這是一個原因定位的問題。

那麼，我們該如何解決上面的問題呢？

- 首先，我們要定義一套 SLO，來描述叢集的可用性。

- 接著，我們必須有能力對叢集中 Pod 的生命週期進行追蹤；對於失敗的 Pod，還需要分析出失敗原因，以快速定位異常元件。

- 最後，我們要透過最佳化手段，消除叢集的異常。

# SLls on Large K8s Cluster

我們先來看下叢集的一些指標。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/40c8096233644b53b04b14225a38f529.png)

- **第一項指標：叢集健康度**。目前有 Healthy/Warning/Fatal 三個值來描述，Warning 和 Fatal 對應著告警體系，比如 P2 告警發生，那叢集就是 Warning；如果 P0 告警發生，那叢集就是 Fatal，必須進行處理。

- **第二項指標：成功率**。這裡的成功率是指 Pod 的建立成功率。Pod 成功率是一個非常重要的指標，螞蟻一週 Pod 建立量是百萬級的，成功率的波動會造成大量 Pod 的失敗；而且 Pod 成功率的下跌，是叢集異常的最直觀反應。

- **第三項指標：殘留 Terminating Pod 的數量**。為什麼不用刪除成功率呢？因為在百萬級別的時候，即使 Pod 刪除成功率達到 99.9%，那麼 Terminating Pod 的數量也是千級別的。殘留如此多的 Pod，會佔著應用的容量，在生產環境中是不可接受的。

- **第四項指標：服務線上率**。服務線上率是透過探針來衡量的，探針失敗，意味著叢集不可用。服務線上率是會對 Master 元件來設計的。

- **最後一項指標：故障機數量**，這是一個節點維度的指標。故障機通常是指那些無法正確交付 Pod 的物理機，可能是磁碟滿了，可能是 load 太高了。叢集故障機並須做到“快速發現，快速隔離，及時修復”，畢竟故障機會對叢集容量造成影響。

# The success standard and reason classification

有了叢集的指標後，我們需要把這些指標進行細化，定義出成功的標準。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/3599d52dc99649af82d87952673dfb64.png)

先來看 Pod 建立成功率指標。我們把 Pod 分為了普通 Pod 和 Job 類 Pob。普通 Pod 的 RestartPolicy 為 Always，Job 類 Pod 的 RestartPlicy 為 Never 或 OnFailure。兩者都設定有交付時間，比如必須在 1 分鐘以內完成交付。普通 Pod 的交付標準是 1min 內 Pod 已經 Ready；Job 類 Pod 的交付標準是 1min 內 Pod 的狀態已達 Running、Succeeded 或 Failed。當然建立的時間需要把 PostStartHook 執行時間排除。

對於 Pod 的刪除，成功的標準為：在規定時間內，Pod 從 ETCD 內刪除。當然，刪除的時間需要把 PreStopHookPeriod 時間排除。

對於故障機，要儘快的發現並進行隔離和降級。比如物理機磁碟只讀，那必須在 1min 內完成對該 Pod 打 taint。至於故障機的恢復時間，需要按不同的故障原因，制定不同的恢復時間。比如系統故障需要重要安裝系統，那恢復時間就會長些。

有了這些標準後，我們也對 Pod 失敗的原因進行了整理，有些失敗原因是系統引起的，是我們需要關心的；有些失敗原因是使用者引發的，是我們不需要關心的。

比如 RuntimeError，就是一個系統錯誤，底層 Runtime 有問題了；ImagePullFailed，Kubelet 下載映象失敗，由於螞蟻有 Webhook 對映象准入做了校驗，所有映象下載失敗一般都是系統原因造成的。

對於使用者原因，在系統側無法解決，我們只把這些失敗原因以介面查詢的方式提供給使用者，讓使用者自己解決。比如 ContainerCrashLoopBackOff，通常是由使用者容器退出引起的。

# The infrastructure

![5.png](https://ucc.alicdn.com/pic/developer-ecology/efdaa8338253478db1664e6f7ced8040.png)

圍繞 SLO 目標，我們構建了一整套體系，一方面用於向終端使用者、運維人員展示當前叢集各項指標狀；另一方面，各個元件相互協作，透過分析當前叢集狀態，得到影響 SLO 的各項因素，為提升叢集 pod 交付成功率提供資料支援。

自頂向下而看，頂層元件主要面向各種指標資料， 如叢集健康狀態、pod 建立、刪除、升級成功率，殘留 pods 數量、不健康節點數量等指標。其中 Display Board 就是我們常說的監控大盤。

我們同樣構建了 Alert 告警子系統，支援靈活的配置方式，可以為不同的指標，根據指標的下跌百分比，指標下跌絕對值等配置多種告警方式，如電話，簡訊，郵件等。

Analysis System 透過分析指標歷史資料，以及採集到的節點 metrics 和 master 元件指標，給出更詳細的叢集運營報告。其中：

- Weekly Report 子系統給出當前叢集本週 pod 建立/刪除/升級的資料統計，以及失敗案例原因彙總。

- Terminating Pods Number 給出一段時間內叢集內新增的無法透過 K8s 機制刪除的 pods 列表和 pods 殘留原因。

- Unhealthy Nodes 則給出一個週期內叢集所有節點的總可用時間佔比，每個節點的可用時間，運維記錄，以及不能自動恢復，需要人工介入恢復的節點列表。

為了支撐上述這些功能，我們開發了 Trace System，用來分析展示單個 pod 建立/刪除/升級失敗的具體原因。其中包含日誌和事件採集、資料分析和 pod 生命週期展示三個模組：

- 日誌和事件採集模組採集各 master 元件以及節點元件的執行日誌和 pod/node 事件，分別以 pod/node 為索引儲存日誌和事件。

- 資料分析模組分析還原出 pod 生命週期中各階段用時，以及判斷 pod 失敗原因及節點不可用原因。

- 最後，由 Report 模組向終端使用者暴露介面和 UI，向終端使用者展示 pod 生命週期以及出錯原因。

# The trace system

接下來，以一個 pod 建立失敗案例為例，向大家展示下 tracing 系統的工作流程。

![6.png](https://ucc.alicdn.com/pic/developer-ecology/87c0e070c7dd43c3805e0c261c01bfab.png)

使用者輸入 pod uid 之後，tracing system 透過 pod 索引，查詢到 pod 對應生命週期分析記錄、交付成功與否判定結果。當然，storage 儲存的資料不僅為終端使用者提供基礎資料，更重要的是透過對叢集內 pods 生命週期，分析出週期內叢集的運營狀況及每個節點的運營狀況。比如說叢集內太多 pods 排程到熱點節點，不同 pods 的交付引起節點上資源競爭，導致節點負載太高，而交付能力卻在下降，最終表現為節點上 pods 交付超時。

再舉個例子，透過歷史統計資料，分析出 pods 生命週期中各階段的執行時間基線，以基線為評估標準，比較元件不同版本的平均用時、用時分佈，給出元件改進建議。另外，透過整體的 pods 生命週期中各元件負責的步驟時間佔比，找出佔比較多的步驟，為後續最佳化 pod 交付時間提供資料支援。

# Node Metrics

![7.png](https://ucc.alicdn.com/pic/developer-ecology/9908f44e2ab14452aebc1ad56762e2d3.png)

一個執行狀況良好的叢集，不僅需要 master 元件保持高可用，節點穩定性也不容忽視。

如果把 pod 建立比作是 rpc 呼叫，則每個節點就是一個 rpc 服務提供者，叢集的總容量等於每個節點能處理的 pod 建立請求的總和。每多一個不可用的節點，都代表著叢集1交付能力的下降，也代表著叢集可用資源的下降，這就要求儘量保證叢集內節點高可用；每一次 pod 交付/刪除/升級失敗，也意味著使用者使用成本上升，體驗下降，這就要求叢集節點只有保證良好的健康度，排程到節點上的 pods 才能成功交付。

換句話說，不僅要儘早發現節點異常，也要儘快修復節點。透過分析各元件在 pod 交付鏈路上的功能，我們補充了各種不同型別的元件的 metrics，以及將 host 執行狀態轉換為 metrics，一併採集到資料庫之後，結合每個節點上 pod 交付結果，可以構建模型預測節點可用性，分析節點是否存在不可恢復異常，適當調整節點在排程器中比重，從而提升 pod 交付成功率。

Pod 建立/升級失敗，使用者可以透過重試來解決，但 pod 刪除失敗，雖然有著 K8s 面向終態的理念，元件會不斷重試，但終究也會存在髒資料，如 pod 在 etcd 上刪除，但是節點上還殘留著髒資料。我們設計實現了一個巡檢系統，透過查詢 apiserver 獲取排程到當前節點上的 pods，透過對比，找到節點上殘留的程式/容器/volumes 目錄/cgroup /網路裝置等，透過其他途徑嘗試釋放殘留資源。

# Unhealthy node

接下來描述故障機的處理流程。

![8.png](https://ucc.alicdn.com/pic/developer-ecology/eac460bcebd74056842635c690a56cb5.png)

故障機判斷的資料來源有很多，主要有節點的監控指標，比如：

- 某類 Volume 掛載失敗

- NPD(Node Problem Detector)，這是社群的一個框架

- Trace 系統，比如某個節點上 Pod 建立持續報映象下載失敗

- SLO，比如單機上殘留大量 Pod

我們開發了多個 Controller 對這些某類故障進行巡檢，形成故障機列表。一個故障機可以有好幾項故障。對於故障機，會按照故障進行不同的操作。主要的操作有：打 Taint，防止 Pod 排程上去；降低 Node 的優先順序；直接自動處理進行恢復。對於一些特殊原因，比如磁碟滿，那就需要人工介入排查。

故障機系統每天都會產生一個日報，來表明故障機系統今天做了哪些事情。開發人員可以透過不斷地新增 Controller 和處理規則完善整個故障機處理系統。

# Tips on increasing SLO

接下來，我們來分享下達到高 SLO 的一些方法。

![9.png](https://ucc.alicdn.com/pic/developer-ecology/b933d3081e784463ab8a64f95aee67de.png)

- **第一點**，在提升成功率的程式中，我們面臨的最大問題就是映象下載的問題。要知道，Pod 必須在規定時間內交付，而映象下載通常需要非常多的時間。為此，我們透過計算映象下載時間，還專門設定了一個 ImagePullCostTime 的錯誤，即映象下載時間太長，導致 Pod 無法按時交付。

還好，阿里映象分發平臺 Dragonfly 支援了 Image lazyload 技術，也就是支援遠端映象，在 Kubelet 建立容器時，不用再下載映象。所以，這大大加速了 Pod 的交付速度。有關 Image lazyload 技術，大家可以看下阿里 Dragonfly 的分享。

- **第二點**，對於提升單個 Pod 成功率，隨著成功率的提升，難度也越來越難。可以引入一些 workload 進行重試。在螞蟻，paas 平臺會不斷重試，直到 Pod 成功交付或者超時。當然，在重試時，之前的失敗的節點需要排除。

- **第三點**，關鍵的 Daemonset 一定要進行檢查，如果關鍵 Daemonset 缺失，而把 Pod 排程上去，就非常容易出問題，從而影響建立/刪除鏈路。這需要接入故障機體系。

- **第四點**，很多 Plugin，如 CSI Plugin，是需要向 Kubelet 註冊的。可能存在節點上一切正常，但向 Kubelet 註冊的時候失敗，這個節點同樣無法提供 Pod 交付的服務，需要接入故障機體系。

- **最後一點**，由於叢集中的使用者數量是非常多的，所以隔離非常重要。在許可權隔離的基礎上，還需要做到 QPS 隔離，及容量的隔離，防止一個使用者的 Pod 把叢集能力耗盡，從而保障其他使用者的利益。

## 阿里雲首場 Serverless 開發者線下沙龍亮相北京

本次線下活動將邀請來自阿里雲、淘寶、閒魚、百富旅行等國內一線 Serverless 技術專家，為開發者帶來:

- 淘寶/天貓應對 雙11 流量洪峰如何規模化實踐 Serverless。
- 切中開發者痛點，講述閒魚、百富旅行等中國企業的 Serverless 落地及“踩坑”經驗。
- 首次披露阿里雲最新開源工具鏈 Serverless Devs 設計詳情及未來走向。

點選連結立即報名：[https://www.huodongxing.com/event/9570184556300](https://www.huodongxing.com/event/9570184556300)

> “[阿里巴巴雲原生](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247495762&idx=1&sn=b4e994057ca16a8cf3b207c4192ef299&chksm=fae6fb9dcd91728bd9a3f42e7348ac031338b5b35559bf99c0aaf2ce3d3e2d847c48314fdcd9&token=650114445&lang=zh_CN#rd)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”

在大規模 Kubernetes 叢集上實現高 SLO 的方法

相關文章