大家好，我是來自阿里雲的李煌東，今天由我為大家分享 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](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7c90096301eb4eae99d37e83f8a9e7ca~tplv-k3u1fbpfcp-zoom-1.image)

再上一層是指標，指標主要由黃金指標、網路、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](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0825a645ec5240919ba69193c347962b~tplv-k3u1fbpfcp-zoom-1.image)

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

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

### （一）網路效能監控

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

![圖片 3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c104465662c4494d9318d39b33ca2fb7~tplv-k3u1fbpfcp-zoom-1.image)

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

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

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

![圖片 4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f163b54ec10241eb8f81cf807dfbad68~tplv-k3u1fbpfcp-zoom-1.image)

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

### （二）DNS 解析異常

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

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

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

![圖片 5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/dd602c05d3294227a7990fe6ab306b06~tplv-k3u1fbpfcp-zoom-1.image)

這裡對 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](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/26ee1c5701e14f969850e7c6dd305dfa~tplv-k3u1fbpfcp-zoom-1.image)

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

### （三）全鏈路壓測

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

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

![圖片 7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5174e146ec7e4bab8debc870915d933b~tplv-k3u1fbpfcp-zoom-1.image)

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

### （四）訪問外部 MySQL

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

![圖片 8.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/28146d27cb12418d8aedd413cdfa5929~tplv-k3u1fbpfcp-zoom-1.image)

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

![圖片 9.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9f9bed2416ee402abb7c930e2d2ed532~tplv-k3u1fbpfcp-zoom-1.image)

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

### （五）多租戶架構

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

![圖片 10.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9511eba0e2e343c8ac2ab7fa25e0d72e~tplv-k3u1fbpfcp-zoom-1.image)

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

![圖片 11.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9320f13e844c49759a157d0f8650b354~tplv-k3u1fbpfcp-zoom-1.image)

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

![圖片 12.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d4fa055160c443088511f0475802784c~tplv-k3u1fbpfcp-zoom-1.image)

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

![圖片 13.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/488723da071f4ef5ab27dd527cc77e26~tplv-k3u1fbpfcp-zoom-1.image)

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

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

# 產品價值

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

![圖片 14.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c1682eabce6846ff8352917b96f19739~tplv-k3u1fbpfcp-zoom-1.image)

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

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

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

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

相關文章