摘要：但事實是，并不完美，甚至存在嚴重的問題。容器產(chǎn)品擁抱正在改變云原生生態(tài)，未來容器云產(chǎn)品與容器產(chǎn)品將緊密結(jié)合業(yè)內(nèi)最新進展，挖掘在網(wǎng)絡(luò)，負載均衡，監(jiān)控等領(lǐng)域的應(yīng)用，為用戶提供更好的觀測定位和調(diào)優(yōu)能力。

Serverless容器的服務(wù)發(fā)現(xiàn)

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

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

為什么不是kube-proxy？

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

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

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

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

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

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

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

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

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

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

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

ClusterIP的實現(xiàn)

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

對于一般環(huán)境，DNAT操作可以發(fā)生在tc egress，同時在tc ingress
中對回程的流量進行反向操作，即將源地址由真實的PodIP改成ClusterIP 此外完成NAT后需要重新計算IP和TCP頭部的checksum。

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

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

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

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

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

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

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

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

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

UCloud容器產(chǎn)品擁抱eBPF

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

                                                                   文章來源：U-Star技術(shù)創(chuàng)作者