如何發現 Kubernetes 中服務和工作負載的異常

阿里雲開發者 發表於 2021-10-11
Kubernetes

大家好,我是來自阿里雲的李煌東,今天由我為大家分享 Kubernetes 監控公開課的第二節內容:如何發現 Kubernetes 中服務和工作負載的異常。

本次分享由三個部分組成:

一、Kubernetes 異常定位存在痛點;

二、針對這些痛點,Kubernetes 監控如何更快、更準、更全的發現異常;

三、網路效能監控、中介軟體監控等典型案例解析。

Kubernetes 異常定位存在痛點

當下的網際網路架構中,越來越多的公司採用微服務 + Kubernetes 這樣的架構,這樣的架構有如下特點:

  1. 首先應用層基於微服務,微服務由解耦開的幾個服務相互呼叫構成,服務一般職責分明、邊界明確,造成的結果是一個簡單的產品也有幾十、甚至上百個微服務,相互之間的依賴、呼叫是非常複雜的,這給定位問題帶來比較大的成本。同時,每個服務的 owner 可能來自不同團隊,不同的開發,可能使用不同的語言,對我們監控的影響是對每一種語言都需要進行監控工具的接入,投資回報率低。還有一個特點是多協議,幾乎每種中介軟體(Redis、MySQL、Kafka)都有他們獨特的協議,怎麼要做到快速對這些協議進行觀測,是不小的挑戰。
  2. 雖然 Kubernetes 和容器對上層應用遮蔽了底層的複雜度,但是帶來的兩個結果是:基礎設施層越來越高;另一個是上層應用和基礎設施之間資訊變得越來越複雜了。舉個例子,使用者反饋網站訪問很慢,管理員檢視訪問日誌、服務狀態、資源水位發現都沒問題,這時候不知道問題出現在哪裡,雖然懷疑基礎設施有問題,但無法定界的情況下只能一個一個排查效率低,問題的根源就是上層應用和基礎設施之間缺少上下問題關聯,無法做到端到端串聯。
  3. 最後一個痛點是資料散、工具多、資訊沒打通。舉個例子,假設我們收到一個告警,用 grafana 去檢視指標,指標只能描述的比較粗略,我們得去看下日誌,這時候我們要去 SLS 日誌服務看下有沒有對應的日誌,日誌也沒問題,這時候我們需要登入到機器上去看,然而登入到容器裡面可能又因為重啟導致日誌沒有了。查了一波之後,可能我們會覺得可能問題不是出現在這個應用,於是我們又去看鏈路追蹤是不是下游有問題。總而言之,工具用了一大堆,瀏覽器開了十幾個視窗,效率低、體驗差。

這三個痛點分別歸納為成本、效率、體驗三個方面。針對這些痛點,接下來我們一起看下 Kubernetes 監控的資料體系,看下怎麼來更好的解決成本、效率、體驗三大問題。

Kubernetes 監控如何發現異常

下圖金子塔自頂向下表示資訊的密度或者詳細程度,越往下面資訊越詳細。我們從底部開始講,Trace 是我們通過eBPF技術以無入侵、多協議、多語言的方式採集應用層協議資料,如 HTTP、MySQL、Redis,協議資料會進一步解析成容易理解的請求詳情、響應詳情、各個階段的耗時資訊。

圖片 1.png

再上一層是指標,指標主要由黃金指標、網路、Kubernetes 體系中的指標。其中黃金指標和網路指標是基於 eBPF 採集的,所以同樣他們是沒有入侵的,支援各種協議的,有了黃金指標,我們就能知道服務整體上是否有異常、是否有慢、是否影響使用者;網路指標主要是對socket的支援,如丟包率、重傳率、RTT 等,主要用來監控網路是否正常的指標。Kubernetes 體系中的指標是指原來 Kubernetes 監控體系中的 cAdvisor/MetricServer/Node Exporter/NPD 這些指標。

再上一層是事件,事件直接明確地告訴我們發生了什麼,可能我們遇到最多的是 Pod 重啟、拉映象失敗等。我們對 Kubernetes 事件進行了持久化儲存,並儲存一段時間,這樣方便定位問題。然後,我們的巡檢和健康檢查也是支援以事件的形式報出來。

最頂層是告警,告警是監控系統的最後一環,當我們發現某些特定異常可能對業務有損後,我們就需要對指標、事件進行告警配置。告警目前支援 PromQL,智慧告警支援對歷史資料進行智慧演算法檢測,從而發現潛在的異常事件。告警的配置支援動態閾值,通過調節靈敏度的方式來配置告警,從而避免寫死閾值。

有了 Trace、指標、事件、告警之後,我們用拓撲圖將這些資料和 Kubernetes 實體都關聯起來,每個節點對應 Kubernetes 實體中的服務和工作負載,服務之間呼叫用線表示。有了拓撲圖,我們就像拿到一張地圖,能快速識別拓撲圖中的異常,並對異常進行進一步的分析,對上下游、依賴、影響面進行分析,從而對系統有了更全面的掌控。

最佳實踐&場景分析

接下來我們講下發現 Kubernetes 中服務和工作負載的異常的最佳實踐。

首先還是先有指標,指標能反應服務的監控狀態,我們應儘可能地收集各種指標,並且越全越好,不限於黃金指標、USE 指標、Kubernetes 原生指標等;然後,指標是巨集觀資料,需要做根因分析我們得有 Trace 資料,多語言、多協議的情況下要考慮採集這些 Trace 的成本,同樣儘可能地支援多一點協議、多一點語言;最後,用一張拓撲將指標、Trace、事件彙總起來、串聯起來,形成一張拓撲圖,用來做架構感知分析、上下游分析。

圖片 2.png

通過這三種方法的分析,服務和工作負載的異常通常暴露無遺了,但我們不應該就此停止前進的腳步,加入這個異常下次再來,那麼我們這些工作得重來一遍,最好的辦法是針對這類異常配置對應的告警,自動化地管理起來。

我們用幾個具體的場景來詳細介紹:

(一)網路效能監控

網路效能監控以重傳為例,重傳的意思是說傳送方認為發生了丟包現象,就重發這些資料包。以圖中的傳輸過程為例:

圖片 3.png

  1. 傳送方傳送編號為 1 的包,接收方接受了,返回 ACK 2
  2. 傳送方傳送編號為 2 的包,接收方返回 ACK 2
  3. 傳送方傳送編號為 3、4、5 的包,接收方都返回 ACK 2
  4. 直到傳送方收到 3 次同樣的 ACK ,就會觸發重傳機制,重傳會導致延遲升高

程式碼和日誌是觀察不出來的,這種情形下最終很難找到根因。為了能快速定位這個問題,我們需要一組網路效能指標來提供定位依據,包含以下指標,P50、P95、P99 指標來表示延時,然後我們需要流量、重傳、RTT、丟包這些指標來表徵網路情況。

以某個服務 RT 高為例:首先我們看到拓撲的邊是紅的,紅的判斷邏輯是根據延時、錯誤來判斷的,當發現這個紅邊的時候,點選上面的邊,就可以看對應的黃金指標了。

圖片 4.png

點選底部最左邊這個按鈕,可以檢視當前服務的網路資料列表,我們可以按平均響應時間、重傳、RTT 排下序,可以看到第一個服務呼叫延時比較高,快到一秒的返回時間,同時也看到重傳比較高,相比於其他服務高很多。這裡其實是通過工具去注入了重傳高這麼一個故障,看起來更明顯一些。這樣分析下來我們就知道可能是網路的問題,就可以進一步排查了。有經驗的開發一般會拿著網路指標、服務名、ip、域名這些資訊去找網路的同事排查,而不是隻是告訴對方說我服務很慢,這樣對方知道的資訊太少,就不會積極去排查,因為別人也不知道從哪裡開始,當我們提供了相關資料,對方就有了參考,會順藤摸瓜進一步推進。

(二)DNS 解析異常

第二個場景是 DNS 解析異常。DNS 通常是協議通訊的第一步,比如 HTTP 請求,第一步就是先拿到 IP,也就是我們平常說的服務發現過程,第一步出現問題,整個呼叫就直接失敗了,這就是所謂關鍵路徑不能掉鏈子。在 Kubernetes 叢集中所有的 DNS 都走 CoreDNS 的解析,所以 CoreDNS 上容易出現瓶頸,一旦出現問題,影響面也是非常大的,可能整個叢集都不可用了。舉個兩個月前發生的鮮活的例子,著名的 CDN 公司 Akamai 就發生了一個 DNS 故障,導致眾多網站像 Airbnb 網站無法訪問,事故持續了長達一個小時。

在 Kubernetes 叢集中 DNS 解析比較核心的幾個場景有三個:

  1. 呼叫外部 API 閘道器
  2. 呼叫雲服務,雲服務一般是公網的
  3. 呼叫外部中介軟體

圖片 5.png

這裡對 CoreDNS 常見的問題進行了歸納,大家可以參考下,排查下自己的叢集上有沒有類似問題:

  1. 配置問題(ndots 問題),ndots 是個數字,表示域名中點的個數要是小於 ndots,那麼搜尋就優先走 search 列表中的域去查詢,這樣的話會產生多次查詢,對效能的影響還是挺大的。
  2. 由於 Kubernetes 所有的域名解析都走 CoreDNS,非常容易成為效能瓶頸,有人統計過大概 qps 在 5000~8000 的時候就要關注效能問題了。尤其是依賴外部 Redis、MySQL 這種訪問量比較大的。
  3. 低版本的 CoreDNS 有穩定性問題,這個也是需要關注的點。
  4. 有些語言,想 PHP 對連線池支援的不是很好,導致每次都要去解析 DNS,建立連線,這個現象也是比較常見的。

接下來,我們看下 Kubernetes CoreDNS 中可能會發生問題的地方,首先應用和 CoreDNS 之間的網路可能有問題;第二是 CoreDNS 本身問題,比如 CoreDNS 返回 SERVFAIL、REFUSE 這些錯誤碼,甚至因為 Corefile 配置錯了,導致返回值是錯的;第三點是跟外部 DNS 通訊的時候,發生網路中斷、效能問題;最後一個是外部 DNS 不可用。

針對這些問題點總結出以下步驟來盤查:

第一、從客戶端側,先看下請求內容和返回碼,如果是返回是錯誤碼說明是服務端有問題。如果是慢解析,可以看下時間瀑布流看下時間耗費在哪個階段。
第二、看網路是否正常,看流量、重傳、丟包、RTT 這幾個指標就夠了。
第三、檢視服務端,看下流量、錯誤、延時、飽和度這幾個指標,再看下 CPU、記憶體、磁碟等這幾個資源指標,也能定位出是否有問題。
第四、看下外部 DNS,同理我們可以通過請求 Trace、返回碼、網路流量、重傳等指標來定位。

圖片 6.png

接下來我們看下拓撲。首先看到紅色的線表示有異常的 DNS 解析呼叫,點選這個我們能看到呼叫的黃金指標;點選檢視列表,彈出詳情頁面,可檢視請求的詳情,是請求這個域名,請求過程中經歷傳送、等待、下載三個過程,看起來指標正常,接下來我們點選看響應,發現響應是域名不存在。那麼這時候我們可以進一步看下外部 DNS 是否有問題,步驟也是一樣的,後面我會在 demo 中展示,所以這裡就不展開先了。

(三)全鏈路壓測

第三個典型場景是全鏈路壓測,對於大促這種場景峰值是平常的數倍,怎麼保障大促的穩定,需要通過一系列的壓測來驗證系統能力、系統穩定性評估、做容量規劃、識別系統瓶頸。一般會有這麼幾個步驟:先預熱下,這時候驗證下鏈路是否正常的,逐步加流量直到峰值,然後開始摸高,也就是看下能支援的最大 TPS 是多少,接著再加流量,這時候主要就是看服務是否能正常限流了,因為已經找過最大 TPS 了,再加大力量就是破壞性流量了。那麼在這個過程中,我們需要關注哪些點呢?

首先針對我們多語言、多協議的微服務架構,比如這裡的 Java、Golang、Python 應用,這裡有 RPC、MySQL、Redis、Kafka 應用層協議,我們得有各種語言、各種協議的黃金指標,用來驗證系統能力;針對系統的瓶頸、容量規劃這塊,我們需要 use 指標,去看各種流量級別情況下資源的飽和度,來確定是不是要擴容,每增加一次流量,對應看下 use 指標,對應調整容量,逐步優化;對於複雜架構,需要有一張全域性的大圖來幫助梳理上下游依賴、全鏈路架構,確定爆炸報警,比如這裡的 CheckoutService 就是個關鍵的服務,這個點如果出現問題,影響面會很大。

圖片 7.png

第一、各種語言、協議通訊的黃金指標,通過檢視列表進一步看呼叫的詳情
第二、點選節點詳情下鑽檢視 cpu、memory 等 use 資源指標
第三、整個拓撲圖是能反映整個架構的形態的,有了全域性的架構視角,就能識別哪個服務容易成為瓶頸、爆炸半徑有多大,是否需要做高可用保障。

(四)訪問外部 MySQL

第四個場景是訪問外部 MySQL,先看下訪問外部 MySQL 有哪些常見的問題:

圖片 8.png

  1. 首先是慢查詢,慢查詢提現為延時指標高,這時候去看 trace 裡面詳情請求是啥,查詢的是哪張表,哪些欄位,進而看下是不是查詢量太大了、表太大了、還是說沒有建索引等。
  2. 查詢語句過大,我們知道查詢語句太大會導致傳輸耗時高,網路稍一抖動就造成失敗重試,還會引發頻寬佔用的問題。一般都是一些批量的更新、插入導致的,出現這種問題延時指標會飆高,這時候我們可以選擇RT較高的一些 Trace 來看,看下語句怎麼寫的、看下查詢語句的長度是不是太大了。
  3. 錯誤碼返回,比如表不存在這種,那麼解析出其中的錯誤碼就很有幫助了,再進一步看裡面的詳情,去看語句,就比較容易定位出根因了。
  4. 網路問題,這個點也講過比較多了,一般配合著延時指標加上 RTT、重傳、丟包來確定網路是否有問題。

圖片 9.png

接下來看下拓撲圖,中間框住的應用依賴了外部的 MySQL 服務,點選拓撲線可以進一步看黃金指標,點選檢視列表可以進一步看請求的詳情、響應等。同時我們也可以看下網路效能指標,這個 table 是將當前拓撲中的網路資料根據來源和目標進行歸類,可以分別檢視請求數、錯誤數、平均響應時間、socket 重傳、socket rtt,點選上面箭頭可以對應地排序。

(五)多租戶架構

第五個典型案例是多租戶架構。多租戶指的是不同的租戶、工作負載、不同團隊,公用一個叢集,通常一個租戶對應一個名稱空間,同時保證資源的邏輯隔離或者物理隔離,互不影響、互不干擾。常見的場景有:企業內部使用者,一個團隊對應一個租戶,同一個名稱空間內網路不受限制,用網路策略去控制不同名稱空間之間的網路流量。第二種是 SaaS 提供商多租戶架構,每個使用者對應一個名稱空間,同時租戶和平臺分別處於不同的名稱空間。雖然 Kubernetes 的名稱空間特性給多租戶架構帶來了便利,但也給可觀測帶來兩個挑戰:第一名稱空間非常多,查詢資訊變得很繁瑣,增加了管理成本、理解成本。第二是租戶之間有流量隔離的要求,在名稱空間比較多的情況下往往無法做到準確、全面的發現異常流量。第三是對多協議、多語言的 Trace 支援。曾經遇到過一個客戶,一個叢集裡面有 400 多個名稱空間,管理起來非常痛苦,而且應用是多協議、多語言的,要支援 Trace,得一個個改造。

圖片 10.png

這是我們產品的叢集首頁,Kubernetes 的實體以名稱空間的方式劃分,支援查詢來定位到我想看的叢集。氣泡圖上展示對應名稱空間上的實體數,以及有異常的實體數,比如框子裡 3 個名稱空間裡存在有異常的 pod,點進去可以進一步看異常。首頁下面是按黃金指標排序的效能概覽,也就是場景的 Top 功能,這樣能快速檢視哪幾個名稱空間是有異常的。

圖片 11.png

在拓撲圖中,如果名稱空間比較多,可以通過過濾功能檢視想看的名稱空間,或者通過搜尋方式快速定位到想看的名稱空間。由於節點是以名稱空間分組的,能通過名稱空間之間的線來檢視名稱空間的流量,這樣就能方便地檢視有來自哪些名稱空間的流量、是否有異常流量等等。

圖片 12.png

我們將上述場景介紹總結如下:

圖片 13.png

  1. 網路監控:如何能分析網路導致的服務的錯慢、中斷,如何分析網路問題帶來的影響
  2. 服務監控:如何通過黃金指標確定服務是否健康?如何通過支援多協議的 Trace 檢視詳情?
  3. 中介軟體、基礎設施監控:如何用黃金指標、trace 分析中介軟體、基礎設施的異常,如何快速定界是網路問題,還是自身問題,還是下游服務問題
  4. 架構感知:如何通過拓撲感知整個架構,梳理上下游、內部外部依賴,進而能掌控全域性?如何通過拓撲保障架構有足夠的觀測性、穩定性保障,如何通過拓撲分析、發現系統中的瓶頸、爆炸半徑。

從這幾個場景中又進一步列舉常見的 case:網路、服務的可用性檢測,健康檢查;中介軟體架構升級可觀測性保障;新業務上線驗證;服務效能優化;中介軟體效能監控;方案選型;全鏈路壓測等。

產品價值

經過以上內容介紹,我們將 Kubernetes 的產品價值總結如下:

圖片 14.png

  1. 通過多協議、多語言、無入侵的方式採集服務的指標和 Trace 資料,最大限度地減少接入的成本,同時提供覆蓋度全面的指標和Trace;
  2. 有了這些指標和 Trace 之後我們就能,對服務和工作負載進行科學的分析、下鑽;
  3. 將這些指標、Trace 關聯起來串成一張拓撲圖,能在一張大圖上進行架構感知、上下游分析、上下文關聯等,充分得理解架構,評估潛在的效能瓶頸等,方便做進一步的架構優化;
  4. 提供配置簡單的告警配置方法,將經驗知識沉澱到告警中,做到主動發現。

本節課的內容到這裡就結束了,歡迎大家前往釘釘搜尋群號(31588365)加入答疑交流群進行交流。

目前 Kubernetes 監控已經全面免費公測,點選下方連結,立即開啟試用!
https://www.aliyun.com/activity/middleware/container-monitoring?spm=5176.20960838.0.0.42b6305eAqJy2n