大家好，我是阿里云云原生應用平臺的炎尋，很高興能和大家一起在 Kubernetes 監控系列公開課上進行交流。本次公開課期望能夠給大家在 Kubernetes 容器化環境中快速發現和定位問題帶來新的解決思路。
為什麼需要 Kubernetes 監控？
很多同學對應用效能監控應該並不陌生，這類監控主要關注業務應用邏輯、應用框架和語言執行時，監控物件有執行緒池滿，資料庫連線無法獲取，MySQL， 記憶體溢位，還有各種呼叫鏈異常棧等。隨著 Kubernetes 容器化技術帶來的雲原生技術演進，上層應用的開發和運維變得更加簡單，但複雜度是恆定的，上層的複雜度降低必然伴隨著底層的複雜度提升。如下圖所示，複雜度逐漸轉移到容器虛擬化層以及系統呼叫核心層對各種虛擬化技術的支援。每一層都可能出現問題，且這些問題會影響上層應用。比如容器虛擬化層的 Kubernetes 元件異常，如果排程器異常，Pod 將無法排程影響應用；比如檔案系統相關的系統呼叫異常，上層應用無法讀取檔案，造成應用問題；比如核心異常，應用程序無法排程完成工作。
應用想要健康穩定的執行，需要的是軟體棧端到端的健康穩定，雖然現在很多運維團隊都搭建了應用監控和系統監控體系，但沒有一個監控能夠自頂向下、端到端的串聯起來各層軟體的行為，導致棘手的問題發生時，無從下手處理。在應用層，一個網路請求超時，在客戶端和服務端看起來似乎都沒有問題，但實際上是網路層包傳送 RTT 過高，重傳率過高，亦或是 DNS 解析慢，或者是 CNI 外掛慢。如何在 Kubernetes 容器化環境下做到端到端的可觀測性是Kubernetes 監控出現的意義。
Kubernetes 監控立足於應用監控之下的 Kubernetes 容器介面和底層作業系統。在容器虛擬化層，我們通過以下五個資料來源獲取觀測資料，通過 Kubernetes 管控元件 exporter 來獲取 Kubernetes 管控元件的觀測資料；通過 cAdvisor 獲取容器的資源觀測資料；通過 kube-state-metrics 獲取 Kubernetes 資源的狀態資料，還有事件和 Kubernetes 資源的狀態以及條件資料。在系統呼叫層，我們通過 Kprobe/tracepoints 等 Linux tracing 技術獲取觀測資料；在核心層，我們通過核心可觀測模組獲取觀測資料，然後 Kubernetes 監控通過程序、容器、Kubernetes 資源和業務應用的關聯關係向上關聯打通應用效能監控，打造端到端的可觀測性。所以 Kubernetes 監控是 Kubernetes 叢集軟體棧端到端可觀測性的一體化解決方案，在 Kubernetes 監控中可以同時看到關聯的所有層的觀測資料。我們希望通過 Kubernetes 監控的一系列最佳實踐，讓大家能夠使用 Kubernetes 監控解決 Kubernetes 環境下棘手的可觀測問題。
我們也將從兩個型別去講解，第一類是發現問題，主要包含五類問題的發現：應用架構問題、效能問題、資源問題、排程問題和網路問題。第二類是定位問題，主要包含對以上五類發現的問題進行根因定位，並且提供修復建議。
探索應用架構，發現預期外的流量
Kubernetes 監控系列公開課第一節課的主題是“如何使用 Kubernetes 監控進行應用架構探索，發現預期外的流量”，包含以下三點內容：
- 背景介紹：應用架構探索的挑戰；
- 典型場景：在哪些場景下，我們需要進行應用架構的探索；
- 最佳實踐：介紹一種應用架構探索的模式，高效的發現定位問題。
一、應用架構探索的挑戰
（1）混沌的微服務架構
在 Kubernetes 容器化環境裡，微服務架構是最普遍的架構模式。在這種架構下，隨著業務發展，一定會有越來越多的微服務，他們之間的關係也會越來越複雜。在複雜度不斷增長的情況下，一些常見架構問題就變得困難，比如應用當前執行架構是怎樣的，應用下游依賴服務是否正常，應用上游客戶端流量是否正常，應用 DNS 解析是否正常，兩個應用之間的連通性是否有問題等。因此，我們要進行應用架構探索，往往變得十分困難。
（2）多語言
在微服務架構裡面，各個微服務通常可以使用不同程式語言，只要暴露出標準的服務即可。那麼不同語言如何進行監控，是否有相同的埋點模式，是否對應語言有好用高效的埋點工具呢？程式碼侵入對效能有什麼影響，是否埋點程式碼會影響業務執行呢？這是多語言場景下面臨的觀測難題。
（3）多通訊協議
在微服務架構裡面，各個微服務之間的通訊可以使用不同通訊協議，比如 HTTP、gRPC、Kafka、Dubbo 等，往往我們需要識別這些協議才能快速發現對應依賴服務的問題，但是識別協議意味著理解各個協議，在合適的地方需要進行埋點，不同通訊協議如何統一埋點程式碼侵入，是否會影響業務效能，這是通訊協議場景下面臨的觀測難題。
二、典型場景
（1）架構感知
架構感知是根據真實的網路呼叫，將微服務作為節點，微服務之間的呼叫作為邊，繪製出一張拓撲圖。通過對比靜態設計的期望架構，我們可以發現問題，比如是不是多了或少了某個微服務，微服務之間的關係是不是正確，通常在新應用上線、新地區開服、整體鏈路梳理等需要關注結構大圖的場景使用。
（2）架構異常發現
架構異常發現是指通過自定義架構拓撲圖中節點和邊的異常規則顯示對應的異常顏色，能夠快速發現異常的節點和邊，通常在整體鏈路梳理和健康巡檢等關注節點和邊狀態的場景下使用。
（3）關聯分析
通過異常發現定位到某個節點或者邊異常之後，我們通常需要關聯關係的切換，快速檢視相關節點或者邊的上下游以及對應的自身服務例項，一步一步縮小問題範圍。
三、最佳實踐
以上三個典型場景構成了完整的實踐流程：通過架構感知觀測應用實際執行架構是否和預期一致，如果有結構性問題，需要進一步排查結構異常的服務，如果沒有結構性問題，我們可以進行下一步。通過異常發現觀測是否有顏色異常的節點和邊，如果沒有其異常節點和邊就最好，否則我們進行下一步，定位到特定的節點和邊之後，開始進行關聯分析，先分析自身例項是不是有問題，再看上下游是不是有問題。
Kubernetes 監控是如何支援最佳實踐的呢？首先是Kubernetes監控叢集拓撲的架構感知能力。Kubernetes 監控通過關聯真實的網路請求繪製出了應用架構拓撲。當前提供 Service 和 Workload 兩種檢視，前者是 Service 之間的服務呼叫，後者是 Deployment 、Daemonset、Statefulset 之間的服務呼叫。
進入拓撲圖，預設對節點進行分組收斂，叢集內按名稱空間分組，叢集外按服務型別進行分組。展開分組之後可以看到對應的節點和節點關係，點選節點可以看到選定時間範圍內的效能指標聚合值和時序值，這些值會按網路協議進行劃分，點選邊可以看到選定時間範圍內的效能指標聚合值和時序值，這些值會按網路協議進行劃分，再配合節點過濾，比如檢視兩個特定名稱空間的架構關係，以及節點查詢，快速檢視一個節點，可以很好的對架構進行探索。
再看 Kubernetes 監控的異常發現能力，Kubernetes 監控通過三個維度的異常條件，將節點和邊繪製成異常的黃或者紅的顏色。具體來說，這三個維度是效能指標異常，比如說錯誤率大於 10%，平均響應時間大於 500 毫秒；第二，資源指標異常，比如 CPU 使用率大於 70%，記憶體使用率大於 70%；第三，K8S 管控狀態異常，比如 POD 一直無法到達 ready 狀態，在分組收起的狀態下會顯示節點分組的異常佔比，展開分組可以看到特定的節點變得異常。通過該能力，我們可以快速發現特定的微服務或者微服務關係的異常。
Kubernetes 監控還具備關聯分析能力，支援檢視特定節點的上下游，提供 3D 檢視同時檢視節點關聯的上下游關係和自身的實力狀態，可以在一張圖進行所有關聯資料的探索，極大提升問題定位的效率。
四、Kubernetes 監控的產品價值
阿里雲 Kubernetes 監控是一套針對 Kubernetes 叢集開發的一站式可觀測性產品，它會關聯起 Kubernetes 名下的所有指標、鏈路、日誌和事件。主要具備六大特性：
- 程式碼無侵入：阿里雲 Kubernetes 監控通過旁路技術，不需要對程式碼進行埋點即可獲取到豐富的網路效能資料。
- 語言無關：阿里雲 Kubernetes 監控在核心層進行網路協議解析，支援任意語言、任意框架。
- 高效能：阿里雲 Kubernetes 監控基於 eBPF 技術，能以極低的消耗獲取豐富的網路效能資料。
- 資源關聯：阿里雲 Kubernetes 監控通過網路拓撲、資源拓撲展示相關資源的關聯。
- 資料多樣：阿里雲 Kubernetes 監控支援可觀測的各種型別資料（監控指標、鏈路、日誌和事件），涵蓋端到端的軟體棧。
- 整體性：阿里雲 Kubernetes 監控通過控制檯的場景設計、關聯起架構感知拓撲、應用監控、Prometheus 監控、雲撥測、健康巡檢、事件中心、日誌服務和雲服務。
那麼 Kubernetes 監控、應用效能監控、Prometheus 監控有什麼異同點呢？下圖清晰的表達了這三者的關係和區別，應用效能監控主要關注應用邏輯，框架與程式語言，而 Kubernetes 監控關注的是系統網路和容器介面，同時會向上關聯應用效能監控。Prometheus 監控是基礎設施，Kubernetes 監控和應用效能監控的指標類資料將會儲存在 Prometheus 監控中。
所以，想要快速解決 Kubernetes 監測問題，那就立刻開始試用吧！目前 Kubernetes 監測全面免費公測中，點選連結（https://www.aliyun.com/activity/middleware/container-monitoring?spm=5176.20960838.0.0.42b6305eAqJy2n）即可開通試用！也歡迎大家加入答疑交流群進行交流，我們下節課再見。
