大家好，我是阿里云云原生應用平臺的炎尋，很高興能和大家一起在 Kubernetes 監(jiān)控系列公開課上進行交流。本次公開課期望能夠給大家在 Kubernetes 容器化環(huán)境中快速發(fā)現和定位問題帶來新的解決思路。
?

為什么需要 Kubernetes 監(jiān)控？

很多同學對應用性能監(jiān)控應該并不陌生，這類監(jiān)控主要關注業(yè)務應用邏輯、應用框架和語言運行時，監(jiān)控對象有線程池滿，數據庫連接無法獲取，MySQL， 內存溢出，還有各種調用鏈異常棧等。隨著 Kubernetes 容器化技術帶來的云原生技術演進，上層應用的開發(fā)和運維變得更加簡單，但復雜度是恒定的，上層的復雜度降低必然伴隨著底層的復雜度提升。如下圖所示，復雜度逐漸轉移到容器虛擬化層以及系統(tǒng)調用內核層對各種虛擬化技術的支持。每一層都可能出現問題，且這些問題會影響上層應用。比如容器虛擬化層的 Kubernetes 組件異常，如果調度器異常，Pod 將無法調度影響應用；比如文件系統(tǒng)相關的系統(tǒng)調用異常，上層應用無法讀取文件，造成應用問題；比如內核異常，應用進程無法調度完成工作。
?

?
應用想要健康穩(wěn)定的運行，需要的是軟件棧端到端的健康穩(wěn)定，雖然現在很多運維團隊都搭建了應用監(jiān)控和系統(tǒng)監(jiān)控體系，但沒有一個監(jiān)控能夠自頂向下、端到端的串聯(lián)起來各層軟件的行為，導致棘手的問題發(fā)生時，無從下手處理。在應用層，一個網絡請求超時，在客戶端和服務端看起來似乎都沒有問題，但實際上是網絡層包發(fā)送 RTT 過高，重傳率過高，亦或是 DNS 解析慢，或者是 CNI 插件慢。如何在 Kubernetes 容器化環(huán)境下做到端到端的可觀測性是Kubernetes 監(jiān)控出現的意義。
?
Kubernetes 監(jiān)控立足于應用監(jiān)控之下的 Kubernetes 容器界面和底層操作系統(tǒng)。在容器虛擬化層，我們通過以下五個數據源獲取觀測數據，通過 Kubernetes 管控組件 exporter 來獲取 Kubernetes 管控組件的觀測數據；通過 cAdvisor 獲取容器的資源觀測數據；通過 kube-state-metrics 獲取 Kubernetes 資源的狀態(tài)數據，還有事件和 Kubernetes 資源的狀態(tài)以及條件數據。在系統(tǒng)調用層，我們通過 Kprobe/tracepoints 等 Linux tracing 技術獲取觀測數據；在內核層，我們通過內核可觀測模塊獲取觀測數據，然后 Kubernetes 監(jiān)控通過進程、容器、Kubernetes 資源和業(yè)務應用的關聯(lián)關系向上關聯(lián)打通應用性能監(jiān)控，打造端到端的可觀測性。所以 Kubernetes 監(jiān)控是 Kubernetes 集群軟件棧端到端可觀測性的一體化解決方案，在 Kubernetes 監(jiān)控中可以同時看到關聯(lián)的所有層的觀測數據。我們希望通過 Kubernetes 監(jiān)控的一系列最佳實踐，讓大家能夠使用 Kubernetes 監(jiān)控解決 Kubernetes 環(huán)境下棘手的可觀測問題。
?
我們也將從兩個類型去講解，第一類是發(fā)現問題，主要包含五類問題的發(fā)現：應用架構問題、性能問題、資源問題、調度問題和網絡問題。第二類是定位問題，主要包含對以上五類發(fā)現的問題進行根因定位，并且提供修復建議。

探索應用架構，發(fā)現預期外的流量

Kubernetes 監(jiān)控系列公開課第一節(jié)課的主題是“如何使用 Kubernetes 監(jiān)控進行應用架構探索，發(fā)現預期外的流量”，包含以下三點內容：

• 背景介紹：應用架構探索的挑戰(zhàn)；
• 典型場景：在哪些場景下，我們需要進行應用架構的探索；
• 最佳實踐：介紹一種應用架構探索的模式，高效的發(fā)現定位問題。
  ?

一、應用架構探索的挑戰(zhàn)

（1）混沌的微服務架構
在 Kubernetes 容器化環(huán)境里，微服務架構是最普遍的架構模式。在這種架構下，隨著業(yè)務發(fā)展，一定會有越來越多的微服務，他們之間的關系也會越來越復雜。在復雜度不斷增長的情況下，一些常見架構問題就變得困難，比如應用當前運行架構是怎樣的，應用下游依賴服務是否正常，應用上游客戶端流量是否正常，應用 DNS 解析是否正常，兩個應用之間的連通性是否有問題等。因此，我們要進行應用架構探索，往往變得十分困難。
?
（2）多語言
在微服務架構里面，各個微服務通常可以使用不同編程語言，只要暴露出標準的服務即可。那么不同語言如何進行監(jiān)控，是否有相同的埋點模式，是否對應語言有好用高效的埋點工具呢？代碼侵入對性能有什么影響，是否埋點代碼會影響業(yè)務運行呢？這是多語言場景下面臨的觀測難題。
?
（3）多通信協(xié)議
在微服務架構里面，各個微服務之間的通信可以使用不同通信協(xié)議，比如 HTTP、gRPC、Kafka、Dubbo 等，往往我們需要識別這些協(xié)議才能快速發(fā)現對應依賴服務的問題，但是識別協(xié)議意味著理解各個協(xié)議，在合適的地方需要進行埋點，不同通信協(xié)議如何統(tǒng)一埋點代碼侵入，是否會影響業(yè)務性能，這是通信協(xié)議場景下面臨的觀測難題。
?

二、典型場景

（1）架構感知
架構感知是根據真實的網絡調用，將微服務作為節(jié)點，微服務之間的調用作為邊，繪制出一張拓撲圖。通過對比靜態(tài)設計的期望架構，我們可以發(fā)現問題，比如是不是多了或少了某個微服務，微服務之間的關系是不是正確，通常在新應用上線、新地區(qū)開服、整體鏈路梳理等需要關注結構大圖的場景使用。
?
（2）架構異常發(fā)現
架構異常發(fā)現是指通過自定義架構拓撲圖中節(jié)點和邊的異常規(guī)則顯示對應的異常顏色，能夠快速發(fā)現異常的節(jié)點和邊，通常在整體鏈路梳理和健康巡檢等關注節(jié)點和邊狀態(tài)的場景下使用。
?
（3）關聯(lián)分析
通過異常發(fā)現定位到某個節(jié)點或者邊異常之后，我們通常需要關聯(lián)關系的切換，快速查看相關節(jié)點或者邊的上下游以及對應的自身服務實例，一步一步縮小問題范圍。
?

三、最佳實踐

以上三個典型場景構成了完整的實踐流程：通過架構感知觀測應用實際運行架構是否和預期一致，如果有結構性問題，需要進一步排查結構異常的服務，如果沒有結構性問題，我們可以進行下一步。通過異常發(fā)現觀測是否有顏色異常的節(jié)點和邊，如果沒有其異常節(jié)點和邊就最好，否則我們進行下一步，定位到特定的節(jié)點和邊之后，開始進行關聯(lián)分析，先分析自身實例是不是有問題，再看上下游是不是有問題。
?
Kubernetes 監(jiān)控是如何支持最佳實踐的呢？首先是Kubernetes監(jiān)控集群拓撲的架構感知能力。Kubernetes 監(jiān)控通過關聯(lián)真實的網絡請求繪制出了應用架構拓撲。當前提供 Service 和 Workload 兩種視圖，前者是 Service 之間的服務調用，后者是 Deployment 、Daemonset、Statefulset 之間的服務調用。
?
進入拓撲圖，默認對節(jié)點進行分組收斂，集群內按命名空間分組，集群外按服務類型進行分組。展開分組之后可以看到對應的節(jié)點和節(jié)點關系，點擊節(jié)點可以看到選定時間范圍內的性能指標聚合值和時序值，這些值會按網絡協(xié)議進行劃分，點擊邊可以看到選定時間范圍內的性能指標聚合值和時序值，這些值會按網絡協(xié)議進行劃分，再配合節(jié)點過濾，比如查看兩個特定命名空間的架構關系，以及節(jié)點查詢，快速查看一個節(jié)點，可以很好的對架構進行探索。

再看 Kubernetes 監(jiān)控的異常發(fā)現能力，Kubernetes 監(jiān)控通過三個維度的異常條件，將節(jié)點和邊繪制成異常的黃或者紅的顏色。具體來說，這三個維度是性能指標異常，比如說錯誤率大于 10%，平均響應時間大于 500 毫秒；第二，資源指標異常，比如 CPU 使用率大于 70%，內存使用率大于 70%；第三，K8S 管控狀態(tài)異常，比如 POD 一直無法到達 ready 狀態(tài)，在分組收起的狀態(tài)下會顯示節(jié)點分組的異常占比，展開分組可以看到特定的節(jié)點變得異常。通過該能力，我們可以快速發(fā)現特定的微服務或者微服務關系的異常。

Kubernetes 監(jiān)控還具備關聯(lián)分析能力，支持查看特定節(jié)點的上下游，提供 3D 視圖同時查看節(jié)點關聯(lián)的上下游關系和自身的實力狀態(tài)，可以在一張圖進行所有關聯(lián)數據的探索，極大提升問題定位的效率。

四、Kubernetes 監(jiān)控的產品價值

阿里云 Kubernetes 監(jiān)控是一套針對 Kubernetes 集群開發(fā)的一站式可觀測性產品，它會關聯(lián)起 Kubernetes 名下的所有指標、鏈路、日志和事件。主要具備六大特性：

• 代碼無侵入：阿里云 Kubernetes 監(jiān)控通過旁路技術，不需要對代碼進行埋點即可獲取到豐富的網絡性能數據。
• 語言無關：阿里云 Kubernetes 監(jiān)控在內核層進行網絡協(xié)議解析，支持任意語言、任意框架。
• 高性能：阿里云 Kubernetes 監(jiān)控基于 eBPF 技術，能以極低的消耗獲取豐富的網絡性能數據。
• 資源關聯(lián)：阿里云 Kubernetes 監(jiān)控通過網絡拓撲、資源拓撲展示相關資源的關聯(lián)。
• 數據多樣：阿里云 Kubernetes 監(jiān)控支持可觀測的各種類型數據（監(jiān)控指標、鏈路、日志和事件），涵蓋端到端的軟件棧。
• 整體性：阿里云 Kubernetes 監(jiān)控通過控制臺的場景設計、關聯(lián)起架構感知拓撲、應用監(jiān)控、Prometheus 監(jiān)控、云撥測、健康巡檢、事件中心、日志服務和云服務。

那么 Kubernetes 監(jiān)控、應用性能監(jiān)控、Prometheus 監(jiān)控有什么異同點呢？下圖清晰的表達了這三者的關系和區(qū)別，應用性能監(jiān)控主要關注應用邏輯，框架與編程語言，而 Kubernetes 監(jiān)控關注的是系統(tǒng)網絡和容器界面，同時會向上關聯(lián)應用性能監(jiān)控。Prometheus 監(jiān)控是基礎設施，Kubernetes 監(jiān)控和應用性能監(jiān)控的指標類數據將會存儲在 Prometheus 監(jiān)控中。

所以，想要快速解決 Kubernetes 監(jiān)測問題，那就立刻開始試用吧！目前 Kubernetes 監(jiān)測全面免費公測中，點擊鏈接（https://www.aliyun.com/activity/middleware/container-monitoring?spm=5176.20960838.0.0.42b6305eAqJy2n）即可開通試用！也歡迎大家加入答疑交流群進行交流，我們下節(jié)課再見。

《新程序員》：云原生和全面數字化實踐50位技術專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的通过Kubernetes监控探索应用架构，发现预期外的流量的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。