kube-proxy

我們知道尉辑，Kubernetes中Pod的生命是短暫了蛹找，它隨時可能被終止候齿。即使使用了Deployment或者ReplicaSet保證Pod掛掉之后還會重啟茶没，但也沒法保證重啟后Pod的IP不變筒占。從服務的高可用性與連續(xù)性的角度出發(fā)妻献，我們不可能把Pod的IP直接暴露成service端口蛛株。因此我們需要一個更加可靠的“前端”去代理Pod，這就是k8s中的Service育拨。引用官方文檔的定義就是：

Service 定義了這樣一種抽象：邏輯上的一組 Pod泳挥，一種可以訪問它們的策略 —— 通常稱為微服務。 這一組 Pod 能夠被 Service 訪問到至朗。

也可以說屉符，Service作為“前端”提供穩(wěn)定的服務端口，Pod作為“后端”提供服務實現(xiàn)锹引。Service會監(jiān)控自己組內的Pod的運行狀態(tài)矗钟，剔除終止的Pod，添加新增的Pod嫌变。配合k8s的服務發(fā)現(xiàn)機制吨艇，我們再也不用擔心IP改變，Pod終止等問題了腾啥。kube-proxy則是實現(xiàn)Service的關鍵組件东涡，到目前為止共有3種實現(xiàn)模式：userspace、iptables 或者 IPVS倘待。其中userspace 模式非常陳舊疮跑、緩慢，已經不推薦使用凸舵。

IP Tables模式

iptables 是一個 Linux 內核功能祖娘，是一個高效的防火墻，并提供了大量的數(shù)據(jù)包處理和過濾方面的能力啊奄。它可以在核心數(shù)據(jù)包處理管線上用 Hook 掛接一系列的規(guī)則渐苏。在K8S中掀潮，kube-proxy 會把請求的代理轉發(fā)規(guī)則全部寫入iptable中，砍掉了kube-proxy轉發(fā)的部分琼富，整個過程發(fā)生在內核空間仪吧，提高了轉發(fā)性能，但是iptable的規(guī)則是基于鏈表實現(xiàn)的鞠眉，規(guī)則數(shù)量隨著Service數(shù)量的增加線性增加邑商，查找時間復雜度為O（n），也就是說凡蚜，當Service數(shù)量到達一定量級時人断，CPU消耗和延遲將顯著增加。

IP VS模式

IPVS 是一個用于負載均衡的 Linux 內核功能朝蜘。IPVS 模式下恶迈，kube-proxy 使用 IPVS 負載均衡代替了 iptable。IPVS 的設計就是用來為大量服務進行負載均衡的谱醇，它有一套優(yōu)化過的 API暇仲，使用優(yōu)化的查找算法，而不是簡單的從列表中查找規(guī)則副渴。這樣一來奈附，kube-proxy 在 IPVS 模式下，其連接過程的復雜度為 O(1)煮剧。換句話說斥滤，多數(shù)情況下，他的連接處理效率是和集群規(guī)模無關的勉盅。另外作為一個獨立的負載均衡器佑颇，IPVS 包含了多種不同的負載均衡算法，例如輪詢草娜、最短期望延遲挑胸、最少連接以及各種哈希方法等。而 iptables 就只有一種隨機平等的選擇算法宰闰。IPVS 的一個潛在缺點就是茬贵，IPVS 處理數(shù)據(jù)包的路徑和通常情況下 iptables 過濾器的路徑是不同的。

通過下圖移袍，可以簡單的看出Client pod 解藻、kube proxy 、Pod之間的關系咐容。Service的虛擬Ip會寫到ip tables/ip vs中舆逃，被轉發(fā)到真正的Pod地址蚂维。

image.png

IP Tables & IP VS 網絡扭轉

image.png

流程簡述如下：

1. kube-proxy DNAT + SNAT 用自己的 IP 替換源 IP 戳粒，用 Pod IP 替換掉目的 IP
2. 數(shù)據(jù)包轉發(fā)到目標 Pod
3. Pod 將 Ingress Node 視為源路狮，并作出響應
4. 源 / 目的地址在 Ingress Node 替換為客戶端地址(目的) ，服務地址(Ingress Node)

性能對比

image.png

image.png

總結下IPVS & IPTables

1.在小規(guī)模的集群中蔚约，兩者在CPU和響應時間上奄妨，差別不大，無論是keep alive 還是non keep alive 苹祟。

2.在大規(guī)模集群中砸抛，兩者會慢慢在響應時間以及CPU上都會出現(xiàn)區(qū)別喇勋，不過在使用keep alive的情況下骏庸，區(qū)別還是主要來源于CPU的使用。

3.ipvs 基于散列表吞琐，復雜度 O(1)砂轻，iptables 基于鏈表奔誓，復雜度 O(n)

4.ipvs 支持多種負載均衡調度算法；iptables 只有由 statistic 模塊的 DNAT 支持概率輪詢搔涝。

PS：要注意厨喂，在微服務的情況下，調用鏈會非常長庄呈，兩者影響效果會更顯著一些蜕煌。

eBPF

什么是eBPF?

Linux內核一直是實現(xiàn)監(jiān)視/可觀察性，網絡和安全性的理想場所诬留。不幸的是斜纪，這通常是不切實際的，因為它需要更改內核源代碼或加載內核模塊文兑，并導致彼此堆疊的抽象層傀广。 eBPF是一項革命性的技術，可以在Linux內核中運行沙盒程序彩届，而無需更改內核源代碼或加載內核模塊伪冰。通過使Linux內核可編程，基礎架構軟件可以利用現(xiàn)有的層樟蠕，從而使它們更加智能和功能豐富贮聂，而無需繼續(xù)為系統(tǒng)增加額外的復雜性層。

eBPF導致了網絡寨辩，安全性吓懈，應用程序配置/跟蹤和性能故障排除等領域的新一代工具的開發(fā)，這些工具不再依賴現(xiàn)有的內核功能靡狞，而是在不影響執(zhí)行效率或安全性的情況下主動重新編程運行時行為耻警。對于云原生領域，Cilium 已經使用eBPF 實現(xiàn)了無kube-proxy的容器網絡。利用eBPF解決iptables帶來的性能問題甘穿。

通過的 eBPF 實現(xiàn)腮恩，可以保留原始源 IP，并且可以選擇執(zhí)行直接服務器返回 (DSR)温兼。即返回流量可以選擇最優(yōu)路徑秸滴，而無需通過原始入口節(jié)點環(huán)回，如下圖：

image.png

簡述流程如下:

1. BPF program 將數(shù)據(jù)發(fā)送給 K8s service募判； 做負載均衡決策并將數(shù)據(jù)包發(fā)送給目的 pod 節(jié)點
2. BPF program 程序將 DNAT 轉換成 Pod 的IP
3. Pod 看到客戶端真正的 IP
4. Pod 做出響應荡含； BPF 反向 DNAT
5. 如果網絡準許，數(shù)據(jù)包直接返回届垫。否則將通過 Ingress Node （ingress controller Pod 所在服務器）

性能

網絡吞吐

測試環(huán)境：兩臺物理節(jié)點释液，一個發(fā)包，一個收包装处，收到的包做 Service loadbalancing 轉發(fā)給后端 Pods均澳。

image.png

可以看出：

1. Cilium XDP eBPF 模式能處理接收到的全部 10Mpps（packets per second）。
2. Cilium tc eBPF 模式能處理 3.5Mpps符衔。
3. kube-proxy iptables 只能處理 2.3Mpps找前，因為它的 hook 點在收發(fā)包路徑上更后面的位置。
4. kube-proxy ipvs 模式這里表現(xiàn)更差判族，它相比 iptables 的優(yōu)勢要在 backend 數(shù)量很多的時候才能體現(xiàn)出來躺盛。

CPU 利用率

測試生成了 1Mpps、2Mpps 和 4Mpps 流量形帮，空閑 CPU 占比（可以被應用使用的 CPU）結果如下：

image.png

結論與上面吞吐類似槽惫。

• XDP 性能最好，是因為 XDP BPF 在驅動層執(zhí)行辩撑，不需要將包 push 到內核協(xié)議棧界斜。
• kube-proxy 不管是 iptables 還是 ipvs 模式，都在處理軟中斷（softirq）上消耗了大量 CPU合冀。

eBPF簡化服務網格

首先看下Service Mesh

image.png

這是一張經典的service mesh圖各薇，在eBPF之前，kubernetes服務網格解決方案是要求我們在每一個應用pod上添加一個代理Sidecar容器君躺，如：Envoy/Linkerd-proxy峭判。

例：即使在一個非常小的環(huán)境中，比如說有20個服務棕叫，每個服務運行5個pod林螃，分在3個節(jié)點上，你也有100個代理容器俺泣。無論代理的實現(xiàn)多么小和有效疗认，這種純粹的重復都會浪費資源完残。每個代理使用的內存與它需要能夠通信的服務數(shù)量有關。

問題：

為什么我們需要所有這些 sidecar横漏？這種模式允許代理容器與 pod 中的應用容器共享一個網絡命名空間谨设。網絡命名空間是 Linux 內核的結構，它允許容器和 pod 擁有自己獨立的網絡堆棧绊茧，將容器化的應用程序相互隔離铝宵。這使得應用之間互不相干打掘，這就是為什么你可以讓盡可能多的 pod 在 80 端口上運行一個 web 應用 —— 網絡命名空間意味著它們各自擁有自己的 80 端口华畏。代理必須共享相同的網絡命名空間，這樣它就可以攔截和處理進出應用容器的流量尊蚁。

eBPF的sidecar less proxy model

基于eBPF的Cilium項目亡笑，最近將這種“無 sidecar”模式帶到了服務網格的世界。除了傳統(tǒng)的 sidecar 模型横朋，Cilium 還支持每個節(jié)點使用一個 Envoy 代理實例運行服務網格的數(shù)據(jù)平面仑乌。使用上面的例子，這就把代理實例的數(shù)量從 100 個減少到只有 3 個琴锭。

image.png

支持eBPF的網絡允許數(shù)據(jù)包走捷徑晰甚，繞過內核部分網絡對戰(zhàn)，這可以使kubernetes網絡的性能得到更加顯著的改善决帖，如下圖：

image.png

在服務網格的情況厕九，代理在傳統(tǒng)網絡中作為sidecar運行，數(shù)據(jù)包到達應用程序的路徑相當曲折：入棧數(shù)據(jù)包必須穿越主機TPC/IP棧地回，通過虛擬以太網連接到達pod的網絡命名空間扁远。從那里，數(shù)據(jù)包必須穿過pod的網絡對戰(zhàn)到達代理刻像，代理講數(shù)據(jù)包通過回環(huán)接口轉發(fā)到應用程序畅买，考慮到流量必須在連接的兩端流經代理，于非服務網格流量相比细睡，這將導致延遲的顯著增加谷羞。

而基于eBPF的kubernetes CNI實現(xiàn)，如Cilium溜徙，可以使用eBPF程序洒宝，明智的勾住內核中的特定點，沿著更加直接的路線重定向數(shù)據(jù)包萌京。因為Cilium知道所有的kubernetes斷點和服務的身份雁歌。當數(shù)據(jù)包到達主機時，Cilium 可以將其直接分配到它所要去的代理或 Pod 端點知残。

總結

通過以上的內容靠瞎，我想大家對kube-proxy和基于eBPF的CNI插件Cilium已經有了一些了解比庄。可以看到在云原生領域乏盐，Cilium 已經使用eBPF 實現(xiàn)了無kube-proxy的容器網絡佳窑。利用eBPF解決iptables帶來的性能問題。另外以上也只是介紹了eBPF的網絡方面父能，其實eBPF在跟蹤神凑、安全、負載均衡何吝、故障分析等領域都是eBPF的主戰(zhàn)場溉委，而且還有更多更多的可能性正在被發(fā)掘。