如何發現 Kubernetes 中服務和工作負載的異常Kubernetes 異常定位存在痛點Kubernetes 監控如何發現異常最佳實踐&場景分析

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

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

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

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

三、網絡性能監控、中間件監控等典型案例解析。

Kubernetes 異常定位存在痛點

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

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

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

Kubernetes 監控如何發現異常

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

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

再上一層是事件，事件直接明确地告訴我們發生了什麼，可能我們遇到最多的是 Pod 重新開機、拉鏡像失敗等。我們對 Kubernetes 事件進行了持久化存儲，并儲存一段時間，這樣友善定位問題。然後，我們的巡檢和健康檢查也是支援以事件的形式報出來。

最頂層是告警，告警是監控系統的最後一環，當我們發現某些特定異常可能對業務有損後，我們就需要對名額、事件進行告警配置。告警目前支援 PromQL，智能告警支援對曆史資料進行智能算法檢測，進而發現潛在的異常事件。告警的配置支援動态門檻值，通過調節靈敏度的方式來配置告警，進而避免寫死門檻值。 有了 Trace、名額、事件、告警之後，我們用拓撲圖将這些資料和 Kubernetes 實體都關聯起來，每個節點對應 Kubernetes 實體中的服務和工作負載，服務之間調用用線表示。有了拓撲圖，我們就像拿到一張地圖，能快速識别拓撲圖中的異常，并對異常進行進一步的分析，對上下遊、依賴、影響面進行分析，進而對系統有了更全面的掌控。 

最佳實踐&場景分析

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

首先還是先有名額，名額能反應服務的監控狀态，我們應盡可能地收集各種名額，并且越全越好，不限于黃金名額、USE 名額、Kubernetes 原生名額等；然後，名額是宏觀資料，需要做根因分析我們得有 Trace 資料，多語言、多協定的情況下要考慮采集這些 Trace 的成本，同樣盡可能地支援多一點協定、多一點語言；最後，用一張拓撲将名額、Trace、事件彙總起來、串聯起來，形成一張拓撲圖，用來做架構感覺分析、上下遊分析。

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

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

（一）網絡性能監控

網絡性能監控以重傳為例，重傳的意思是說發送方認為發生了丢包現象，就重發這些資料包。以圖中的傳輸過程為例：

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

代碼和日志是觀察不出來的，這種情形下最終很難找到根因。為了能快速定位這個問題，我們需要一組網絡性能名額來提供定位依據，包含以下名額，P50、P95、P99 名額來表示延時，然後我們需要流量、重傳、RTT、丢包這些名額來表征網絡情況。

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

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

（二）DNS 解析異常

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

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

1. 調用外部 API 網關
2. 調用雲服務，雲服務一般是公網的
3. 調用外部中間件

這裡對 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、傳回碼、網路流量、重傳等名額來定位。

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

（三）全鍊路壓測

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

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

第一、各種語言、協定通信的黃金名額，通過檢視清單進一步看調用的詳情

第二、點選節點詳情下鑽檢視 cpu、memory 等 use 資源名額

第三、整個拓撲圖是能反映整個架構的形态的，有了全局的架構視角，就能識别哪個服務容易成為瓶頸、爆炸半徑有多大，是否需要做高可用保障。 

（四）通路外部 MySQL

第四個場景是通路外部 MySQL，先看下通路外部 MySQL 有哪些常見的問題：

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

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

（五）多租戶架構

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

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

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

我們将上述場景介紹總結如下：

1. 網絡監控：如何能分析網絡導緻的服務的錯慢、中斷，如何分析網絡問題帶來的影響
2. 服務監控：如何通過黃金名額确定服務是否健康？如何通過支援多協定的 Trace 檢視詳情？
3. 中間件、基礎設施監控：如何用黃金名額、trace 分析中間件、基礎設施的異常，如何快速定界是網絡問題，還是自身問題，還是下遊服務問題
4. 架構感覺：如何通過拓撲感覺整個架構，梳理上下遊、内部外部依賴，進而能掌控全局？如何通過拓撲保障架構有足夠的觀測性、穩定性保障，如何通過拓撲分析、發現系統中的瓶頸、爆炸半徑。

從這幾個場景中又進一步列舉常見的 case：網絡、服務的可用性檢測，健康檢查；中間件架構更新可觀測性保障；新業務上線驗證；服務性能優化；中間件性能監控；方案選型；全鍊路壓測等。 

産品價值

經過以上内容介紹，我們将 Kubernetes 的産品價值總結如下：

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

本節課的内容到這裡就結束了，歡迎大家前往釘釘掃碼或搜尋釘釘群号（31588365）加入答疑交流群進行交流。

目前 Kubernetes 監控已經全面免費公測，點選下方連結，立即開啟試用！

https://www.aliyun.com/activity/middleware/container-monitoring?spm=5176.20960838.0.0.42b6305eAqJy2n