如何進行eBPF應(yīng)用分析

今天就跟大家聊聊有關(guān)如何進行eBPF應(yīng)用分析，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

最近一直在學習eBPF以及當前的應(yīng)用案例，搜索到這篇文章。這篇文章將目前市面上主流的應(yīng)用場景描述的很清楚。但是傳播度不夠，關(guān)鍵詞的搜索中也不是第一個出現(xiàn)的。所以，我也是簡單的調(diào)整了下格式發(fā)出來。原文鏈接也找不到了，如果涉及到版權(quán)請聯(lián)系我。eBPF是當前的網(wǎng)絡(luò)開發(fā)領(lǐng)域中的熱點，netconf也有多篇相關(guān)的topic。后續(xù)我會把eBPF/XDP的源碼實現(xiàn)，應(yīng)用場景，當前現(xiàn)狀也會陸續(xù)整理發(fā)出來。
 

引子

Linux內(nèi)核社區(qū)最近發(fā)布了bpfilter，一個使用Linux BPF提供的高性能網(wǎng)絡(luò)過濾內(nèi)核模塊，用來替代netfilter作為iptables的長期支持的內(nèi)核底層的實現(xiàn)，實現(xiàn)Linux用戶的無痛向BPF過渡的換心手術(shù)。

BPF可能我們比較生疏，但是我說起tcpdump、Wireshark等流行的網(wǎng)絡(luò)抓包和分析工具你一定聽說并可能使用過，他們底層的包過濾實現(xiàn)就是用的BPF。所以他不是一個新的技術(shù)，也已經(jīng)陪伴我們很久了。目前，BPF已經(jīng)成長為一個高度靈活的和豐富功能的框架，它可以以不犧牲系統(tǒng)性能和安全性為前提下，大幅度擴展Linux的功能。BPF強大的靈活性、穩(wěn)定性和豐富的功能，使得業(yè)界翹楚比如谷歌，facebook和Netflix等Linux內(nèi)核前瞻性大企業(yè)用戶紛紛對其伸出橄欖枝，用BPF來實現(xiàn)網(wǎng)絡(luò)安全、負載均衡，還有性能監(jiān)控、故障排查等大量的用途。 Netflix的Brendan Gregg首先稱其為Linux的BPF Superpowers。

下面將介紹這些大企業(yè)實踐中由于如何超負荷使用iptables內(nèi)核子系統(tǒng)，從而導(dǎo)致的冗余、性能低下等問題，以及新內(nèi)核如何利用新特性優(yōu)雅地從底層解決這些問題。

在過去15年類，Linux內(nèi)核社區(qū)構(gòu)建了很多內(nèi)核子系統(tǒng)，包括TPC/IP棧，iptables(netfiter)等等，在此過程中我們也看到了BPF一步步發(fā)展、成長、壯大。現(xiàn)在內(nèi)核的新轉(zhuǎn)變讓我們意識到了BPF不僅僅是另一個功能，而是代表了一個根本的技術(shù)轉(zhuǎn)型，它將及時改變Linux從網(wǎng)絡(luò)到安全的各個方面。從iptables到bpfilter的轉(zhuǎn)變,只是BPF為振興Linux網(wǎng)絡(luò)棧領(lǐng)域,使其更現(xiàn)代化的重要一步。為了解釋為什么會有這激動人心的一步轉(zhuǎn)變，首先我們介紹下內(nèi)核中iptables的歷史演變。

iptables及順序過濾的起源

多年來iptables一直是Linux上實現(xiàn)防火墻和網(wǎng)絡(luò)數(shù)據(jù)包過濾器的最主要的工具。從最初的ipchains，很多l(xiāng)inux老司機最初可能都接觸ipchains，他是iptables前身，是在linux 內(nèi)核 2.2.10引入。然后是在2001年linux內(nèi)核版本2.4.0開始引入了iptables。從此，多少年一來，iptables一直給用戶帶來了便利和麻煩兩重天。一方面享受的靈活性和快速修復(fù)。另一方面，又為了在調(diào)試5000條沉沉的過濾規(guī)則而犯難，想為此罵娘。

當iptables在20年前取代其前身ipchains時，開始其生命周期時，防火墻功能的范圍還很簡單明確：

1. 保護本地應(yīng)用程序免受不需要的網(wǎng)絡(luò)通信（INPUT鏈）

2. 保護本地應(yīng)用程序發(fā)送不需要的網(wǎng)絡(luò)通信（OUTPUT鏈）

3. 過濾由Linux系統(tǒng)（FORWARD鏈）轉(zhuǎn)發(fā)/路由的網(wǎng)絡(luò)流量。

那時后網(wǎng)絡(luò)速度很慢，日子過的很慢。還記得用宿舍用Modem，201卡撥號情形么？那是iptables最初被設(shè)計和開發(fā)的時代。用iptables實現(xiàn)訪問控制列表（ACLs）的標準做法是使用連續(xù)的規(guī)則列表，即每個接收或發(fā)送的網(wǎng)絡(luò)數(shù)據(jù)包都要逐一與規(guī)則列表進行匹配，直到匹配或者全不匹配。然而，逐行的處理有明顯的缺陷：過濾數(shù)據(jù)包的成本，隨著添加的規(guī)則數(shù)量線性增加。

權(quán)衡處理：ipset

一段時間過去了，網(wǎng)絡(luò)速度開始提高了，iptables的設(shè)置規(guī)則，也從十幾條增加到數(shù)千條規(guī)則。從性能和延遲角度來看，遍歷順序的iptables列表已經(jīng)變得不可忍受。

社區(qū)很快發(fā)現(xiàn)了瓶頸所在：長長的規(guī)則列表要么拒絕，要么允許單獨的IP地址和端口組合。為此引進了ipset對IP地址進行管理。 ipset允許將與IP地址和端口組合存儲到散列表中，在iptables只需引用ipset中的散列的鍵名就可以，極大的減少iptables規(guī)則的數(shù)量，而且ipset散列中的IP地址信息常駐內(nèi)存，匹配非?？臁５@也只是"頭疼醫(yī)頭，腳疼治腳"的治表不治本的暫時權(quán)衡之策。

更不幸的是，ipset還不能適用于所有情況。近些年，隨著容器技術(shù)的崛起，一個明顯的問題是kube-proxy，他是Kubernetes的一個組件，容器要使用iptables和-j DNAT規(guī)則為服務(wù)提供負載均衡。它要為為每個后端服務(wù)要添加多條iptables規(guī)則。對于添加到Kubernetes的每個服務(wù)，要遍歷的iptables規(guī)則列表呈指數(shù)增長。最近的KubeCon議題中詳細研究kube-proxy的性能表現(xiàn)細節(jié)。研究結(jié)果顯示，隨著服務(wù)數(shù)量的增長，網(wǎng)絡(luò)延遲和性能下降無法估量。還披露了iptables的另一個主要缺點，無法實現(xiàn)增量更新。每次添加新規(guī)則時，必須更新整個規(guī)則列表。結(jié)果是對2萬個Kubernetes服務(wù)16萬條的iptables規(guī)則，裝配這些規(guī)則需要耗時5個小時。

使用基于IP/端口的機制一般還有許多其他明顯的缺點，特別是在容器應(yīng)用環(huán)境下。容器需要經(jīng)常部署和刪除。這可能導(dǎo)致個別IP地址的使用快速變化。一個IP地址可能被一個容器使用幾秒鐘，然后在幾秒鐘之后會換到一個容器使用。這使得依靠使用IP地址進行安全過濾的系統(tǒng)受到壓力，因為集群中的所有節(jié)點都必須始終知道最新的IP到容器的映射。雖然在一個集群內(nèi)部這幾乎沒有什么難度，但它在如果在分布式的跨集群應(yīng)用中就會很有挑戰(zhàn)性。關(guān)于這些這兒不在贅述，可以參考docker，k8s等相關(guān)的官方文檔。

用BPF統(tǒng)一一切

BPF革命性開發(fā)的新進展更令人興奮，即通過用戶完全透明的方式用BPF完全替換iptables的內(nèi)核部分（netfiter），即現(xiàn)有iptables客戶端和庫無需任何改動。

感興趣的同學可以去linux 內(nèi)核郵件列表中找到相關(guān)的討論。該提案由Daniel Borkmann（Covalent），網(wǎng)絡(luò)維護部分由David Miller（Red Hat）和Alexei Starovoitov（Facebook）撰寫。

Quentin Monnet在FRnOG 30上提供的以下圖表顯示了與iptables和nftables相比較bpfilter的一些早期測試結(jié)果。

這些早期的測試數(shù)據(jù)展示了令人乍舌的性能優(yōu)勢，也是BPF強大的一個實例。我們唯一要注意的是bpfilter和BPF本身并不能解決由iptables使用順序過濾引起的性能問題，要徹底解決這個問題必須使用BPF底層內(nèi)核及原生的BPF應(yīng)用。

看完上述內(nèi)容，你們對如何進行eBPF應(yīng)用分析有進一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。