溪恒、謝石、遐宇 阿里云云原生 2023-06-27 18:30 發表于浙江

(資料圖片僅供參考)

Kubernetes 本身比較復雜，使用門檻較高，用戶在開始容器化遷移時經常遇到各種各樣的問題，由于缺乏故障定位的技能和工具，用戶常常產生挫敗感，甚至放棄業務容器化。其中網絡問題表現尤為突出，Kubernetes 網絡虛擬化導致網絡問題排查的難度巨大。

KubeSkoop 是阿里云容器服務團隊開源的 Kubernetes 容器網絡診斷工具，支持主流的網絡插件和云廠商的 Kubernetes 集群診斷。它正是為了降低網絡問題排查難度，讓沒有網絡知識的人也可以自動化地定位網絡問題。

Kubernetes 容器網絡診斷工具：

/alibaba/kubeskoop

KubeSkoop 能夠自動構建出給定源和目的地址在容器網絡中的訪問路徑，自動化地采集和分析鏈路上每一個網絡節點的配置，結合 eBPF 內核監控以及 IaaS 層的網絡配置檢查，定位出導致網絡不通的根因，極大地降低了網絡問題定位的時間，即使沒有任何網絡技能的用戶也可以使用。目前在阿里云容器服務的環境中，作為自運維工具解決了大量客戶在大規模 Kubernetes 集群場景下遇到的網絡問題。

本文將會對容器網絡和傳統定位手段帶來的問題進行簡單的介紹，以及對 KubeSkoop 的功能設計等方面進行總體解說。

容器網絡

Cloud Native

網絡連通性-CNI

容器網絡是 Kubernetes 集群中及其重要的一部分，包括了構成集群網絡連通性的 CNI 插件、Service 服務發現機制、NetworkPolicy 網絡策略等。Kubernetes 集群網絡保證了每個 Pod 擁有自己獨立的網絡空間，并且能夠與集群中的 Pod 和 Node 互相通信。

CNI 插件是構成集群容器網絡中的核心，實現集群級別唯一的地址分配，將集群維度的網絡打通。

不同的 CNI 插件，如 Flannel、Calico、Cilium、Terway 等，有其不同的網絡實現，包括地址分配，網絡虛擬化實現，網絡連通性實現等。

服務發現和網絡策略

除 CNI 插件外，Kubernetes 還提供了 Service 作為服務發現，以及 NetworkPolicy 作為網絡策略能力。這些能力也是通過可替換的組件來實現的。

復雜性和網絡問題定位

由于概念繁多，以及插件實現選擇的豐富性，導致 Kubernetes 網絡問題存在著相當的復雜性，包括：

邏輯概念的復雜性 Ingress/Service/NetworkPolicy 配置靈活，可能導致配置錯誤/規則沖突等問題。 使用 ServiceMesh 或第三方 CNI 插件，帶來更復雜的網絡策略和擴展能力。 數據面實現的復雜性 數據平面經過不同組件的多層處理，且存在多種實現。 協議棧鏈路復雜，涉及到網卡驅動 /netfilter/route/bridge 等配置。 不同云廠商的底層配置不同，安全組、路由表等配置復雜。

傳統的容器網絡問題定位手段，主要是通過抓包定位丟包點、壓測復現、人工查配置等方式。存在著定位流程長、大量時間開銷、人員經驗要求高等問題。

在日常的工作中，排查容器網絡問題占用了相當大部分的精力。因此，我們開發了 KubeSkoop 項目，來實現針對容器網絡場景下問題的自動診斷系統。

KubeSkoop 功能

Cloud Native

在我們的分析中，常見的 Kubernetes 網絡問題可以分為以下兩類：

網絡持續不通問題 持續的無法訪問：ping 不同、connect 超時、DNS 無法解析等。 網絡抖動問題 偶發的網絡問題：偶爾的業務超時、504、偶發 reset 等。 網絡性能問題：網絡性能低、QPS 壓不上去等。

在這些問題中，80% 都是可以依賴經驗解決的已知問題。而問題的處理時間主要浪費在 問題上報、信息收集和驗證上。

KubeSkoop 即是針對這兩類場景，通過信息收集（包括 CNI 插件、ServiceMesh、Kernel/eBPF、基礎設施等）、推導和展示（容器服務智能運維、Prometheus、Grafana/Loki 等），實現全鏈路一鍵診斷、網絡棧延遲分析、網絡異常事件識別回溯，快速定位問題根因。

項目可分為兩部分：診斷網絡持續不通問題的 KubeSkoop 連通性診斷， 和分析網絡抖動問題的 KubeSkoop 深度網絡監控。

連通性診斷

通過 KubeSkoop，能夠對網絡持續不通問題進行一鍵診斷。

用戶通過指定網絡不通的來源 IP 和目的 IP 發起一次診斷。在診斷中，KubeSkoop 將會自動構建網絡訪問鏈路，收集網絡棧信息，分析鏈路問題。

同時，診斷包含了 Service、NetworkPolicy 等 Kubernetes 概念的分析，全面覆蓋協議棧、底層 IaaS 的連通性相關檢查，讓用戶無需了解網絡插件的實現，也無需擁有復雜網絡問題排查經驗，就能夠一鍵定位網絡問題并自助解決。

連通性診斷目前提供了 Flannel、Calico（內部包括 Terway）網絡插件插件的診斷支持，以及阿里云作為基礎設施的支持。關于診斷能力的完整使用文檔，可見： /docs/guide/diagnose/intro

深度網絡監控

針對網絡抖動問題，KubeSkoop 深度網絡監控提供了基于 eBPF 的，Pod 級別的容器網絡異常監控能力。

基于 eBPF，KubeSkoop 提供了精簡、低開銷的內核異常監控能力，覆蓋驅動、netfilter、TCP 等完整協議棧，幾十種異常場景的識別。同時，基于云原生部署，提供了與 Prometheus 等可觀測體系的對接，支持網絡問題的 Metrics 查看和事件回溯。

關于深度網絡監控能力的指標透出，可參考： /docs/guide/exporter/exporter-description

KubeSkoop 設計

Cloud Native

KubeSkoop 的設計，同樣分為連通性診斷和深度網絡監控兩部分。

連通性診斷

工作流程 ?

KubeSkoop 連通性診斷的工作流程可分為三步： 拓撲構建、信息采集和鏈路模擬。

拓撲構建

通過用戶所提供的信息，再通過 API Server 獲取集群內的 Pod/Node 資源和 Service/NetworkPolicy 規則，匹配對應的 CNI 插件、基礎設施，構建集群內的訪問關系。

信息采集

在構建鏈路的過程中，KubeSkoop 會按需向集群中的節點下發信息采集任務。采集的內容包括運行時信息、協議棧采集（路由、iptables、IPVS 等）和基礎設施信息（ECS metadata）。采集后的信息用于后續的網絡拓撲構建和診斷模擬過程。

鏈路模擬

KubeSkoop 會根據網絡拓撲和所收集到到的信息，進行檢查和模擬。包括對路徑上的拓撲點和鏈路的轉發模擬、對于 CNI 插件實現的模擬、云廠商的模擬，快速發現鏈路中存在的丟包或錯誤路由配置。

最終，結合網絡拓撲以及診斷中發現的異常鏈路，KubeSkoop 會輸出診斷結果和鏈路中存在的問題，或在 Web UI 中進行直觀地展示。

擴展性

KubeSkoop 連通性診斷提供了對 CNI 插件和基礎設施架構的擴展，能夠輕松地在框架中提供對其它 CNI 插件和云廠商的支持。

深度網絡監控

工作流程

KubeSkoop 深度網絡監控通過在需要采集信息的集群節點上運行 KubeSkkop exporter 的方式，采集節點上 Pod 的網絡監控信息并以多種形式導出，包括：

深度容器網絡采集 通過 eBPF 采集協議棧關鍵點 采集 procfs 下內核透出信息用于回溯 采用 CRI 接口關聯采集點和 Pod 容器指標和異常事件預處理 網絡異常 Metrics 過濾，減少開銷 多指標聚合生成異常 Event 網絡 Metrics 和 Event 展示 通過 Prometheus+Grafa 存儲和回溯異常時間點指標 Grafana Loki 記錄異常事件 KubeSkoop Inspector 查看實時異常事件流

實現

在實現中，采用了 eBPF 作為 KubeSkoop 主要數據的采集來源。eBPF 可以達到在內核中動態注入代碼的目的，eBPF 代碼在內核中執行效率高，并且可以通過 map 和 pert_event 與用戶態通信。eBPF 還自帶了校驗機制，避免了因掛載的程序問題而導致宕機。

為了兼容性和性能考慮，在使用 eBPF 的過程中，我們也做了許多優化措施：

采用 CO-RE 方式減少編譯開銷，提升內核兼容性 減少在關鍵路徑上的注入 盡量在 eBPF 程序中過濾異常數據，以減少內存開銷 默認注入低開銷程序，根據需求可動態插拔 eBPF 采集模塊和修改過濾參數

未來規劃

Cloud Native

目前，KubeSkoop 項目仍舊處于早期階段。我們下一步的規劃包括：

增加更多云廠商和網絡插件的支持。 支持模擬發包和追蹤以定位未知問題點，縮小排查范圍。 提供 KubeSkoop Analysis 工具，智能分析 KubeSkoop 的指標和事件，降低診斷結果理解門檻。 不限于網絡診斷，增加存儲、性能診斷。 應用層感知能力，提供對7層協議（如 http、redis 等）的感知和處理。

KubeSkoop 的官網位于：

歡迎大家前來試用&提供建議&貢獻代碼！ 也歡迎通過搜索群號的方式加入 KubeSkoop 用戶釘釘交流群~（群號：26720020148）