【摘要】 external-traffic-policy,顧名思義“外部流量策略”,那這個配置有什麼作用呢?以及external是指什麼東西的外部呢,集羣、節點、Pod?今天我們就來學習一下這個概念吧。
1 什麼是external-traffic-policy
在k8s的Service對象(申明一條訪問通道)中,有一個“externalTrafficPolicy”字段可以設置。有2個值可以設置:Cluster或者Local。
1)Cluster表示:流量可以轉發到其他節點上的Pod。
2)Local表示:流量只發給本機的Pod。
圖示一下:
2 這2種模式有什麼區別
存在這2種模式的原因就是,當前節點的Kube-proxy在轉發報文的時候,會不會保留原始訪問者的IP。
2.1 選擇(1)Cluster
注:這個是默認模式,Kube-proxy不管容器實例在哪,公平轉發。
Kube-proxy轉發時會替換掉報文的源IP。即:容器收的報文,源IP地址,已經被替換爲上一個轉發節點的了。
原因是Kube-proxy在做轉發的時候,會做一次SNAT (source network address translation),所以源IP變成了節點1的IP地址。
ps:snat確保回去的報文可以原路返回,不然回去的路徑不一樣,客戶會認爲非法報文的。(我發給張三的,怎麼李四給我回應?丟棄!)
這種模式好處是負載均衡會比較好,因爲無論容器實例怎麼分佈在多個節點上,它都會轉發過去。當然,由於多了一次轉發,性能會損失一丟丟。
2.2 選擇(2)Local
這種情況下,只轉發給本機的容器,絕不跨節點轉發。
Kube-proxy轉發時會保留源IP。即:容器收到的報文,看到源IP地址還是用戶的。
缺點是負載均衡可能不是很好,因爲一旦容器實例分佈在多個節點上,它只轉發給本機,不跨節點轉發流量。當然,少了一次轉發,性能會相對好一丟丟。
注:這種模式下的Service類型只能爲外部流量,即:LoadBalancer 或者 NodePort 兩種,否則會報錯。
同時,由於本機不會跨節點轉發報文,所以要想所有節點上的容器有負載均衡,就需要上一級的Loadbalancer來做了。
不過流量還是會不太均衡,如上圖,Loadbalancer看到的是2個後端(把節點的IP),每個Node上面幾個Pod對Loadbalancer來說是不知道的。
想要解決負載不均衡的問題:可以給Pod容器設置反親和,讓這些容器平均的分佈在各個節點上(不要聚在一起)。
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: k8s-app
operator: In
values:
- my-app
topologyKey: kubernetes.io/hostname
像下面這樣,負載均衡情況就會好很多~
3 兩種模式該怎麼選
要想性能(時延)好,當然應該選 Local 模式嘍,畢竟流量轉發少一次SNAT嘛。
不過注意,選了這個就得考慮好怎麼處理好負載均衡問題(ps:通常我們使用Pod間反親和來達成)。
如果你是從外部LB接收流量的,那麼使用:Local模式 + Pod反親和,一般是足夠的。
參考:
https://www.asykim.com/blog/deep-dive-into-kubernetes-external-traffic-policies
作者:華爲雲享專家 tsjsdbd