負載均衡器 OpenELB ARP 欺騙技術解析
作者:大飛哥,視源電子運維工程師,KubeSphere 使用者委員會廣州站站長,KubeSphere Ambassador。
K8S 對叢集外暴露服務有三種方式:NodePort,Ingress 和 Loadbalancer。NodePort 用於暴露 TCP 服務(4 層),但限於對叢集節點主機埠的佔用,不適合大規模使用;Ingress 用於暴露 HTTP 服務(7 層),可對域名地址做路由分發;Loadbalancer 則專屬於雲服務,可動態分配公網閘道器。
對於私有云叢集,沒有用到公有云服務,能否使用 LoadBalancer 對外暴露服務呢?
答案當然是肯定的,OpenELB 正是為裸金屬伺服器提供 LoadBalancer 服務而生的!
應用安裝與配置
安裝 OpenELB
參考官方安裝文件
$ kubectl apply -f https://raw.githubusercontent.com/openelb/openelb/master/deploy/openelb.yaml
新增 EIP 池
EIP 地址要與叢集主機節點在同一網段內,且不可繫結任何網絡卡;
apiVersion: network.kubesphere.io/v1alpha2 kind: Eip metadata: name: eip-sample-pool annotations: eip.openelb.kubesphere.io/is-default-eip: "true" spec: address: 192.168.0.91-192.168.0.100 protocol: layer2 interface: eth0 disable: false
配置 Service 為 LoadBalancer
把 Service 型別修改為 LoadBalancer,同時 annotations 中新增如下三行:
lb.kubesphere.io/v1alpha1: openelb
protocol.openelb.kubesphere.io/v1alpha1: layer2
eip.openelb.kubesphere.io/v1alpha2: layer2-eip
總體配置清單如下:
kind: Service apiVersion: v1 metadata: name: layer2-svc annotations: lb.kubesphere.io/v1alpha1: openelb protocol.openelb.kubesphere.io/v1alpha1: layer2 eip.openelb.kubesphere.io/v1alpha2: layer2-eip spec: selector: app: layer2-openelb type: LoadBalancer ports: - name: http port: 80 targetPort: 8080 externalTrafficPolicy: Cluster
Layer2 模式中的黑客技術
ARP 欺騙技術: 應用程式主動回覆路由器 ARP 請求,讓路由器以為該應用是合法終端,從而劫持網路流量包。
OpenELB 正是利用 ARP 欺騙技術,從而獲取路由器流量,再由 kube-proxy 將流量轉發到 Service 網路。OpenELB Layer2 模式需要配置 EIP,如上圖所示的 EIP 為 192.168.0.91
。
當請求 EIP 地址時,路由器會在區域網內發起 ARP 協議廣播,哪個終端裝置響應,就把資料包傳送給誰;配置 EIP 時有要求,EIP 地址不能繫結任何網絡卡,也就是說正常情況下,不會有任何物理硬體裝置響應。此時的 OpenELB,就趁虛而入,捕獲到 ARP 廣播資訊後,對路由器廣播進行響應,把自己偽裝成終端裝置。OpenELB 獲得流量後,再經由 kube-proxy 轉發入 Service 網路。
可以在其中一臺 Node 上面抓包看一下:
$ tcpdump -i any arp -nn -vvv | grep 192.168.0.91
17:33:01.398722 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.91 (ff:ff:ff:ff:ff:ff) tell 192.168.0.91, length 46
17:33:01.398793 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.0.91 is-at 52:54:22:3a:e6:6e, length 46
路由器的 ARP 快取每過一段時間就會失效,重新發起 ARP 協議廣播,使用 tcpdump 一直監聽就可以抓到相關的資料包。可以看到 OpenELB 響應的 MAC 地址是 Kubernetes 的其中一臺節點的 MAC 地址。
改善與建議
OpenELB Layer2 模式因其實現簡單,而且對物理硬體和網路沒有額外要求,所以實際生產中經常會用到。但目前仍存在單點故障風險,即如果 OpenELB 例項因資源不足故障,則整個對外流量將中斷。
萬幸的是 OpenELB 官方已有新的解決方案,即 Layer2 VIP 模式,該模式的使用方式可以參考官方文件。有時間我會再寫一篇 Layer2 VIP 模式的詳細使用方案,敬請期待。
本文由部落格一文多發平臺 OpenWrite 釋出!