#挑戰30天在頭條寫日記# #網際網路# #讓AI觸手可及# #金融# #财經# #程式員# #馬斯克# #chat GPT#
今天跟大家分享的eBPF（extended Berkeley Packet Filter），相信很多技術人員已經很熟悉了。作為 Linux 社群的新寵，它備受，如 Goole、Facebook、Twitter 等大公司的青睐。
一、eBPF 究竟有什麼魔力讓大家這麼關注它呢？
這是因為 eBPF 增加了核心的可擴充性，讓核心變得更加靈活和強大。如果大家玩過樂高積木的話就會深有體會，樂高積木就是通過不斷向主體添加積木來組合出更龐大的模型。而 eBPF 就像樂高積木一樣，可以不斷向核心添加 eBPF 子產品來增強核心的功能。
二、什麼是 eBPF
在介紹eBPF (Extended Berkeley Packet Filter)之前，我們先來了解一下它的前身－BPF (Berkeley Packet Filter)伯克利資料包過濾器。
BPF最早由Van Jacobson在1992年開發，用于在Unix作業系統中過濾和捕獲網絡資料包。它運作在核心中，通過提供一個簡單而強大的虛拟機，可以在網絡協定層上進行高效的資料包處理操作。BPF通過把過程轉換成指令序列來實作，這些指令直接在核心中執行，進而避免了使用者空間和核心空間之間頻繁的切換。
三、基于BPF開發的工具庫有libpcap、tcpdump等工具。
BPF在網絡性能監測和安全政策實施方面具有廣泛的應用。然而，由于其指令集的限制和功能的局限性，它無法支援更加複雜和靈活的資料包處理需求。
正是為了克服BPF的限制，eBPF應運而生。eBPF于2014年（3.18版本）年首次引入Linux核心，并在此後的幾年中經曆了快速的發展和完善。
eBPF是一個高度可擴充的、運作在核心中的虛拟機，具備與傳統BPF相似的指令集，但功能更加強大且更加靈活。eBPF可以在運作時即時編譯，進而能夠處理更加複雜和動态的資料包處理任務，如網絡流量分析、安全檢測和性能優化等。
eBPF的靈活性和可擴充性展現在它可以與各種使用者空間程式（如tcpdump、Wireshark、Suricata等）和工具（如網絡監控、調試器等）無縫內建。
eBPF還可以與系統的其他元件（如網絡協定棧、排程器等）互動，進而實作更加細粒度的性能優化和安全政策。
此外，eBPF的開發和使用也得到了廣泛的支援和推動。社群中有許多緻力于eBPF的開發者和貢獻者，他們不斷改進和擴充eBPF的功能。同時，一些知名的大型技術公司，如Facebook、Netflix和Google等，也在其産品和基礎設施中廣泛使用eBPF。
四、eBPF的發展史
2014 年初，Alexei Starovoitov 實作了eBPF。新的設計針對現代硬體進行了優化，是以eBPF生成的指令集比舊的 BPF 解釋器生成的機器碼執行得更快。 擴充版本也增加了虛拟機中的寄存器數量，将原有的 2 個 32 位寄存器增加到10 個 64 位寄存器。
由于寄存器數量和寬度的增加，開發人員可以使用函數參數自由交換更多的資訊，編寫更複雜的程式。總之，這些改進使eBPF版本的速度比原來的 BPF 提高了 4 倍。
eBPF是一項具有革命性的技術，源自于Linux核心，可以在特權環境中運作受沙盒保護的程式，例如作業系統核心。它被用于安全有效地擴充核心的功能，而無需更改核心源代碼或加載核心子產品。
在曆史上，作業系統一直是實作可觀察性、安全性和網絡功能的理想場所，這是因為核心具有特權能力，可以監督和控制整個系統。與此同時，由于核心在系統中的核心地位以及對穩定性和安全性的高要求，作業系統核心的演進往往很困難。是以，與作業系統外部實作的功能相比，作業系統層面的創新速度傳統上較低。
eBPF從根本上改變了這個現象。通過在作業系統内運作受沙盒保護的程式，應用開發人員可以在運作時運作eBPF程式，為作業系統添加額外的功能。作業系統會利用即時編譯器和驗證引擎的幫助來保證安全性和執行效率，就像本地編譯一樣。這導緻了一系列基于eBPF的項目的湧現，涵蓋了各種用例，包括下一代網絡、可觀測性和安全功能。
五、eBPF應用場景
如今，eBPF被廣泛應用于驅動各種用例：在現代資料中心和雲原生環境中提供高性能的網絡和負載均衡；
以低開銷提取細粒度的安全可觀測性資料，幫助應用開發人員追蹤應用程式、提供性能故障排除的見解，進行預防性應用程式和容器運作時安全執行等等。
可能性是無限的，eBPF正在釋放出的創新力量才剛剛開始。
六、eBPF 特性
1.Hook Overview
eBPF 程式都是事件驅動的，它們會在核心或者應用程式經過某個确定的 Hook 點的時候運作，這些 Hook 點都是提前定義的，包括系統調用、函數進入/退出、核心 tracepoints、網絡事件等。
2.Verification
With great power there must also come great responsibility.
每一個 eBPF 程式加載到核心都要經過 Verification，用來保證 eBPF 程式的安全性，主要包括：
要保證加載 eBPF 程式的程序有必要的特權級，除非節點開啟了 unpriviledged 特性，隻有特權級的程式才能夠加載 eBPF 程式。
1、核心提供了一個配置項 /proc/sys/kernel/unprivileged_bpf_disabled 來禁止非特權使用者使用 bpf(2) 系統調用，可以通過 sysctl 指令修改
2、比較特殊的一點是，這個配置項特意設計為一次性開關（one-time kill switch）， 這意味着一旦将它設為 1，就沒有辦法再改為 0 了，除非重新開機核心
3、一旦設定為 1 之後，隻有初始命名空間中有 CAP_SYS_ADMIN 特權的程序才可以調用 bpf(2) 系統調用 。Cilium 啟動後也會将這個配置項設為 1：
$ echo 1 > /proc/sys/kernel/unprivileged_bpf_disabled 要保證 eBPF 程式不會崩潰或者使得系統出故障。
要保證 eBPF 程式不能陷入死循環，能夠 runs to completion。
要保證 eBPF 程式必須滿足系統要求的大小，過大的 eBPF 程式不允許被加載進核心。
要保證 eBPF 程式的複雜度有限，Verifier 将會評估 eBPF 程式所有可能的執行路徑，必須能夠在有限時間内完成 eBPF 程式複雜度分析。
3.JIT Compilation
Just-In-Time（JIT）編譯用來将通用的 eBPF 位元組碼翻譯成與機器相關的指令集，進而極大加速 BPF 程式的執行：
- 與解釋器相比，它們可以降低每個指令的開銷。通常，指令可以 1:1 映射到底層架構的原生指令
- 這也會減少生成的可執行鏡像的大小，是以對 CPU 的指令緩存更友好
- 特别地，對于 CISC 指令集（例如 x86），JIT 做了很多特殊優化，目的是為給定的指令産生可能的最短操作碼，以降低程式翻譯過程所需的空間
64 位的 x86_64、arm64、ppc64、s390x、mips64、sparc64 和 32 位的 arm 、x86_32 架構都内置了 in-kernel eBPF JIT 編譯器，它們的功能都是一樣的，可以用如下方式打開：
$ echo 1 > /proc/sys/net/core/bpf_jit_enable 32 位的 mips、ppc 和 sparc 架構目前内置的是一個 cBPF JIT 編譯器。這些隻有 cBPF JIT 編譯器的架構，以及那些甚至完全沒有 BPF JIT 編譯器的架構，需要通過核心中的解釋器（in-kernel interpreter）執行 eBPF 程式。
要判斷哪些平台支援 eBPF JIT，可以在核心源檔案中 grep HAVE_EBPF_JIT：
$ git grep HAVE_EBPF_JIT arch/
arch/arm/Kconfig: select HAVE_EBPF_JIT if !CPU_ENDIAN_BE32
arch/arm64/Kconfig: select HAVE_EBPF_JIT
arch/powerpc/Kconfig: select HAVE_EBPF_JIT if PPC64
arch/mips/Kconfig: select HAVE_EBPF_JIT if (64BIT && !CPU_MICROMIPS)
arch/s390/Kconfig: select HAVE_EBPF_JIT if PACK_STACK && HAVE_MARCH_Z196_FEATURES
arch/sparc/Kconfig: select HAVE_EBPF_JIT if SPARC64
arch/x86/Kconfig: select HAVE_EBPF_JIT if X86_64 好啦，本期關于運維可觀測工具eBPF的分享到這裡就告一段落了，下期我們再來講講eBPF在實際使用中遇到的問題。感興趣的朋友可以關注一下~
擎創科技，Gartner連續推薦的AIOps領域标杆供應商。公司專注于通過提升企業客戶對運維資料的洞見能力，為運維降本增效，充分展現科技運維對業務營運的影響力。
行業龍頭客戶的共同選擇
了解更多運維幹貨與行業前沿動态
可以右上角一鍵關注
我們是深耕智能運維領域近十年的
連續多年獲Gartner推薦的AIOps标杆供應商
下期我們不見不散~