大规模微服务利器：eBPF + Kubernetes
hi， 大家好，微服務(wù)，云原生近來大熱，在企業(yè)積極進行數(shù)字化轉(zhuǎn)型，全面提升效率的今天，幾乎無人否認(rèn)云原生代表著云計算的“下一個時代”，IT大廠們都不約而同的將其視為未來云應(yīng)用的發(fā)展方向，從網(wǎng)絡(luò)方向來看，eBPF可能會成為“為云而生”下一代網(wǎng)絡(luò)技術(shù)，今天分享一篇經(jīng)典eBPF文章，希望大家喜歡。
譯者序
本文翻譯自 2020 年 Daniel Borkmann 在 KubeCon 的一篇分享: eBPF and Kubernetes: Little Helper Minions for Scaling Microservices， 視頻見油管。翻譯已獲得 Daniel 授權(quán)。
Daniel 是 eBPF 兩位 maintainer 之一，目前在 eBPF commits 榜單上排名第一，也是 Cilium 的核心開發(fā)者之一。
本文內(nèi)容的時間跨度有 8 年，覆蓋了 eBPF 發(fā)展的整個歷史，非常值得一讀。時間限制， Daniel 很多地方只是點到，沒有展開。譯文中加了一些延展閱讀，有需要的同學(xué)可以參考。
由于譯者水平有限，本文不免存在遺漏或錯誤之處。如有疑問，請查閱原文。
http://arthurchiao.art/blog/ebpf-and-k8s-zh
譯者序
1 eBPF 正在吞噬世界
1.1 Kubernetes 已經(jīng)是云操作系統(tǒng)
1.2 兩個清晰的容器技術(shù)趨勢
2 內(nèi)核面臨的挑戰(zhàn)
2.1 復(fù)雜度性不斷增長，性能和可擴展性新需求
2.2 永遠保持后向兼容
2.3 Feature creeping normality
3 eBPF 降世：重新定義數(shù)據(jù)平面（datapth）
4 eBPF 長什么樣，怎么用？Cilium eBPF networking 案例研究
4.1 Cilium eBPF 流程
4.2 eBPF 特點
5 溫故：kube-proxy 包轉(zhuǎn)發(fā)路徑
6 知新：Cilium eBPF 包轉(zhuǎn)發(fā)路徑
7 eBPF 年鑒
不知疲倦的增長和 eBPF 的第三個方向：Linux security modules
bpftrace
BPF 專著《BPF Performance Tools》
Cilium 1.6 發(fā)布
BPF live-patching
第一次 bpfconf：受邀請才能參加的 BPF 內(nèi)核專家會議
BPF backend 合并到 GCC
Cilium 1.0 發(fā)布
BTF（Byte Type Format）
Linux Plumbers 會議開辟 BPF/XDP 主題
新 socket 類型：AF_XDP
bpffilter
eBPF 成為內(nèi)核獨立子系統(tǒng)
kTLS & eBPF
bpftool & libbpf
BPF to BPF function calls
eBPF 開始大規(guī)模應(yīng)用于生產(chǎn)環(huán)境
eBPF 添加了一個新 fast path：XDP
Cilium 項目發(fā)布
eBPF 分成兩個方向：networking & tracing
eBPF backend 合并到 LLVM 3.7
支持將 eBPF attach 到 kprobes
通過 cls_bpf，tc 變得完全可編程
為 tc 添加了一個 lockless ingress & egress hook 點
添加了很多 verifer 和 eBPF 輔助代碼（helper）
bcc 項目發(fā)布
第一個 eBPF patch 合并到內(nèi)核
Kubernetes 提交第一個 commit
前浪工具和子系統(tǒng)
eBPF 與前浪的區(qū)別
eBPF：第一個（巨型）patch
2013
2014
2015
2016
2017
2017 ~ 2018
2018
2018 ~ 2019
2019 ~ 2020
8 eBPF：過去 50 年操作系統(tǒng)最大的變革
9 eBPF 數(shù)字榜單（截至 2020.07）
10 業(yè)界趨勢
11 eBPF 革命：燃燒到 Kubernetes 社區(qū)
網(wǎng)絡(luò)吞吐
CPU 利用率
東西向流量
南北向流量
11.1 干掉 kube-proxy/iptables
11.2 Cilium 的 Service load balancing 設(shè)計
11.3 XDP/eBPF vs kube-proxy 性能對比
12 eBPF 和 Kubernetes：未來展望
13 結(jié)束語
以下是譯文。
1 eBPF 正在吞噬世界
1.1 Kubernetes 已經(jīng)是云操作系統(tǒng)
Kubernetes 正在吞噬世界（eating the world）。越來越多的企業(yè)開始遷移到容器平臺上 ，而 Kubernetes 已經(jīng)是公認(rèn)的云操作系統(tǒng)（Cloud OS）。從技術(shù)層面來說，
Linux 內(nèi)核是一切的堅實基礎(chǔ)，例如，內(nèi)核提供了 cgroup、namespace 等特性。
Kubernetes CNI 插件串聯(lián)起了關(guān)鍵路徑（critical path）上的組件。例如，從網(wǎng)絡(luò)的 視角看，包括，
廣義的 Pod 連通性：一個容器創(chuàng)建之后，CNI 插件會給它創(chuàng)建網(wǎng)絡(luò)設(shè)備，移動到容 器的網(wǎng)絡(luò)命名空間。
IPAM：CNI 向 IPAM 發(fā)送請求，為容器分配 IP 地址，然后配置路由。
Kubernetes 的 Service 處理和負載均衡功能。
網(wǎng)絡(luò)策略的生效（network policy enforcement）。
監(jiān)控和排障。
1.2 兩個清晰的容器技術(shù)趨勢
今天我們能清晰地看到兩個技術(shù)發(fā)展趨勢：
容器的部署密度越來越高（increasing Pod density）。
容器的生命周期越來越短（decreasing Pod lifespan）。甚至短到秒級或毫秒級。
大家有興趣的可以查閱相關(guān)調(diào)查：
CNCF’19 survey report
sysdig’19 container usage report
2 內(nèi)核面臨的挑戰(zhàn)
從操作系統(tǒng)內(nèi)核的角度看，我們面臨很多挑戰(zhàn)。
2.1 復(fù)雜度性不斷增長，性能和可擴展性新需求
內(nèi)核，或者說通用內(nèi)核（general kernel），必須在子系統(tǒng)復(fù)雜度不斷增長（ increasing complexity of kernel subsystems）的前提下，滿足這些性能和可擴展性?需求（performance & scalability requirements）。
2.2 永遠保持后向兼容
Linus torvalds 的名言大家都知道：never break user space。
這對用戶來說是好事，但對內(nèi)核開發(fā)者來說意味著：我們必須保證在引入新代碼時，五年前 甚至十幾年前的老代碼仍然能正常工作。
顯然，這會使原本就復(fù)雜的內(nèi)核變得更加復(fù)雜，對于網(wǎng)絡(luò)來說，這意味著快速收發(fā)包路徑 （fast path）將受到影響。
2.3 Feature creeping normality
開發(fā)者和用戶不斷往內(nèi)核加入新功能，導(dǎo)致內(nèi)核非常復(fù)雜，現(xiàn)在已經(jīng)沒有一個人能理解所有東西了。
Wikipedia 對 creeping normality 的定義：
Def. creeping normality: … is a process by which a major change can be accepted as normal and acceptable if it happens slowly through small, often unnoticeable, increments of change. The change could otherwise be regarded as objectionable if it took place in a single step or short period.
應(yīng)用到這里，意思就是：內(nèi)核不允許一次性引入非常大的改動，只能將它們拆 分成數(shù)量眾多的小 patch，每次合并的 patch 保證系統(tǒng)后向兼容，并且對系統(tǒng)的影響非 常小。
來看 Linus torvalds 的原話：
Linus Torvalds on crazy new kernel features:
So I can work with crazy people, that’s not the problem. They just need to?sell?their crazy stuff to me using non-crazy arguments, and in small and well-defined pieces. When I ask for killer features, I want them to lull me into a safe and cozy world where the stuff they are pushing is actually useful to mainline people?first.
In other words, every new crazy feature should be hidden in a nice solid “Trojan Horse” gift: something that looks?obviously?good at first sight.
Linus Torvalds,
https://lore.kernel.org/lkml/alpine.LFD.2.00.1001251002430.3574@localhost.localdomain/
3 eBPF 降世：重新定義數(shù)據(jù)平面（datapth）
這就是我們最開始想將 eBPF 合并到內(nèi)核時遇到的問題：改動太大，功能太新（a crazy new kernel feature）。
但是，eBPF 帶來的好處也是無與倫比的。
首先，從長期看，eBPF 這項新功能會減少未來的 feature creeping normality。因為用戶或開發(fā)者希望內(nèi)核實現(xiàn)的功能，以后不需要再通過改內(nèi)核的方式來實現(xiàn)了。只需要一段 eBPF 代碼，實時動態(tài)加載到內(nèi)核就行了。
其次，因為 eBPF，內(nèi)核也不會再引入那些影響 fast path 的蹩腳甚至 hardcode 代碼 ，從而也避免了性能的下降。
第三，eBPF 還使得內(nèi)核完全可編程，安全地可編程（fully and safely programmable ），用戶編寫的 eBPF 程序不會導(dǎo)致內(nèi)核 crash。另外，eBPF 設(shè)計用來解決真實世界 中的線上問題，而且我們現(xiàn)在仍然在堅守這個初衷。
4 eBPF 長什么樣，怎么用？Cilium eBPF networking 案例研究
eBPF 程序長什么樣？如下圖所示，和 C 語言差不多，一般由用戶空間 application 或 agent 來生成。
4.1 Cilium eBPF 流程
下面我們將看看 Cilium 是如何用 eBPF 實現(xiàn)容器網(wǎng)絡(luò)方案的。
如上圖所示，幾個步驟：
Cilium agent?生成 eBPF 程序。
用 LLVM 編譯 eBPF 程序，生成 eBPF 對象文件（object file，*.o）。
用 eBPF loader?將對象文件加載到 Linux 內(nèi)核。
校驗器（verifier）對 eBPF 指令會進行合法性驗證，以確保程序是安全的，例如 ，無非法內(nèi)存訪問、不會 crash 內(nèi)核、不會有無限循環(huán)等。
對象文件被即時編譯（JIT）為能直接在底層平臺（例如 x86）運行的 native code。
如果要在內(nèi)核和用戶態(tài)之間共享狀態(tài)，BPF 程序可以使用 BPF map，這種一種共享存儲?，BPF 側(cè)和用戶側(cè)都可以訪問。
BPF 程序就緒，等待事件觸發(fā)其執(zhí)行。對于這個例子，就是有數(shù)據(jù)包到達網(wǎng)絡(luò)設(shè)備時，觸發(fā) BPF 程序的執(zhí)行。
BPF 程序?qū)κ盏降陌M行處理，例如 mangle。最后返回一個裁決（verdict）結(jié)果。
根據(jù)裁決結(jié)果，如果是 DROP，這個包將被丟棄；如果是 PASS，包會被送到更網(wǎng)絡(luò)棧的 更上層繼續(xù)處理；如果是重定向，就發(fā)送給其他設(shè)備。
4.2 eBPF 特點
最重要的一點：不能 crash 內(nèi)核。
執(zhí)行起來，與內(nèi)核模塊（kernel module）一樣快。
提供穩(wěn)定的 API。
這意味著什么？簡單來說，如果一段 BPF 程序能在老內(nèi)核上執(zhí)行，那它一定也能繼續(xù)在新 內(nèi)核上執(zhí)行，而無需做任何修改。
這就像是內(nèi)核空間與用戶空間的契約，內(nèi)核保證對用戶空間應(yīng)用的兼容性，類似地，內(nèi)核也 會保證 eBPF 程序的兼容性。
5 溫故：kube-proxy 包轉(zhuǎn)發(fā)路徑
從網(wǎng)絡(luò)角度看，使用傳統(tǒng)的 kube-proxy 處理 Kubernetes Service 時，包在內(nèi)核中的 轉(zhuǎn)發(fā)路徑是怎樣的？如下圖所示：
步驟：
網(wǎng)卡收到一個包（通過 DMA 放到 ring-buffer）。
包經(jīng)過 XDP hook 點。
內(nèi)核給包分配內(nèi)存，此時才有了大家熟悉的?skb（包的內(nèi)核結(jié)構(gòu)體表示），然后 送到內(nèi)核協(xié)議棧。
包經(jīng)過 GRO 處理，對分片包進行重組。
包進入 tc（traffic control）的 ingress hook。接下來，所有橙色的框都是 Netfilter 處理點。
Netfilter：在?PREROUTING?hook 點處理?raw?table 里的 iptables 規(guī)則。
包經(jīng)過內(nèi)核的連接跟蹤（conntrack）模塊。
Netfilter：在?PREROUTING?hook 點處理?mangle?table 的 iptables 規(guī)則。
Netfilter：在?PREROUTING?hook 點處理?nat?table 的 iptables 規(guī)則。
進行路由判斷（FIB：Forwarding Information Base，路由條目的內(nèi)核表示，譯者注） 。接下來又是四個 Netfilter 處理點。
Netfilter：在?FORWARD?hook 點處理?mangle?table 里的 iptables 規(guī)則。
Netfilter：在?FORWARD?hook 點處理?filter?table 里的 iptables 規(guī)則。
Netfilter：在?POSTROUTING?hook 點處理?mangle?table 里的 iptables 規(guī)則。
Netfilter：在?POSTROUTING?hook 點處理?nat?table 里的 iptables 規(guī)則。
包到達 TC egress hook 點，會進行出方向（egress）的判斷，例如判斷這個包是到本 地設(shè)備，還是到主機外。
對大包進行分片。根據(jù) step 15 判斷的結(jié)果，這個包接下來可能會：
發(fā)送到一個本機 veth 設(shè)備，或者一個本機 service endpoint，
或者，如果目的 IP 是主機外，就通過網(wǎng)卡發(fā)出去。
相關(guān)閱讀，有助于理解以上過程：
Cracking Kubernetes Node Proxy (aka kube-proxy)
(譯) 深入理解 iptables 和 netfilter 架構(gòu)
連接跟蹤（conntrack）：原理、應(yīng)用及 Linux 內(nèi)核實現(xiàn)
(譯) 深入理解 Cilium 的 eBPF 收發(fā)包路徑（datapath）
譯者注。
6 知新：Cilium eBPF 包轉(zhuǎn)發(fā)路徑
作為對比，再來看下 Cilium eBPF 中的包轉(zhuǎn)發(fā)路徑：
建議和?(譯) 深入理解 Cilium 的 eBPF 收發(fā)包路徑（datapath）?對照看。
譯者注。
對比可以看出，Cilium eBPF datapath 做了短路處理：從 tc ingress 直接 shortcut 到 tc egress，節(jié)省了 9 個中間步驟（總共 17 個）。更重要的是：這個 datapath 繞過了 整個 Netfilter 框架（橘黃色的框們），Netfilter 在大流量情況下性能是很差的。
去掉那些不用的框之后，Cilium eBPF datapath 長這樣：
Cilium/eBPF 還能走的更遠。例如，如果包的目的端是另一臺主機上的 service endpoint，那你可以直接在 XDP 框中完成包的重定向（收包?1->2，在步驟?2?中對包 進行修改，再通過?2->1?發(fā)送出去），將其發(fā)送出去，如下圖所示：
可以看到，這種情況下包都沒有進入內(nèi)核協(xié)議棧（準(zhǔn)確地說，都沒有創(chuàng)建 skb）就被轉(zhuǎn) 發(fā)出去了，性能可想而知。
XDP 是 eXpress DataPath 的縮寫，支持在網(wǎng)卡驅(qū)動中運行 eBPF 代碼，而無需將包送 到復(fù)雜的協(xié)議棧進行處理，因此處理代價很小，速度極快。
7 eBPF 年鑒
eBPF 是如何誕生的呢？我最初開始講起。這里“最初”我指的是 2013 年之前。
2013
前浪工具和子系統(tǒng)
回顧一下當(dāng)時的 “SDN” 藍圖。
當(dāng)時有 OpenvSwitch（OVS）、tc（Traffic control），以及內(nèi)核中的 Netfilter 子系 統(tǒng)（包括?iptables、ipvs、nftalbes?工具），可以用這些工具對 datapath 進行“ 編程”：。
BPF 當(dāng)時用于?tcpdump，在內(nèi)核中盡量前面的位置抓包，它不會 crash 內(nèi)核；此 外，它還用于 seccomp，對系統(tǒng)調(diào)用進行過濾（system call filtering），但當(dāng)時 使用的非常受限，遠不是今天我們已經(jīng)在用的樣子。
此外就是前面提到的 feature creeping 問題，以及?tc 和 netfilter 的代碼重復(fù)問題，因為這兩個子系統(tǒng)是競爭關(guān)系。
OVS 當(dāng)時被認(rèn)為是內(nèi)核中最先進的數(shù)據(jù)平面，但它最大的問題是：與內(nèi)核中其他網(wǎng) 絡(luò)模塊的集成不好【譯者注 1】。此外，很多核心的內(nèi)核開發(fā)者也比較抵觸 OVS，覺得它很怪。
【譯者注 1】
例如，OVS 的 internal port、patch port 用 tcpdump 都是?抓不到包的，排障非常不方便。
eBPF 與前浪的區(qū)別
對比 eBPF 和這些已經(jīng)存在很多年的工具：
tc、OVS、netfilter 可以對 datapath 進行“編程”：但前提是 datapath 知道你想做什 么（but only if the datapath knows what you want to do）。
只能利用這些工具或模塊提供的既有功能。
eBPF 能夠讓你創(chuàng)建新的 datapath（eBPF lets you create the datapath instead）。
eBPF 就是內(nèi)核本身的代碼，想象空間無限，并且熱加載到內(nèi)核；換句話說，一旦加 載到內(nèi)核，內(nèi)核的行為就變了。
在 eBPF 之前，改變內(nèi)核行為這件事情，只能通過修改內(nèi)核再重新編譯，或者開發(fā)內(nèi) 核模塊才能實現(xiàn)。
譯者注
eBPF：第一個（巨型）patch
描述 eBPF 的 RFC 引起了廣泛討論，但普遍認(rèn)為侵入性太強了（改動太大）。
另外，當(dāng)時 nftables (inspired by BPF) 正在上升期，它是一個與 eBPF 有點類似的 BPF 解釋器，大家不想同時維護兩個解釋器。
最終這個 patch 被拒絕了。
被拒的另外一個原因是前面提到的，沒有遵循“大改動小提交”原則，全部代碼放到了一個 patch。Linus 會瘋的。
2014
第一個 eBPF patch 合并到內(nèi)核
用一個擴展（extended）指令集逐步、全面替換原來老的 BPF 解釋器。
自動新老 BPF 轉(zhuǎn)換：in-kernel translation。
后續(xù) patch 將 eBPF 暴露給 UAPI，并添加了 verifier 代碼和 JIT 代碼。
更多后續(xù) patch，從核心代碼中移除老的 BPF。
我們也從那時開始，順理成章地成為了 eBPF 的 maintainer。
Kubernetes 提交第一個 commit
巧合的是，對后來影響深遠的 Kubernetes，也在這一年提交了第一個 commit：
2015
eBPF 分成兩個方向：networking & tracing
到了 2015 年，eBPF 開發(fā)分成了兩個方向：
networking
tracing
eBPF backend 合并到 LLVM 3.7
這一年的一個重要里程碑是 eBPF backend 合并到了 upstream LLVM 編譯器套件，因此你 現(xiàn)在才能用 clang 編譯 eBPF 代碼。
支持將 eBPF attach 到 kprobes
這是 tracing 的第一個使用案例。
Alexei 主要負責(zé) tracing 部分，他添加了一個 patch，支持加載 eBPF 用來做 tracing， 能獲取系統(tǒng)的觀測數(shù)據(jù)。
通過 cls_bpf，tc 變得完全可編程
我主要負責(zé) networking 部分，使 tc 子系統(tǒng)可編程，這樣我們就能用 eBPF 來靈活的對 datapath 進行編程，獲得一個高性能 datapath。
為 tc 添加了一個 lockless ingress & egress hook 點
譯注：可參考：
深入理解 tc ebpf 的 direct-action (da) 模式（2020）
為容器時代設(shè)計的高級 eBPF 內(nèi)核特性（FOSDEM, 2021）
添加了很多 verifer 和 eBPF 輔助代碼（helper）
使用更方便。
bcc 項目發(fā)布
作為 tracing frontend for eBPF。
2016
eBPF 添加了一個新 fast path：XDP
XDP 合并到內(nèi)核，支持在驅(qū)動的 ingress 層 attach BPF 程序。
nfp 最為第一家網(wǎng)卡及驅(qū)動，支持將 eBPF 程序 offload 到 cls_bpf & XDP hook 點。
Cilium 項目發(fā)布
Cilium 最開始的目標(biāo)是?docker 網(wǎng)絡(luò)解決方案。
通過 eBPF 實現(xiàn)高效的 label-based policy、NAT64、tunnel mesh、容器連通性。
整個 datapath & forwarding 邏輯全用 eBPF 實現(xiàn)，不再需要 Docker 或 OVS 橋接設(shè)備。
2017
eBPF 開始大規(guī)模應(yīng)用于生產(chǎn)環(huán)境
2016 ~ 2017 年，eBPF 開始應(yīng)用于生產(chǎn)環(huán)境：
Netflix on eBPF for tracing: ‘Linux BPF superpowers’
Facebook 公布了生產(chǎn)環(huán)境 XDP+eBPF 使用案例（DDoS & LB）
用 XDP/eBPF 重寫了原來基于 IPVS 的 L4LB，性能?10x。
eBPF 經(jīng)受住了嚴(yán)苛的考驗：從 2017 開始，每個進入 facebook.com 的包，都是經(jīng)過了 XDP & eBPF 處理的。
Cloudflare 將 XDP+BPF 集成到了它們的 DDoS mitigation 產(chǎn)品。
成功將其組件從基于 Netfilter 遷移到基于 eBPF。
到 2018 年，它們的 XDP L4LB 完全接管生產(chǎn)環(huán)境。
擴展閱讀：(譯) Cloudflare 邊緣網(wǎng)絡(luò)架構(gòu)：無處不在的 BPF（2019）
譯者注：基于 XDP/eBPF 的 L4LB 原理都是類似的，簡單來說，
通過 BGP 宣告 VIP
通過 ECMP 做物理鏈路高可用
通過 XDP/eBPF 代碼做重定向，將請求轉(zhuǎn)發(fā)到后端（VIP -> Backend）
eBPF patch 合并到?bpf?&?bpf-next?kernel trees on git.kernel.org
拆分 eBPF 郵件列表：bpf@vger.kernel.org?(archive at:?lore.kernel.org/bpf/)
eBPF PR 經(jīng)內(nèi)核網(wǎng)絡(luò)部分的 maintainer David S. Miller 提交給 Linus Torvalds
K8s CNI
Identity-based L3-L7 policy
ClusterIP Services
DPDK 需要重寫網(wǎng)卡驅(qū)動，需要額外維護用戶空間的驅(qū)動代碼。
AF_XDP?在復(fù)用內(nèi)核網(wǎng)卡驅(qū)動的情況下，能達到與 DPDK 一樣的性能。
Google 貢獻了 BPF LSM（安全），部署在了他們的數(shù)據(jù)中心服務(wù)器上。
BPF verifier 防護 Spectre 漏洞（2018 年轟動世界的 CPU bug）：even verifying safety on speculative program paths。
主流云廠商開始通過 SRIOV 支持 XDP：AWS (ena driver), Azure (hv_netvsc driver), …
Cilium 1.8 支持基于 XDP 的 Service 負載均衡和 host network policies。
Facebook 開發(fā)了基于 BPF 的 TCP 擁塞控制模塊。
Microsoft 基于 BPF 重寫了將他們的 Windows monitoring 工具。
347 個貢獻者，貢獻了 4,935 個 patch 到 BPF 子系統(tǒng)。
BPF 內(nèi)核郵件列表日均 50 封郵件 (高峰經(jīng)常超過日均 100)。
23,395 mails since mailing list git archive was added in Feb 2019
每天合并 4 個新 patch。patch 接受率 30% 左右。
30 個程序（different program），27 種 BPF map 類型，141 個 BPF helpers，超過 3,500 個測試。
2 個 BPF kernel maintainers & team of 6 senior core reviewers。
主要貢獻來自：Isovalent（Cilium）, Facebook and Google
Facebook：L4LB、DDoS、tracing。
Netflix：BPF 重度用戶，例如生產(chǎn)環(huán)境 tracing。
Google：Android、服務(wù)器安全以及其他很多方面。
Cloudflare：L4LB、DDoS。
Cilium
在 socket 層運行的 BPF 程序
在 XDP 和 tc 層運行的 BPF 程序
將 Service 的?IP:Port?映射到具體的 backend pods，并做負載均衡。
當(dāng)應(yīng)用發(fā)起?connect、sendmsg、recvmsg 等請求（系統(tǒng)調(diào)用）時，攔截這些請求， 并根據(jù)請求的?IP:Port?映射到后端 pod，直接發(fā)送過去。反向進行相反的變換。
不需要包級別（packet leve）的地址轉(zhuǎn)換（NAT）。在系統(tǒng)調(diào)用時，還沒有創(chuàng)建包，因此性能更高。
省去了 kube-proxy 路徑中的很多中間節(jié)點（intermediate node hops）
將東西向流量放在離 socket 層盡量近的地方做。
將南北向流量放在離驅(qū)動（XDP 和 tc）層盡量近的地方做。
Cilium XDP eBPF 模式能處理接收到的全部 10Mpps（packets per second）。
Cilium tc eBPF 模式能處理 3.5Mpps。
kube-proxy iptables 只能處理 2.3Mpps，因為它的 hook 點在收發(fā)包路徑上更后面的位置。
kube-proxy ipvs 模式這里表現(xiàn)更差，它相比 iptables 的優(yōu)勢要在 backend 數(shù)量很多的時候才能體現(xiàn)出來。
XDP 性能最好，是因為?XDP BPF 在驅(qū)動層執(zhí)行，不需要將包 push 到內(nèi)核協(xié)議棧。
kube-proxy 不管是 iptables 還是 ipvs 模式，都在處理軟中斷（softirq）上消耗了大量 CPU。
設(shè)想在將來，Linux 只會保留一個非常小的核心內(nèi)核（tiny core kernel），其他所有 內(nèi)核功能都由用戶定義，并用 BPF 實現(xiàn)（而不再是開發(fā)內(nèi)核模塊的方式）。
這樣可以減少受攻擊面，因為此時的核心內(nèi)核非常小；另外，所有 BPF 代碼都會經(jīng)過 verifer 校驗。
極大減少 ‘static’ feature creep，資源（例如 CPU）可以用在更有意義的地方。
設(shè)想一下，未來 Kubernetes 可能會內(nèi)置 custom BPF-tailored extensions，能根據(jù)用戶的應(yīng)用自動適配（optimize needs for user workloads）；例如，判斷 pod 是跑在數(shù)據(jù)中心，還是在嵌入式系統(tǒng)上。
Try it out：https://cilium.link/kubeproxy-free
Contribute：https://github.com/cilium/cilium
對此感興趣可參考入門級介紹：L4LB for Kubernetes: Theory and Practice with Cilium+BGP+ECMP
2017 ~ 2018
eBPF 成為內(nèi)核獨立子系統(tǒng)
隨著 eBPF 社區(qū)的發(fā)展，feature 和 patch 越來越多，為了管理這些 patch，Alexei、我和 networking 的一位 maintainer David Miller 經(jīng)過討論，決定將 eBPF 作為獨立的內(nèi)核子 系統(tǒng)。
kTLS & eBPF
kTLS & eBPF for introspection and ability for in-kernel TLS policy enforcement
kTLS 是將 TLS 處理 offload 到內(nèi)核，例如，將加解密過程從 openssl 下放到內(nèi)核進 行，以使得內(nèi)核具備更強的可觀測性（gain visibility）。
有了 kTLS，就可以用 eBPF 查看數(shù)據(jù)和狀態(tài)，在內(nèi)核應(yīng)用安全策略。?目前 openssl 已經(jīng)完全原生支持這個功能。
bpftool & libbpf
為了檢查內(nèi)核內(nèi) eBPF 的狀態(tài)（introspection）、查看內(nèi)核加載了哪些 BPF 程序等， 我們添加了一個新工具 bpftool。現(xiàn)在這個工具已經(jīng)功能非常強大了。
同樣，為了方便用戶空間應(yīng)用使用 eBPF，我們提供了用戶空間 API（user space API for applications）?libbpf。這是一個 C 庫，接管了所有加載工作，這樣用戶就不需要 自己處理復(fù)雜的加載過程了。
BPF to BPF function calls
增加了一個 BPF 函數(shù)調(diào)用另一個 BPF 函數(shù)的支持，使得 BPF 程序的編寫更加靈活。
2018
Cilium 1.0 發(fā)布
這標(biāo)志著?BPF 革命之火燃燒到了 Kubernetes networking & security 領(lǐng)域。
Cilium 此時支持的功能：
BTF（Byte Type Format）
內(nèi)核添加了一個稱為 BTF 的組件。這是一種元數(shù)據(jù)格式，和 DWARF 這樣的 debugging data 類似。但 BTF 的 size 要小的多，而更重要的是，有史以來，內(nèi)核第一次變得可自 描述了（self-descriptive）。什么意思？
想象一下當(dāng)前正在運行中的內(nèi)核，它內(nèi)置了自己的數(shù)據(jù)格式（its own data format） 和內(nèi)部數(shù)據(jù)結(jié)構(gòu)（internal structures），你能用工具來查看這些東西（you can introspect them）。還是不太懂？這么說吧，BTF 是后來的 “一次編譯、到處運行”、 熱補丁（live-patching）、BPF global data 處理等等所有這些 BPF 特性的基礎(chǔ)。
新的特性不斷加入，它們都依賴 BTF 提供富元數(shù)據(jù)（rich metadata）這個基礎(chǔ)。
更多 BTF 內(nèi)容，可參考?(譯) Cilium：BPF 和 XDP 參考指南（2019）
譯者注
Linux Plumbers 會議開辟 BPF/XDP 主題
這一年，Linux Plumbers 會議第一次開辟了專門討論 BPF/XDP 的微型分會，我們 一起組織這場會議。其中，Networking Track 一半以上的議題都涉及 BPF 和 XDP 主題，因為這是一個非常振奮人心的特性，越來越多的人用它來解決實際問題。
新 socket 類型：AF_XDP
內(nèi)核添加了一個新 socket 類型?AF_XDP。它提供的能力是：在零拷貝（ zero-copy）的前提下將包從網(wǎng)卡驅(qū)動送到用戶空間。
回憶前面的內(nèi)容，數(shù)據(jù)包到達網(wǎng)卡后，先經(jīng)過 XDP，然后才為這個包分配內(nèi)存。因此在 XDP 層直接將包送到用戶態(tài)是無需拷貝的。
譯者注
AF_XDP?提供的能力與 DPDK 有點類似，不過
而且由于復(fù)用了內(nèi)核基礎(chǔ)設(shè)施，所有的網(wǎng)絡(luò)管理工具還都是可以用的，因此非常方便， 而 DPDK 這種 bypass 內(nèi)核的方案導(dǎo)致絕大大部分現(xiàn)有工具都用不了了。
由于所有這些操作都是發(fā)生在 XDP 層的，因此它稱為?AF_XDP。插入到這里的 BPF 代碼 能直接將包送到 socket。
bpffilter
開始了 bpffilter prototype，作用是通過用戶空間驅(qū)動（userspace driver），將 iptables 規(guī)則轉(zhuǎn)換成 eBPF 代碼。
這是將 iptables 轉(zhuǎn)換成 eBPF 的第一次嘗試，整個過程對用戶都是無感知的，其中的某些 組件現(xiàn)在還在用，用于在其他方面擴展內(nèi)核的功能。
2018 ~ 2019
bpftrace
Brendan 發(fā)布了 bpftrace 工具，作為 DTrace 2.0 for Linux。
BPF 專著《BPF Performance Tools》
Berendan 寫了一本 800 多頁的 BPF 書。
Cilium 1.6 發(fā)布
第一次支持完全干掉基于 iptables 的 kube-proxy，全部功能基于 eBPF。
這個版本其實是有問題的，例如 1.6 發(fā)布之后我們發(fā)現(xiàn) externalIPs 的實現(xiàn)是有問題 ，社區(qū)在后面的版本修復(fù)了這個問題。在修復(fù)之前，還是得用 kube-proxy：https://github.com/cilium/cilium/issues/9285
譯者注
BPF live-patching
添加了一些內(nèi)核新特性，例如尾調(diào)用（tail call），這使得?eBPF 核心基礎(chǔ) 設(shè)施第一次實現(xiàn)了熱加載。這個功能幫我們極大地優(yōu)化了 datapath。
另一個重要功能是 BPF trampolines，這里就不展開了，感興趣的可以搜索相關(guān)資料，我只 能說這是另一個振奮人心的技術(shù)。
第一次 bpfconf：受邀請才能參加的 BPF 內(nèi)核專家會議
如題，這是 BPF 內(nèi)核專家交換想法和討論問題的會議。與 Linux Plumbers 會議互補。
BPF backend 合并到 GCC
前面提到，BPF backend 很早就合并到 LLVM/Clang，現(xiàn)在，它終于合并到 GCC 了。至此，GCC 和 LLVM 這兩個最主要的編譯器套件都支持了 BPF backend。
此外，BPF 開始支持有限循環(huán)（bounded loops），在此之前，是不支持循環(huán)的，以防止程 序無限執(zhí)行。
2019 ~ 2020
不知疲倦的增長和 eBPF 的第三個方向：Linux security modules
8 eBPF：過去 50 年操作系統(tǒng)最大的變革
Brendan 說在他的職業(yè)生涯中，eBPF 是他見過的操作系統(tǒng)中最大的變革之一（one of the biggest operating system changes），他為能身處其中而感到非常興奮。
我接下來只能用數(shù)字證明：Brendan 的興奮是沒錯的。
9 eBPF 數(shù)字榜單（截至 2020.07）
eBPF 內(nèi)核社區(qū)截至 7 月份的一些數(shù)據(jù)：
毫無疑問，這是內(nèi)核里發(fā)展最快的子系統(tǒng)！
10 業(yè)界趨勢
注意貢獻榜排名第一的就是演講者本人，譯者注。
列舉幾個生產(chǎn)環(huán)境大規(guī)模使用 BPF 的大廠：
上圖中，右下角是前 Netfilter 維護者?Rusty Russel 說的一句，業(yè)界對 eBPF 的受認(rèn)可程度可窺一斑。
11 eBPF 革命：燃燒到 Kubernetes 社區(qū)
eBPF 已無處不在，而你還在使用 iptables？
11.1 干掉 kube-proxy/iptables
不用再忍受 iptables 復(fù)雜冗長的規(guī)則和差勁的性能了，以前沒得選，現(xiàn)在你可以做個好人：
$ kubectl -n kube-system delete ds kube-proxy作為例子，我們來看看 Cilium 是怎么做 Service 的負載均衡的。
Service 細節(jié)實現(xiàn)可參考 Cracking Kubernetes Node Proxy (aka kube-proxy)。
譯者注。
11.2 Cilium 的 Service load balancing 設(shè)計
如上圖所示，主要涉及兩部分：
東西向流量
我們先來看 socker 層。
如上圖所示，
Socket 層的 BPF 程序主要處理 Cilium 節(jié)點的東西向流量（E-W）。
這里實現(xiàn)的好處：性能更高。
可以看出，應(yīng)用對這種攔截和重定向是無感知的（符合 k8s Service 的設(shè)計）。
南北向流量
再來看從 k8s 集群外進入節(jié)點，或者從節(jié)點出 k8s 集群的流量（external traffic）， 即南北向流量（N-S）：
區(qū)分集群外流量的一個原因是：Pod IP 很多情況下都是不可路由的（與跨主機選用的網(wǎng) 絡(luò)方案有關(guān)），只在集群內(nèi)有效，即，集群外訪問 Pod IP 是不通的。
因此，如果 Pod 流量直接從 node 出宿主機，必須確保它能正常回來。而 node IP 一般都是全局可達的，集群外也可以訪問，所以常見的解決方案就是：在 Pod 通過 node 出集群時，對其進行 SNAT，將源 IP 地址換成 node IP 地址；應(yīng)答包回來時，再進行相 反的 DNAT，這樣包就能回到 Pod 了。
譯者注
如上圖所示，集群外來的流量到達 node 時，由?XDP 和 tc 層的 BPF 程序進行處理， 它們做的事情與 socket 層的差不多，將 Service 的?IP:Port?映射到后端的?PodIP:Port，如果 backend pod 不在本 node，就通過網(wǎng)絡(luò)再發(fā)出去。發(fā)出去的流程我們 在前面?Cilium eBPF 包轉(zhuǎn)發(fā)路徑?講過了。
這里 BPF 做的事情：執(zhí)行 DNAT。這個功能可以在 XDP 層做，也可以在 TC 層做，但 在 XDP 層代價更小，性能也更高。
總結(jié)起來，這里的核心理念就是：
11.3 XDP/eBPF vs kube-proxy 性能對比
網(wǎng)絡(luò)吞吐
測試環(huán)境：兩臺物理節(jié)點，一個發(fā)包，一個收包，收到的包做 Service loadbalancing 轉(zhuǎn)發(fā)給后端 Pods。
可以看出：
CPU 利用率
我們生成了 1Mpps、2Mpps 和 4Mpps 流量，空閑 CPU 占比（可以被應(yīng)用使用的 CPU）結(jié)果如下：
結(jié)論與上面吞吐類似。
12 eBPF 和 Kubernetes：未來展望
“The Linux kernel continues its march towards becoming BPF runtime-powered microkernel.”
“Linux 內(nèi)核繼續(xù)朝著成為 BPF runtime-powered microkernel 而前進”。這是一個非 常有趣的思考角度。
BPF will replace Linux.
我們的目標(biāo)是星辰大海，與此相比，kube-proxy replacement 只是最微不足道的開端。
13 結(jié)束語
????????????????
- END -
看完一鍵三連在看，轉(zhuǎn)發(fā)，點贊
是對文章最大的贊賞，極客重生感謝你
推薦閱讀
Linux網(wǎng)絡(luò)新技術(shù)基石 |eBPF and XDP
圖解Linux 內(nèi)核TCP/IP 協(xié)議棧實現(xiàn)|Linux網(wǎng)絡(luò)硬核系列
Linux I/O 原理和 Zero-copy 技術(shù)全面揭秘
總結(jié)
以上是生活随笔為你收集整理的大规模微服务利器：eBPF + Kubernetes的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 高考结束了
- 下一篇： 一文带你理解云原生|云原生全景指南