Serverless容器的服務發現
2020年9月，UCloud上線了Serverless容器産品Cube，它具備了虛拟機級别的安全隔離、輕量化的系統占用、秒級的啟動速度，高度自動化的彈性伸縮，以及簡潔明了的易用性。結合虛拟節點技術（Virtual Kubelet），Cube可以和UCloud容器托管産品UK8S無縫對接，極大地豐富了Kubernetes叢集的彈性能力。如下圖所示，Virtual Node作為一個虛拟Node在Kubernetes叢集中，每個Cube執行個體被視為VK節點上的一個Pod。
然而，Virtual Kubelet僅僅實作了叢集中Cube執行個體的彈性伸縮。要使得Cube執行個體正式成為K8s叢集大家庭的一員，運作在Cube中的應用需要能利用K8s的服務發現能力，即通路Service位址。
為什麼不是kube-proxy？
衆所周知, kube-proxy為K8s實作了service流量負載均衡。kube-proxy不斷感覺K8s内Service和Endpoints位址的對應關系及其變化，生成ServiceIP的流量轉發規則。它提供了三種轉發實作機制：userspace, iptables和ipvs, 其中userspace由于較高的性能代價已不再被使用。
然而，我們發現，直接把kube-proxy部署在Cube虛拟機内部并不合适，有如下原因：
1 、kube-proxy采用go語言開發，編譯産生的目标檔案體積龐大。以K8s v1.19.5 linux環境為例，經strip過的kube-proxy ELF可執行檔案大小為37MB。對于普通K8s環境來說，這個體積可以忽略不計；但對于Serverless産品來說，為了保證秒起輕量級虛拟機，虛拟機作業系統和鏡像需要高度裁剪，寸土寸金，我們想要一個部署體積不超過10MB的proxy控制程式。
2 、kube-proxy的運作性能問題。同樣由于使用go語言開發，相對于C/C++和Rust等無gc、具備精細控制底層資源能力的進階語言來說，要付出更多的性能代價。Cube通常存在較細粒度的資源傳遞配額，例如0.5C 500MiB，我們不希望kube-proxy這類輔助元件喧賓奪主。
3 、ipvs的問題。在eBPF被廣為周知之前，ipvs被認為是最合理的K8s service轉發面實作。iptables因為擴充性問題被鞭屍已久，ipvs卻能随着services和endpoints規模增大依然保持穩定的轉發能力和較低的規則重新整理間隔。
但事實是，ipvs并不完美，甚至存在嚴重的問題。
例如，同樣實作nat , iptables是在PREROUTING或者OUTPUT完成DNAT；而ipvs需要經曆INPUT和OUTPUT，鍊路更長。是以，較少svc和ep數量下的service ip壓測場景下，無論是帶寬還是短連接配接請求延遲，ipvs都會獲得全場最低分。此外，conn_reuse_mode的參數為1導緻的滾動釋出時服務通路失敗的問題至今（2021年4月）也解決的不太幹淨。
4 、iptables的問題。擴充差，更新慢，O(n)時間複雜度的規則查找（這幾句話背不出來是找不到一份K8s相關的工作的）， 同樣的問題還會出現在基于iptables實作的NetworkPolicy上。1.6.2以下iptables甚至不支援full_random端口選擇，導緻SNAT的性能在高并發短連接配接的業務場景下雪上加霜。
eBPF能為容器網絡帶來什麼？
eBPF近年來被視為linux的革命性技術，它允許開發者在linux的核心裡動态實時地加載運作自己編寫的沙盒程式，無需更改核心源碼或者加載核心子產品。同時，使用者态的程式可以通過bpf(2)系統調用和bpf map結構與核心中的eBPF程式實時交換資料，如下圖所示。
編寫好的eBPF程式在核心中以事件觸發的模式運作，這些事件可以是系統調用入出口，網絡收發包的關鍵路徑點(xdp, tc, qdisc, socket)，核心函數入出口kprobes/kretprobes和使用者态函數入出口uprobes/uretprobes等。加載到網絡收發路徑的hook點的eBPF程式通常用于控制和修改網絡封包， 來實作負載均衡，安全政策和監控觀測。
cilium的出現使得eBPF正式進入K8s的視野，并正在深刻地改變k8s的網絡，安全，負載均衡，可觀測性等領域。從1.6開始，cilium可以100%替換kube-proxy，真正通過eBPF實作了kube-proxy的全部轉發功能。讓我們首先考察一下ClusterIP(東西流量)的實作。
ClusterIP的實作
無論對于TCP還是UDP來說，用戶端通路ClusterIP隻需要實作針對ClusterIP的DNAT，把Frontend與對應的Backends位址記錄在eBPF map中，這個表的内容即為後面執行DNAT的依據。那這個DNAT在什麼環節實作呢？
對于一般環境，DNAT操作可以發生在tc egress，同時在tc ingress中對回程的流量進行反向操作，即将源位址由真實的PodIP改成ClusterIP, 此外完成NAT後需要重新計算IP和TCP頭部的checksum。
如果是支援cgroup2的linux環境，使用cgroup2的sockaddr hook點進行DNAT。cgroup2為一些需要引用L4位址的socket系統調用，如connect(2), sendmsg(2), recvmsg(2)提供了一個BPF攔截層（BPF_PROG_TYPE_CGROUP_SOCK_ADDR）。這些BPF程式可以在packet生成之前完成對目的位址的修改，如下圖所示。
對于tcp和有連接配接的udp的流量（即針對udp fd調用過connect(2)）來說, 隻需要做一次正向轉換，即利用bpf程式，将出向流量的目的位址改成Pod的位址。這種場景下，負載均衡是最高效的，因為開銷一次性的，作用效果則持續貫穿整個通信流的生命周期。
而對于無連接配接的udp流量，還需要做一次反向轉換，即将來自Pod的入向流量做一個SNAT，将源位址改回ClusterIP。如果缺了這一步操作，基于recvmsg的UDP應用會無法收到來自ClusterIP的消息，因為socket的對端位址被改寫成了Pod的位址。流量示意圖如下所示。
綜述，這是一種使用者無感覺的位址轉換。使用者認為自己連接配接的位址是Service, 但實際的tcp連接配接直接指向Pod。一個能說明問題的對比是，當你使用kube-proxy的時候，在Pod中進行tcpdump時，你能發現目的位址依然是ClusterIP，因為ipvs或者iptables規則在host上；當你使用cilium時，在Pod中進行tcpdump，你已經能發現目的位址是Backend Pod。NAT不需要借助conntrack就能完成，相對于ipvs和iptables來說，轉發路徑減少，性能更優。而對比剛才提到的tc-bpf，它更輕量，無需重新計算checksum。
Cube的Service服務發現
Cube為每個需要開啟ClusterIP通路功能的Serverless容器組啟動了一個叫cproxy的agent程式來實作kube-proxy的核心功能。由于Cube的輕量級虛拟機鏡像使用較高版本的linux核心，cproxy采用了上述cgroup2 socket hook的方式進行ClusterIP轉發。cproxy使用Rust開發，編譯後的目标檔案隻有不到10MiB。運作開銷相比kube-proxy也有不小優勢。部署結構如下所示。
以下是一些測試情況對比。我們使用wrk對ClusterIP進行2000并發HTTP短連接配接測試，分别比較svc數量為10和svc數量為5000，觀察請求耗時情況（機關ms）。
結論是cproxy無論在svc數量較少和較多的情況下，都擁有最好的性能；ipvs在svc數量較大的情況下性能遠好于iptables，但在svc數量較小的情況下，性能不如iptables。svc數量=10
svc數量=5000
後續我們會繼續完善基于eBPF實作LoadBalancer（南北流量）轉發，以及基于eBPF的網絡通路政策（NetworkPolicy）。
UCloud容器産品擁抱eBPF
eBPF正在改變雲原生生态， 未來UCloud容器雲産品 UK8S與Serverless容器産品Cube将緊密結合業内最新進展，挖掘eBPF在網絡，負載均衡，監控等領域的應用，為使用者提供更好的觀測、定位和調優能力。