K8s 應用的網路可觀測性: Cilium VS DeepFlow

雲杉網路發表於2023-03-18

隨著分散式服務架構的流行,特別是微服務等設計理念在現代應用普及開來,應用中的服務變得越來越分散,因此服務之間的通訊變得越來越依賴網路,很有必要來談談實現微服務可觀測性中越來越重要的一環——雲原生網路的可觀測。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.yaml

DeepFlow 產品視覺化,有 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 平臺的差異,總結表格如下:

image.png

image.png

04|參考文件

https://github.com/cilium/hubblehttps://docs.cilium.io/en/stable/overview/intro/https://github.com/deepflowio/deepflowhttps://deepflow.io/docs/zh/about/overview/

相關文章