eBPF 允許用戶在 Linux 內核中加載和安全運行自定義程序，而無需直接更改內核本身?？赡苄允菬o限的。

譯自How eBPF is shaping the future of Linux and platform engineering，作者 Travis Van。

當Docker 在 2013 年橫空出世時，Linux 容器似乎一夜之間就取得了成功。但容器（以及微服務和Kubernetes）的演變實際上是幾十年來的積累，其基礎是 Linux 操作系統(tǒng)中的內核原語。Docker 使用這些原語，即 cgroups 和 namespaces，作為構建塊來創(chuàng)建輕量級、易于使用的軟件打包格式。Linux 容器多年來一直被 Google 和其他 [行家？] 使用，但 Docker 使其易于被主流開發(fā)人員訪問。

而這正是我們今天在eBPF周圍看到的情況——另一項源自 Linux 內核原語的技術。如今，每個主要的網絡、可觀察性和安全供應商都在宣稱提供“基于 eBPF 的”產品。像 Cilium、Tetragon 和 Falco 這樣的 eBPF 工具正在企業(yè)架構和云服務提供商產品中扎根。據其創(chuàng)造者之一說，這僅僅是基于 eBPF 的突破的開始。

InfoWorld 與 Daniel Borkmann 進行了交談——eBPF 的共同創(chuàng)造者，也是 Linux 內核當前的 eBPF 共同維護者——以了解更多關于該技術起源的信息，為什么 eBPF 已成為編程和定制 Linux 內核的標準方法，以及這對 Linux 和平臺工程的未來意味著什么。

從 Solaris 學生到 Linux 內核維護者

Daniel Borkmann 走向 eBPF 的道路始于對理解 Solaris 內部機制的追求，Solaris 當時仍在大學的計算機科學課程中教授。然而，一個主要障礙是缺乏源代碼來查看“魔法發(fā)生的地方”。Borkmann 發(fā)現操作系統(tǒng)課程中的理論非常有趣，但真正讓他醍醐灌頂的是他深夜研究 Linux 內核源代碼、Git 日志和郵件列表。他開始編寫與內核交互的低級用戶應用程序。

很快，Borkmann 開始探索數據包過濾器、tcpdump 和 libpcap，以及數據包在進出時遍歷不同層時網絡堆棧的工作原理。他在業(yè)余時間編寫了一個更高效的 tcpdump 克隆，并開始向 Linux 網絡堆棧發(fā)送一些代碼改進。在他碩士學習開始時，他最終獲得了第一份在德國萊比錫的一家當地初創(chuàng)公司開發(fā) Linux 內核代碼的付費工作。

Borkmann 在 2010 年提交了他的第一個補丁到 Linux 內核，當時他還是一個“完全的新手”（他的原話），目的是擴展 netpoll 以允許每個接口執(zhí)行多個 rx_hooks，并且意外地引入了一個錯誤，該錯誤會導致內核死鎖，該錯誤很快被另一位貢獻者發(fā)現并修復。但他被迷住了。Linux 內核開發(fā)是一個迷人的環(huán)境，他知道這是他的使命。

Borkmann 搬到蘇黎世，完成關于為內核開發(fā)可組合網絡堆棧的碩士論文。從 FreeBSD 的 netgraph 中汲取靈感，他的實驗是嘗試將網絡塊卸載到 FPGA 上，并為數據包處理構建可組合的圖。但在此過程中，他有時發(fā)現學術論文過于枯燥，缺乏長期的現實世界影響，并意識到全職為 Linux 內核做出貢獻會更有意義。他發(fā)現了一位名叫 Thomas Graf 的 Linux 貢獻者（最終他們都成為了 Cilium 的共同創(chuàng)造者），他的電子郵件有一個瑞士域名（.ch），自發(fā)地聯系了他——并被邀請加入 Red Hat 的 Linux 內核網絡團隊。

現在，Borkmann 是全球 Linux 內核貢獻者中排名前 1% 的人之一。

eBPF 背后的起源故事實際上始于 2011 年，當時軟件定義網絡 (SDN) 正在興起，Linux 的采用率正在飆升。Linux 子系統(tǒng)需要跟上微服務架構和分布式應用程序的新范式，這些應用程序運行在 Linux 機器集群中，而不是單個服務器和主機操作系統(tǒng)上。

Borkmann 在網絡堆棧中開發(fā)內核的工作讓他站在滿足 SDN 和云原生網絡需求的前線。Linux 需要更新的抽象，因為其許多構建塊在十多年前就已經設計好了——cgroup（CPU、內存處理）、命名空間（網絡、掛載、pid）、SELinux、secomp、Netfilter、Netlink、AppArmor、Auditd、Perf 等。Borkmann 看到 netfilter 的 nftables 等技術被推為“下一代”Linux 網絡，以及 Open vSwitch（OVS），它當時是最先進的 SDN 項目。他認為有更好的方法。

Linux 內核正在不斷擴展以跟上更高的網絡速度，但沒有提供足夠的靈活性來編程新的自定義功能。另一個限制是“絕不破壞用戶空間”。也就是說，Linux 內核必須繼續(xù)支持所有在云原生應用程序出現之前很久就開發(fā)的軟件。不幸的是，這些“遺留包袱”將一些網絡創(chuàng)新從內核移動到了用戶空間。

總之，新的云操作模式為我們帶來了更多的自動化、提取轉換加載 (ETL) 和規(guī)模，以及更嚴苛的網絡性能要求。然而，Linux 內核中的自包含子系統(tǒng)并未對將所有這些新的云上下文中送入內核、聚合這些內容以及對其進行操作達成公約。

在 Linux 編程中，數據包處理（解析、操作、過濾和轉發(fā)）是“可能實現的功能”的一個基礎關注點。這是內核開發(fā)人員對通過堆棧傳輸的網絡數據包進行路由、控制和檢查的機制。數據包處理對于內核的網絡堆棧，就如同化油器對于發(fā)動機，通量電容對于 Doc 的狄羅倫一樣。

應用程序開發(fā)者大多數都在用戶空間內編寫其應用程序，使用保護他們免受需對內核進行的系統(tǒng)調用的抽象。因此，當應用程序需要與硬件進行接口（寫入屏幕、寫入文件、發(fā)送網絡數據包）時，它必須請求內核提供幫助。用戶空間無法直接執(zhí)行此操作（出于多種原因，例如系統(tǒng)安全性）。內核提供用戶空間應用程序和硬件之間的通用且泛用的接口，并協調同時運行的多個用戶空間進程。

從虛擬化到容器的演進過程中，許多不同的數據包篩選方法競爭在 Linux 內核中占有一席之地：iptables、nftables、OVS、Linux 流量控制 (TC) 等。eBPF 最終勝出成為首選方法，因為它將表達能力與驗證器的安全性相結合（同時以本機性能執(zhí)行程序）。換句話說，eBPF 允許用戶以這些備選方案無法實現且不會導致內核崩潰的方式對內核進行編程。

一個更為“可編程”的 Linux 內核

開始時，Borkmann 被 eBPF 的靈活性及其給網絡帶來的性能所吸引，但很明顯，這項新技術的好處遠遠超出了網絡領域。

“一旦 eBPF 實現了此項基礎功能，讓你能夠構建內容并立即部署，它便解決了一個大問題，”Borkmann 說?！澳憧梢跃帉懬度?eBPF 的編排計劃，并將其部署到任何底層內核版本。你無需再為核心內核 ABI 穩(wěn)定性向大型供應商支付巨額費用，現在只需使用 eBPF 即可，而不必再使用模塊來針對大量不同的用例擴展內核?！?/p>

eBPF 轉變?yōu)橐环N通用匯編語言，該語言允許用戶在 Linux 內核中加載和安全運行自定義程序，這是一種在運行時向操作系統(tǒng)中添加各種功能的方法。它具有嚴格的類型，具有穩(wěn)定的指令集，并且其擴展具有后向兼容性。

Borkmann 解釋道：“你可以將其視為一種新型的軟件，能夠彌合典型的單內核與微內核之間的差距”。“它是你受信任的用戶空間中內核的安全擴展。關于 eBPF 很重要的一個方面是，它與常規(guī)內核代碼一樣快，這是由于 eBPF 不是沙箱，并且驗證程序可以完全理解該程序以確定它是否可以在受信任的環(huán)境中安全運行，然后再 JITed [即時編譯] 為本機代碼?！?/p>

eBPF 不僅安全且快速，還可以在本機速度下運行。它極其靈活，允許不同用戶以不同方式使用它?！癳BPF 的強大之處在于你可以僅當你作為用戶有該用例或需要以某種方式處理某些內容時啟用代碼，”Borkmann 說?！斑@不會懲罰他人。它不像以硬編碼方式編入內核的東西，這將使關鍵路徑越來越慢——性能死亡是一千次的削減。”

“在 eBPF 出現之前，大多數用戶使用企業(yè) Linux 發(fā)行版，或者直接運行設備上安裝的內核版本，”Cilium 的 Graf 說?！癳BPF 從根本上改變了這一點，因為有了運行時的存在，任何想法都可以轉化為 eBPF 程序，并在幾天內而不是幾年內在運行時加載。這意味著我們可以更好地重建一切。我們必須決定首先重建什么?！?/p>

內核工程走向主流

與 Google Borg 和其他誕生于超大規(guī)模企業(yè)的技術一樣，eBPF 最初只被少數擁有內核開發(fā)技能的軟件工程團隊采用。并非所有開發(fā)人員都具備必要的低級 C 編程技能來進行內核工程和編寫 eBPF 程序。

但如今，這少數專家正在編寫影響數百萬用戶的程序。eBPF 驅動的程序是平臺工程團隊最令人興奮的領域，這些團隊負責網絡、安全和可觀察性，而許多使用這些程序的人不需要了解使它們成為可能的底層 eBPF 抽象?！鞍阉胂蟪蓙碜栽圃囊粓鰺o聲的平臺革命，”正如 Borkmann 在最近關于 eBPF 的研討會上的一次主題演講中所指出的那樣。

以下是廣闊的 eBPF 領域中眾多應用的概覽：

Cilium最初是容器網絡接口(CNI) 的基于 eBPF 的實現，用于提供容器工作負載之間的第 3 層和第 4 層連接，但后來發(fā)展成為大多數云服務提供商 Kubernetes 產品的實際網絡層。除了其他功能外，Cilium 還為 Kubernetes Pod 之間以及到外部服務的流量實現分布式負載均衡，并且能夠完全替換 kube-proxy，使用 eBPF 中的高效哈希表實現幾乎無限的擴展。它還支持高級功能，如第 3 層到第 7 層策略執(zhí)行、集成入口和出口網關、帶寬管理、與 Envoy 結合的服務網格以及深度網絡可見性。

Tetragon是另一個 eBPF 程序，它提供安全可觀察性和運行時強制執(zhí)行。通過利用 eBPF 的低開銷，Tetragon 允許平臺團隊將網絡流和其他內核事件與 Kubernetes 對象（標簽、Pod、命名空間）綁定，直至非常具體的進程及其相關的進程樹。在XZ Utils等軟件供應鏈安全漏洞出現后，Tetragon 是一個開源項目，旨在為平臺團隊提供更深入的方法來查找特定軟件在其環(huán)境中的運行位置，并在內核級別采取特定的策略操作。

Pixie是一款可觀察性工具，它使用 eBPF “自動捕獲遙測數據，無需手動檢測”。它已成為下一代應用程序性能管理和監(jiān)控供應商的熱門構建塊。在 Google 上簡單搜索“可觀察性 AND eBPF”就可以看出這項技術如何改變了 eBPF 性能帶來的遙測數據豐富性。推斷云原生系統(tǒng)的實時狀態(tài)歷來涉及堆積監(jiān)控數據，這些數據必須在將來進行關聯。將這種遙測數據收集更靠近內核，有望帶來更高的一致性和更低的資源使用率。

Katran是一個 C++ 庫，它可以挑戰(zhàn)專有第 3 層和第 4 層負載均衡器的現狀，采用一種基于內核包處理的新方法。并非每個人都能創(chuàng)建 eBPF 程序，但正在創(chuàng)建的程序針對的是企業(yè)基礎設施中相對停滯的領域，并且迫切需要現代化以滿足云原生用例的需求。

“未來十年的基礎設施軟件將由能夠使用 eBPF 以及利用 eBPF 創(chuàng)建適合更高層平臺的抽象的平臺工程師來定義，”Borkmann 說?！皩⒃圃舷挛耐迫雰群耸侨笔У模?eBPF 解決了這個問題。”

在本月我們慶祝Kubernetes 10 周年之際，我們仍然處于分布式應用程序、容器編排和平臺工程的早期階段?？赡芎苌儆腥藭苯釉趦群思墑e進行 eBPF 工程，但數百萬用戶將使用基于 eBPF 的程序。如果您在大型公共云提供商平臺之一上運行 Kubernetes 上的工作負載，那么您很可能已經在使用它了。