在 Linux 內核中工作是實現安全性、網絡和可觀察性特性的理想選擇。然而，這并不是沒有挑戰。無論是修改內核源代碼，還是添加模塊，開發人員傳統上發現他們要與難以調試的復雜基礎設施和抽象層作斗爭。Extended BPF[2]（eBPF）解決了這兩個問題。

Extended Berkeley Packet Filter（eBPF）是一種內核技術（從 Linux 4.x 開始），它允許程序在無需更改內核源代碼，或添加額外模塊的情況下運行。你可以將其視為 Linux 內核中的輕量級沙箱虛擬機（VM），程序員可以在其中運行 BPF 字節碼，從而利用特定的內核資源。

使用 eBPF 消除了更改內核源代碼的需要，并簡化了軟件利用現有層的能力。因此，它是一項強大的技術，有可能從根本上改變網絡、可觀察性和安全性等服務的交付方式。

下面詳細介紹一下它是什么，它是如何工作的，以及何時考慮實施它。

eBPF 是如何工作

eBPF 程序是事件驅動的，并附加到代碼路徑上。代碼路徑包含特定的觸發器（稱為鉤子），這些觸發器在傳遞附加的 eBPF 程序時執行它們。鉤子的一些例子包括網絡事件、系統調用、函數項和內核追蹤點。

當觸發時，代碼首先被編譯為 BPF 字節碼。然后，字節碼在運行之前會被驗證，以確保它不會創建循環。這個步驟可以防止程序無意或故意損害 Linux 內核。

在鉤子上觸發程序之后，它就會進行助手調用。這些助手調用是為 eBPF 配備許多用于訪問內存的特性的函數。助手調用需要由內核預先定義，但是存在的函數列表在不斷增長[3]。

eBPF 最初被用作過濾網絡數據包時，提高可觀察性和安全性的一種方法。然而，隨著時間的推移，它成為了一種使用戶提供的代碼實現更安全、更方便和性能更好的方法。

eBPF 的優點

eBPF 通常用于追蹤[4]用戶空間進程，它的優點在這里很明顯。這是一個安全和有用的方法來確保：

•  速度和性能。eBPF 可以將包處理從內核空間轉移到用戶空間。同樣，eBPF 是即時（JIT）編譯器。編譯字節碼后，將調用 eBPF，而不是為每個方法調用字節碼的新解釋。
•  低侵入性。當作為調試器使用時，eBPF 不需要停止程序來觀察其狀態。
•  安全。程序實際上是沙箱化的，這意味著內核源代碼仍然受到保護并且沒有改變。驗證步驟確保資源不會被運行無限循環的程序堵塞。
•  方便。創建鉤子內核函數的代碼比構建和維護內核模塊的工作要少。
•  統一的追蹤。eBPF 為你提供了一個用于追蹤流程的單一、強大且可訪問的框架。這增加了可見性和安全性。
•  可編程性。使用 eBPF 有助于增加環境的特性豐富度，而無需添加額外的層。同樣，由于代碼直接在內核中運行，因此可以在 eBPF 事件之間存儲數據，而不像其他追蹤程序那樣轉儲數據。
•  表達能力。eBPF 具有表達性，能夠執行通常只能在高級語言中找到的功能。

eBPF 的最佳實踐

由于 eBPF 是一項如此新的技術，許多東西仍未被探索。隨著技術的發展，圍繞 eBPF 的最佳實踐仍在不斷發展。雖然沒有明確的最佳實踐集存在，但你可以做一些事情來確保有效、高效的程序。

如果你正在為你的生態系統使用 eBPF，我們建議你：

•  使用LLVM Clang[5]將 C 編譯成字節碼。當 eBPF 首次出現時，需要手工編寫和組裝程序。然后，開發人員使用內核的匯編程序生成字節碼。幸運的是，現在不再需要這樣做了。Clang 提供了 C 語言的前端基礎設施和工具。
•  編寫 BPF 程序時請使用 BCC 工具包。BPF Compiler Collection[6]（BCC）是一個工具包，可以幫助你創建高效的內核追蹤和操作程序。它特別適合于性能分析和網絡流量控制相關的任務。

eBPF 的缺點

盡管 eBPF 功能強大，但它并不是適合每個項目或生態系統的靈丹妙藥。eBPF 確實有一些明顯的缺點，這可能會使它在某些實例中工作起來令人沮喪。一些開發人員可能會發現 eBPF 不適合使用，原因如下：

•  它僅限于 Linux 和一個最新的內核。eBPF 是在 Linux 內核中開發的，并且是完全面向 Linux 內核的。這使得它比其他追蹤器更難攜帶。此外，你需要一個相當新的內核。如果你運行的是比 v4.13 更老的版本，你將無法使用它。
•  沙箱程序是有限的。eBPF 通過限制程序可以訪問的資源來提高安全性。然而，通過限制程序可以訪問的操作系統部分，功能也可能受到限制。

eBPF 的常用情況

eBPF 在云原生應用[7]中正迅速獲得關注。因此，eBPF 最常用于兩種情況：

•  需要使用內核追蹤實現可觀察性。在這種情況下，eBPF 更快、更準確。這里不涉及上下文切換[8]，而且 eBPF 程序是基于事件的，因此沒有特定的觸發器就不會運行任何程序——你不會錯過任何事件。
•  傳統的安全監控不起作用。eBPF 在分布式和基于容器的環境中得到了廣泛的應用，包括Kubernetes[9]。在這些環境中，eBPF 可以縮小可見性差距，因為它可以提供對 HTTP 通信的可見性。

你可能還會發現 eBPF 被部署用于其他安全措施，包括：

•  防火墻
•  設備驅動程序
•  網絡性能監控

New Relic 和 eBPF

Pixie[10]（早前被 New Relic 收購了）是一個開源的 kubernetes-native-in-cluster 可觀察平臺，它提供了 Kubernetes 工作負載的即時可見性，無需手動檢測。eBPF 提供了 Pixie 平臺背后的大部分魔力。如前所述，eBPF 允許在觸發事件時運行受限制的代碼。這個事件可以是內核空間（kprobes）或用戶空間（uprobes）中的函數調用。Pixie 同時使用 uprobes 和 kprobes 來支持跨服務和應用程序的可觀察性。

Pixie 利用 eBPF 自動獲取遙測數據，其邊緣機制能將這些數據與 Kubernetes 元數據連接起來，在保持數據局部性的同時提供可見性。這種可見性補充了 New Relic 強大的 Kubernetes 可觀測性解決方案。從 5 月底開始，你將能夠將 Pixie 生成的遙測數據發送到 New Relic One，獲得可擴展的留存率、強大的可視化、高級關聯和智能警報功能。

eBPF 是有效的可觀察性

eBPF 是一種新技術，它改進了 Linux 內核中的可觀察性、聯網和安全性。它消除了更改內核源代碼或添加模塊的需要，因此你可以創建更豐富的基礎設施來支持你的系統，而不會使其過于復雜。

總結

我們了解了 eBPF 是什么，它是如何工作的，以及為什么它在分布式環境中如此有用。通過從內核層進行監控，許多與云中的可觀測性相關的挑戰都得到了解決。你可以在數據中享受更深入的可見性、更多的上下文和更準確的信息。