隨著分散式服務架構的流行，特別是微服務等設計理念在現代應用普及開來，應用中的服務變得越來越分散，因此服務之間的通訊變得越來越依賴網路，很有必要來談談實現微服務可觀測性中越來越重要的一環——雲原生網路的可觀測。K8s 是微服務設計理念能落地的最重要的承載體，本文主要聚焦談談 K8s 的網路可觀測性，以及其給基礎設施/應用等團隊能帶來的價值。
談 K8s 網路可觀測性之前，先簡單瞭解下 K8s 的網路通訊是如何實現的，CNCF 定義了容器網路介面即 CNI，CNI 提供了一種應用容器的外掛化網路解決方案，定義對網路容器進行操作和配置的規範，透過外掛的形式對 CNI 介面進行實現。實現了 CNI 介面則成為 CNI 外掛，常見的 CNI 外掛包括 Calico、Cilium、Flannel、Kube-OVN、Terway、Weave Net 等，每種 CNI 外掛都有自己的偏重性，使用者可用根據環境限制、功能需求和效能需求等各種方面選擇自己所需的 CNI 外掛。
但是目前針對這種類繁多的 CNI 外掛並沒有統一的網路可觀測手段，對 K8s 網路問題的排障定位的前提是需要學習這眾多 CNI 外掛的原理，對於 K8s 運維或者微服務開發同學們來說學習成本高，而這麼高的學習成本學成之後也只能用來回答「網路是不是癱瘓了」這類二極體問題，孤立的看網路只能看到一個個虛擬網口、虛擬網橋、網路策略，但看不到其中流動的每一個訪問路徑，每一次應用呼叫，因此也就無法回答關於訪問路徑、應用呼叫等這類細粒度的問題。
目前已經開始有一些 CNI 外掛廠商在支援 K8s 網路可觀測性了，例如 Cilium 單獨起了一個子專案 Hubble 來做分散式網路和安全的可觀測性，目前已知的如 Calico，Kube-OVN 等也開始推進網路可觀測效能力了；也有純第三方廠商在做 K8s 網路可觀測性，DeepFlow 就實現了一種與 CNI 外掛無關的網路可觀測效能力。下面將重點介紹下 Hubble 和 DeepFlow 兩個元件，看看目前 K8s 網路可觀測性的能力。
01｜Hubble
Hubble 是一個用於雲原生工作負載分散式的 K8s 網路和安全觀測平臺，它構建在 Cilium 和 eBPF 之上，能觀測服務的通訊行為，也觀測網路基礎設施的通訊行為。
Hubble 的元件架構圖，包含 CLI/Server/Metrics/Relay/UI，其中 Server 負責採集網路可觀測性資料；Relay 對外提供統一的 API 入口，提供叢集可觀測能力；CLI 是一個命令列工具；Metrics 負責將指標資料輸出給 Prometheus，因此可以在 Grafana 構建 Hubble 指標資料的 Dashboard；UI 這是目前還在 Beta 中，主要展示服務依賴/通訊拓撲
架構圖
在部署 Cilium 時，需要手動開啟 Hubble，根據自身所需資料，按需設定 Hubble 配置
helm install cilium cilium/cilium \--version 1.13.0 \--namespace kube-system \ --set prometheus.enabled=true \ --set operator.prometheus.enabled=true \ --set hubble.enabled=true \--set hubble.ui.enabled=true \--set hubble.relay.enabled=true \ --set hubble.metrics.enableOpenMetrics=true -f cilium.yaml以下是 Hubble 提供的主要能力，結合 UI 頁面與 Grafana 提供的 Dashboard 來展示
服務依賴/通訊拓撲，以服務的維度檢視通訊拓撲
服務依賴/通訊拓撲
網路監控/告警，包含網路協議/埠/丟包等指標、流日誌詳情
網路監控/告警
應用監控，包含 HTTP / DNS 的 RED 指標及呼叫日誌詳情
應用監控
安全可觀測性，結合網路安全策略與流量，觀測流量透過情況
安全可觀測性
02｜DeepFlow
DeepFlow 是一個高度自動化的可觀測性平臺，基於 AF_PACKET、BPF、eBPF、WASM 等技術，無需依賴 CNI 外掛，既能觀測 K8s 網路的通訊行為進行觀測、也能讓構建在 K8s 上的雲原生應用的無需埋點插碼就能具備可觀測性。
DeepFlow 由 Agent 和 Server 兩個程式組成。每個 K8s 容器節點、虛擬機器或物理裸機中執行一個 Agent，負責該伺服器上所有應用程式的 AutoMetrics 和 AutoTracing 資料採集。Server 執行在一個 K8s 叢集中，提供 Agent 管理、資料標籤注入、資料寫入、資料查詢服務。
架構圖
DeepFlow 可以做到 CNI 外掛和應用都無感知情況下，一條命令五分鐘就能讓 K8s 網路和雲原生應用的具備可觀測性
helm upgrade deepflow-agent -n deepflow deepflow/deepflow-agent -f values-custom.yamlDeepFlow 產品視覺化，有 UI 介面 和 Grafana Dashboard 兩種形式，以下產品功能主要基於 UI 介面形式
全景呼叫拓撲，包含服務依賴拓撲以及覆蓋網路各個節點的網路路徑拓撲
服務拓撲
網路路徑拓撲
全鏈路分散式拓撲，面向使用者請求的零侵擾分散式追蹤，可從程式碼追蹤到系統程式並進一步追蹤到網路節點
呼叫鏈追蹤
網路監控，包含覆蓋三四層負載、時延、異常、效能等網路指標、分鐘粒度的流日誌及包粒度的時序圖
網路指標
流日誌
時序圖
應用監控，包含HTTP(S)、Dubbo、gRPC、ProtobufRPC、SOFARPC、MySQL、PostgreSQL、Redis、Kafka、MQTT、DNS等協議的 RED 指標及呼叫日誌
應用指標
呼叫日誌
03｜總結
透過分析 Hubble 和 DeepFlow 兩款產品，雖然是不同廠商在做，但是對於 K8s 網路可觀測性的功能點上其實是有一樣的認知，筆者基於兩個產品能力以及業界對可觀測性資料的定義，總結了 K8s 網路可觀測性應該具備的能力如下：
全景展示：服務依賴拓撲指標資料：應用指標/網路指標日誌資料：應用呼叫日誌/網路流日誌/網路時序圖追蹤資料：應用呼叫鏈追蹤/網路路徑追蹤
為了方便大家更好的瞭解在 K8s 網路可觀測性上 Hubble 和 DeepFlow 平臺的差異，總結表格如下：
