2020年9月，UCloud 優(yōu)刻得上線了Serverless容器產(chǎn)品Cube，它具備了虛擬機(jī)級(jí)別的安全隔離、輕量化的系統(tǒng)占用、秒級(jí)的啟動(dòng)速度，高度自動(dòng)化的彈性伸縮，以及簡(jiǎn)潔明了的易用性。結(jié)合虛擬節(jié)點(diǎn)技術(shù)（Virtual Kubelet），Cube可以和UCloud 優(yōu)刻得容器托管產(chǎn)品UK8S無(wú)縫對(duì)接，極大地豐富了Kubernetes集群的彈性能力。如下圖所示，Virtual Node作為一個(gè)虛擬Node在Kubernetes集群中，每個(gè)Cube實(shí)例被視為VK節(jié)點(diǎn)上的一個(gè)Pod。

然而，Virtual Kubelet僅僅實(shí)現(xiàn)了集群中Cube實(shí)例的彈性伸縮。要使得Cube實(shí)例正式成為K8s集群大家庭的一員，運(yùn)行在Cube中的應(yīng)用需要能利用K8s的服務(wù)發(fā)現(xiàn)能力，即訪問(wèn)Service地址。

為什么不是kube-proxy？

眾所周知, kube-proxy為K8s實(shí)現(xiàn)了service流量負(fù)載均衡。kube-proxy不斷感知K8s內(nèi)Service和Endpoints地址的對(duì)應(yīng)關(guān)系及其變化，生成ServiceIP的流量轉(zhuǎn)發(fā)規(guī)則。它提供了三種轉(zhuǎn)發(fā)實(shí)現(xiàn)機(jī)制：userspace, iptables和ipvs, 其中userspace由于較高的性能代價(jià)已不再被使用。

然而，我們發(fā)現(xiàn)，直接把kube-proxy部署在Cube虛擬機(jī)內(nèi)部并不合適，有如下原因：

1 、kube-proxy采用go語(yǔ)言開發(fā)，編譯產(chǎn)生的目標(biāo)文件體積龐大。以K8s v1.19.5 linux環(huán)境為例，經(jīng)strip過(guò)的kube-proxy ELF可執(zhí)行文件大小為37MB。對(duì)于普通K8s環(huán)境來(lái)說(shuō)，這個(gè)體積可以忽略不計(jì)；但對(duì)于Serverless產(chǎn)品來(lái)說(shuō)，為了保證秒起輕量級(jí)虛擬機(jī)，虛擬機(jī)操作系統(tǒng)和鏡像需要高度裁剪，寸土寸金，我們想要一個(gè)部署體積不超過(guò)10MB的proxy控制程序。

2 、kube-proxy的運(yùn)行性能問(wèn)題。同樣由于使用go語(yǔ)言開發(fā)，相對(duì)于C/C++和Rust等無(wú)gc、具備精細(xì)控制底層資源能力的高級(jí)語(yǔ)言來(lái)說(shuō)，要付出更多的性能代價(jià)。Cube通常存在較細(xì)粒度的資源交付配額，例如0.5C 500MiB，我們不希望kube-proxy這類輔助組件喧賓奪主。

3 、ipvs的問(wèn)題。在eBPF被廣為周知之前，ipvs被認(rèn)為是最合理的K8s service轉(zhuǎn)發(fā)面實(shí)現(xiàn)。iptables因?yàn)閿U(kuò)展性問(wèn)題被鞭尸已久，ipvs卻能隨著services和endpoints規(guī)模增大依然保持穩(wěn)定的轉(zhuǎn)發(fā)能力和較低的規(guī)則刷新間隔。

但事實(shí)是，ipvs并不完美，甚至存在嚴(yán)重的問(wèn)題。

例如，同樣實(shí)現(xiàn)nat , iptables是在PREROUTING或者OUTPUT完成DNAT；而ipvs需要經(jīng)歷INPUT和OUTPUT，鏈路更長(zhǎng)。因此，較少svc和ep數(shù)量下的service ip壓測(cè)場(chǎng)景下，無(wú)論是帶寬還是短連接請(qǐng)求延遲，ipvs都會(huì)獲得全場(chǎng)最低分。此外，conn_reuse_mode的參數(shù)為1導(dǎo)致的滾動(dòng)發(fā)布時(shí)服務(wù)訪問(wèn)失敗的問(wèn)題至今（2021年4月）也解決的不太干凈。

4 、iptables的問(wèn)題。擴(kuò)展差，更新慢，O(n)時(shí)間復(fù)雜度的規(guī)則查找（這幾句話背不出來(lái)是找不到一份K8s相關(guān)的工作的）， 同樣的問(wèn)題還會(huì)出現(xiàn)在基于iptables實(shí)現(xiàn)的NetworkPolicy上。1.6.2以下iptables甚至不支持full_random端口選擇，導(dǎo)致SNAT的性能在高并發(fā)短連接的業(yè)務(wù)場(chǎng)景下雪上加霜。

eBPF能為容器網(wǎng)絡(luò)帶來(lái)什么？

eBPF近年來(lái)被視為linux的革命性技術(shù)，它允許開發(fā)者在linux的內(nèi)核里動(dòng)態(tài)實(shí)時(shí)地加載運(yùn)行自己編寫的沙盒程序，無(wú)需更改內(nèi)核源碼或者加載內(nèi)核模塊。同時(shí)，用戶態(tài)的程序可以通過(guò)bpf(2)系統(tǒng)調(diào)用和bpf map結(jié)構(gòu)與內(nèi)核中的eBPF程序?qū)崟r(shí)交換數(shù)據(jù)，如下圖所示。

編寫好的eBPF程序在內(nèi)核中以事件觸發(fā)的模式運(yùn)行，這些事件可以是系統(tǒng)調(diào)用入出口，網(wǎng)絡(luò)收發(fā)包的關(guān)鍵路徑點(diǎn)(xdp, tc, qdisc, socket)，內(nèi)核函數(shù)入出口kprobes/kretprobes和用戶態(tài)函數(shù)入出口uprobes/uretprobes等。加載到網(wǎng)絡(luò)收發(fā)路徑的hook點(diǎn)的eBPF程序通常用于控制和修改網(wǎng)絡(luò)報(bào)文， 來(lái)實(shí)現(xiàn)負(fù)載均衡，安全策略和監(jiān)控觀測(cè)。

cilium的出現(xiàn)使得eBPF正式進(jìn)入K8s的視野，并正在深刻地改變k8s的網(wǎng)絡(luò)，安全，負(fù)載均衡，可觀測(cè)性等領(lǐng)域。 從1.6開始，cilium可以100%替換kube-proxy，真正通過(guò)eBPF實(shí)現(xiàn)了kube-proxy的全部轉(zhuǎn)發(fā)功能。 讓我們首先考察一下ClusterIP(東西流量)的實(shí)現(xiàn)。

ClusterIP的實(shí)現(xiàn)

無(wú)論對(duì)于TCP還是UDP來(lái)說(shuō)，客戶端訪問(wèn)ClusterIP只需要實(shí)現(xiàn)針對(duì)ClusterIP的DNAT，把Frontend與對(duì)應(yīng)的Backends地址記錄在eBPF map中，這個(gè)表的內(nèi)容即為后面執(zhí)行DNAT的依據(jù)。那這個(gè)DNAT在什么環(huán)節(jié)實(shí)現(xiàn)呢？

對(duì)于一般環(huán)境，DNAT操作可以發(fā)生在tc egress，同時(shí)在tc ingress

中對(duì)回程的流量進(jìn)行反向操作，即將源地址由真實(shí)的PodIP改成ClusterIP, 此外完成NAT后需要重新計(jì)算IP和TCP頭部的checksum。

如果是支持cgroup2的linux環(huán)境，使用cgroup2的sockaddr hook點(diǎn)進(jìn)行DNAT。cgroup2為一些需要引用L4地址的socket系統(tǒng)調(diào)用，如connect(2), sendmsg(2), recvmsg(2)提供了一個(gè)BPF攔截層（BPF_PROG_TYPE_CGROUP_SOCK_ADDR）。這些BPF程序可以在packet生成之前完成對(duì)目的地址的修改，如下圖所示。

對(duì)于tcp和有連接的udp的流量（即針對(duì)udp fd調(diào)用過(guò)connect(2)）來(lái)說(shuō), 只需要做一次正向轉(zhuǎn)換，即利用bpf程序，將出向流量的目的地址改成Pod的地址。這種場(chǎng)景下，負(fù)載均衡是最高效的，因?yàn)殚_銷一次性的，作用效果則持續(xù)貫穿整個(gè)通信流的生命周期。

而對(duì)于無(wú)連接的udp流量，還需要做一次反向轉(zhuǎn)換，即將來(lái)自Pod的入向流量做一個(gè)SNAT，將源地址改回ClusterIP。如果缺了這一步操作，基于recvmsg的UDP應(yīng)用會(huì)無(wú)法收到來(lái)自ClusterIP的消息，因?yàn)閟ocket的對(duì)端地址被改寫成了Pod的地址。流量示意圖如下所示。

綜述，這是一種用戶無(wú)感知的地址轉(zhuǎn)換。用戶認(rèn)為自己連接的地址是Service, 但實(shí)際的tcp連接直接指向Pod。一個(gè)能說(shuō)明問(wèn)題的對(duì)比是，當(dāng)你使用kube-proxy的時(shí)候，在Pod中進(jìn)行tcpdump時(shí)，你能發(fā)現(xiàn)目的地址依然是ClusterIP，因?yàn)閕pvs或者iptables規(guī)則在host上；當(dāng)你使用cilium時(shí)，在Pod中進(jìn)行tcpdump，你已經(jīng)能發(fā)現(xiàn)目的地址是Backend Pod。NAT不需要借助conntrack就能完成，相對(duì)于ipvs和iptables來(lái)說(shuō)，轉(zhuǎn)發(fā)路徑減少，性能更優(yōu)。而對(duì)比剛才提到的tc-bpf，它更輕量，無(wú)需重新計(jì)算checksum。

Cube的Service服務(wù)發(fā)現(xiàn)

Cube為每個(gè)需要開啟ClusterIP訪問(wèn)功能的Serverless容器組啟動(dòng)了一個(gè)叫cproxy的agent程序來(lái)實(shí)現(xiàn)kube-proxy的核心功能。由于Cube的輕量級(jí)虛擬機(jī)鏡像使用較高版本的linux內(nèi)核，cproxy采用了上述cgroup2 socket hook的方式進(jìn)行ClusterIP轉(zhuǎn)發(fā)。cproxy使用Rust開發(fā)，編譯后的目標(biāo)文件只有不到10MiB。運(yùn)行開銷相比kube-proxy也有不小優(yōu)勢(shì)。部署結(jié)構(gòu)如下所示。

以下是一些測(cè)試情況對(duì)比。我們使用wrk對(duì)ClusterIP進(jìn)行2000并發(fā)HTTP短連接測(cè)試，分別比較svc數(shù)量為10和svc數(shù)量為5000，觀察請(qǐng)求耗時(shí)情況（單位ms）。

結(jié)論是cproxy無(wú)論在svc數(shù)量較少和較多的情況下，都擁有最好的性能；ipvs在svc數(shù)量較大的情況下性能遠(yuǎn)好于iptables，但在svc數(shù)量較小的情況下，性能不如iptables。

svc數(shù)量=10

svc數(shù)量=5000

后續(xù)我們會(huì)繼續(xù)完善基于eBPF實(shí)現(xiàn)LoadBalancer（南北流量）轉(zhuǎn)發(fā)，以及基于eBPF的網(wǎng)絡(luò)訪問(wèn)策略（NetworkPolicy）。

UCloud 優(yōu)刻得容器產(chǎn)品擁抱eBPF

eBPF正在改變?cè)圃鷳B(tài)， 未來(lái)UCloud 優(yōu)刻得容器云產(chǎn)品 UK8S與Serverless容器產(chǎn)品Cube將緊密結(jié)合業(yè)內(nèi)最新進(jìn)展，挖掘eBPF在網(wǎng)絡(luò)，負(fù)載均衡，監(jiān)控等領(lǐng)域的應(yīng)用，為用戶提供更好的觀測(cè)、定位和調(diào)優(yōu)能力。