環境描述
生產環境通過gitlab-running實現自動化發布業務，現需要收集客戶端的真實ip，需要將externaltrafficpolicy改為lacal模式(原來是cluster模式)，前天開發反映無法發布業務(鏡像拉取不成功)。想到就改動過externaltrafficpolicy所以考慮到了local模式和cluster模式的區別。
externaltrafficpolicy作用闡述
把集群外部的服務引入到集群內部來，在集群內部直接使用。沒有任何類型代理被創建，這只有 kubernetes 1.7 或更高版本的 kube-dns 才支持【當我們的集群服務需要訪問k8s之外的集群時，可以選擇這種類型，然后把外部服務的IP及端口寫入到k8s服務中來，k8s的代理將會幫助我們訪問到外部的集群服務】
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反親和，一般是足夠的
總結
同上上述的理論學習，問題可以明確的得出答案：externaltrafficpolicy的local模式，只轉發給本機的容器，絕不跨節點轉發，而我司的gitlab是部署在k8s環境的，分散於多節點。
參考文獻
深入研究Kubernetes外部流量策略
https://www.asykim.com/blog/deep-dive-into-kubernetes-external-traffic-policies
K8s中的external-traffic-policy是什么？