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

(資料圖片僅供參考)

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

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

Kubernetes 容器網(wǎng)絡(luò)診斷工具：

/alibaba/kubeskoop

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

本文將會對容器網(wǎng)絡(luò)和傳統(tǒng)定位手段帶來的問題進行簡單的介紹，以及對 KubeSkoop 的功能設(shè)計等方面進行總體解說。

容器網(wǎng)絡(luò)

Cloud Native

網(wǎng)絡(luò)連通性-CNI

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

CNI 插件是構(gòu)成集群容器網(wǎng)絡(luò)中的核心，實現(xiàn)集群級別唯一的地址分配，將集群維度的網(wǎng)絡(luò)打通。

不同的 CNI 插件，如 Flannel、Calico、Cilium、Terway 等，有其不同的網(wǎng)絡(luò)實現(xiàn)，包括地址分配，網(wǎng)絡(luò)虛擬化實現(xiàn)，網(wǎng)絡(luò)連通性實現(xiàn)等。

服務(wù)發(fā)現(xiàn)和網(wǎng)絡(luò)策略

除 CNI 插件外，Kubernetes 還提供了 Service 作為服務(wù)發(fā)現(xiàn)，以及 NetworkPolicy 作為網(wǎng)絡(luò)策略能力。這些能力也是通過可替換的組件來實現(xiàn)的。

復(fù)雜性和網(wǎng)絡(luò)問題定位

由于概念繁多，以及插件實現(xiàn)選擇的豐富性，導(dǎo)致 Kubernetes 網(wǎng)絡(luò)問題存在著相當(dāng)?shù)膹?fù)雜性，包括：

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

傳統(tǒng)的容器網(wǎng)絡(luò)問題定位手段，主要是通過抓包定位丟包點、壓測復(fù)現(xiàn)、人工查配置等方式。存在著定位流程長、大量時間開銷、人員經(jīng)驗要求高等問題。

在日常的工作中，排查容器網(wǎng)絡(luò)問題占用了相當(dāng)大部分的精力。因此，我們開發(fā)了 KubeSkoop 項目，來實現(xiàn)針對容器網(wǎng)絡(luò)場景下問題的自動診斷系統(tǒng)。

KubeSkoop 功能

Cloud Native

在我們的分析中，常見的 Kubernetes 網(wǎng)絡(luò)問題可以分為以下兩類：

網(wǎng)絡(luò)持續(xù)不通問題 持續(xù)的無法訪問：ping 不同、connect 超時、DNS 無法解析等。 網(wǎng)絡(luò)抖動問題 偶發(fā)的網(wǎng)絡(luò)問題：偶爾的業(yè)務(wù)超時、504、偶發(fā) reset 等。 網(wǎng)絡(luò)性能問題：網(wǎng)絡(luò)性能低、QPS 壓不上去等。

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

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

項目可分為兩部分：診斷網(wǎng)絡(luò)持續(xù)不通問題的 KubeSkoop 連通性診斷， 和分析網(wǎng)絡(luò)抖動問題的 KubeSkoop 深度網(wǎng)絡(luò)監(jiān)控。

連通性診斷

通過 KubeSkoop，能夠?qū)W(wǎng)絡(luò)持續(xù)不通問題進行一鍵診斷。

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

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

連通性診斷目前提供了 Flannel、Calico（內(nèi)部包括 Terway）網(wǎng)絡(luò)插件插件的診斷支持，以及阿里云作為基礎(chǔ)設(shè)施的支持。關(guān)于診斷能力的完整使用文檔，可見： /docs/guide/diagnose/intro

深度網(wǎng)絡(luò)監(jiān)控

針對網(wǎng)絡(luò)抖動問題，KubeSkoop 深度網(wǎng)絡(luò)監(jiān)控提供了基于 eBPF 的，Pod 級別的容器網(wǎng)絡(luò)異常監(jiān)控能力。

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

關(guān)于深度網(wǎng)絡(luò)監(jiān)控能力的指標(biāo)透出，可參考： /docs/guide/exporter/exporter-description

KubeSkoop 設(shè)計

Cloud Native

KubeSkoop 的設(shè)計，同樣分為連通性診斷和深度網(wǎng)絡(luò)監(jiān)控兩部分。

連通性診斷

工作流程 ?

KubeSkoop 連通性診斷的工作流程可分為三步： 拓?fù)錁?gòu)建、信息采集和鏈路模擬。

拓?fù)錁?gòu)建

通過用戶所提供的信息，再通過 API Server 獲取集群內(nèi)的 Pod/Node 資源和 Service/NetworkPolicy 規(guī)則，匹配對應(yīng)的 CNI 插件、基礎(chǔ)設(shè)施，構(gòu)建集群內(nèi)的訪問關(guān)系。

信息采集

在構(gòu)建鏈路的過程中，KubeSkoop 會按需向集群中的節(jié)點下發(fā)信息采集任務(wù)。采集的內(nèi)容包括運行時信息、協(xié)議棧采集（路由、iptables、IPVS 等）和基礎(chǔ)設(shè)施信息（ECS metadata）。采集后的信息用于后續(xù)的網(wǎng)絡(luò)拓?fù)錁?gòu)建和診斷模擬過程。

鏈路模擬

KubeSkoop 會根據(jù)網(wǎng)絡(luò)拓?fù)浜退占降降男畔ⅲM行檢查和模擬。包括對路徑上的拓?fù)潼c和鏈路的轉(zhuǎn)發(fā)模擬、對于 CNI 插件實現(xiàn)的模擬、云廠商的模擬，快速發(fā)現(xiàn)鏈路中存在的丟包或錯誤路由配置。

最終，結(jié)合網(wǎng)絡(luò)拓?fù)湟约霸\斷中發(fā)現(xiàn)的異常鏈路，KubeSkoop 會輸出診斷結(jié)果和鏈路中存在的問題，或在 Web UI 中進行直觀地展示。

擴展性

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

深度網(wǎng)絡(luò)監(jiān)控

工作流程

KubeSkoop 深度網(wǎng)絡(luò)監(jiān)控通過在需要采集信息的集群節(jié)點上運行 KubeSkkop exporter 的方式，采集節(jié)點上 Pod 的網(wǎng)絡(luò)監(jiān)控信息并以多種形式導(dǎo)出，包括：

深度容器網(wǎng)絡(luò)采集 通過 eBPF 采集協(xié)議棧關(guān)鍵點 采集 procfs 下內(nèi)核透出信息用于回溯 采用 CRI 接口關(guān)聯(lián)采集點和 Pod 容器指標(biāo)和異常事件預(yù)處理 網(wǎng)絡(luò)異常 Metrics 過濾，減少開銷 多指標(biāo)聚合生成異常 Event 網(wǎng)絡(luò) Metrics 和 Event 展示 通過 Prometheus+Grafa 存儲和回溯異常時間點指標(biāo) Grafana Loki 記錄異常事件 KubeSkoop Inspector 查看實時異常事件流

實現(xiàn)

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

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

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

未來規(guī)劃

Cloud Native

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

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

KubeSkoop 的官網(wǎng)位于：

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