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

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

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

Why SLO?

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?

隨着生產環境不斷髮展、K8s 集羣愈來愈複雜、集羣規模不斷增大。如何保障大規模環境 K8s 集羣的可用性？是擺在衆多廠家面前的一個難題。對於 K8s 集羣，咱們一般關心如下幾個問題：

• 第一個問題就是集羣是否健康，全部組件是否正常工做，集羣中 Pod 建立的失敗數量有多少，這是一個總體指標的問題。

• 第二個問題就是集羣中發生了什麼，集羣中是否有異常發生了，用戶在集羣中作了些什麼事情，這是一個追蹤能力的問題。

• 第三個問題就是有了異常後，是哪一個組件出了問題致使成功率下降，這是一個緣由定位的問題。

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

• 首先，咱們要定義一套 SLO，來描述集羣的可用性。

• 接着，咱們必須有能力對集羣中 Pod 的生命週期進行追蹤；對於失敗的 Pod，還須要分析出失敗緣由，以快速定位異常組件。

• 最後，咱們要經過優化手段，消除集羣的異常。

SLls on Large K8s Cluster

咱們先來看下集羣的一些指標。

• 第一項指標：集羣健康度。目前有 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

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

先來看 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

圍繞 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 系統的工做流程。

用戶輸入 pod uid 以後，tracing system 經過 pod 索引，查找到 pod 對應生命週期分析記錄、交付成功與否斷定結果。固然，storage 存儲的數據不只爲終端用戶提供基礎數據，更重要的是經過對集羣內 pods 生命週期，分析出週期內集羣的運營情況及每一個節點的運營情況。好比說集羣內太多 pods 調度到熱點節點，不一樣 pods 的交付引發節點上資源競爭，致使節點負載過高，而交付能力卻在降低，最終表現爲節點上 pods 交付超時。

再舉個例子，經過歷史統計數據，分析出 pods 生命週期中各階段的執行時間基線，以基線爲評估標準，比較組件不一樣版本的平均用時、用時分佈，給出組件改進建議。另外，經過總體的 pods 生命週期中各組件負責的步驟時間佔比，找出佔比較多的步驟，爲後續優化 pod 交付時間提供數據支持。

Node Metrics

一個運行情況良好的集羣，不只須要 master 組件保持高可用，節點穩定性也不容忽視。

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

換句話說，不只要儘早發現節點異常，也要儘快修復節點。經過分析各組件在 pod 交付鏈路上的功能，咱們補充了各類不一樣類型的組件的 metrics，以及將 host 運行狀態轉換爲 metrics，一併採集到數據庫以後，結合每一個節點上 pod 交付結果，能夠構建模型預測節點可用性，分析節點是否存在不可恢復異常，適當調整節點在調度器中比重，從而提高 pod 交付成功率。

Pod 建立/升級失敗，用戶能夠經過重試來解決，但 pod 刪除失敗，雖然有着 K8s 面向終態的理念，組件會不斷重試，但終究也會存在髒數據，如 pod 在 etcd 上刪除，可是節點上還殘留着髒數據。咱們設計實現了一個巡檢系統，經過查詢 apiserver 獲取調度到當前節點上的 pods，經過對比，找到節點上殘留的進程/容器/volumes 目錄/cgroup /網絡設備等，經過其餘途徑嘗試釋放殘留資源。

Unhealthy node

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

故障機判斷的數據來源有不少，主要有節點的監控指標，好比：

• 某類 Volume 掛載失敗

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

• Trace 系統，好比某個節點上 Pod 建立持續報鏡像下載失敗

• SLO，好比單機上殘留大量 Pod

咱們開發了多個 Controller 對這些某類故障進行巡檢，造成故障機列表。一個故障機能夠有好幾項故障。對於故障機，會按照故障進行不一樣的操做。主要的操做有：打 Taint，防止 Pod 調度上去；下降 Node 的優先級；直接自動處理進行恢復。對於一些特殊緣由，好比磁盤滿，那就須要人工介入排查。

故障機系統天天都會產生一個日報，來代表故障機系統今天作了哪些事情。開發人員能夠經過不斷地添加 Controller 和處理規則完善整個故障機處理系統。

Tips on increasing SLO

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

• 第一點，在提高成功率的進程中，咱們面臨的最大問題就是鏡像下載的問題。要知道，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

「阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的公衆號。」