externaltrafficpolicy的有關問題說明

時間 2020-07-23

標籤 externaltrafficpolicy 有關問題說明简体版

原文原文鏈接

環境描述

生產環境經過gitlab-running實現自動化發佈業務，現須要收集客戶端的真實ip，須要將externaltrafficpolicy改成lacal模式(原來是cluster模式)，前天開發反映沒法發佈業務(鏡像拉取不成功)。想到就改動過externaltrafficpolicy因此考慮到了local模式和cluster模式的區別。git

externaltrafficpolicy做用闡述

把集羣外部的服務引入到集羣內部來，在集羣內部直接使用。沒有任何類型代理被建立，這隻有 kubernetes 1.7 或更高版本的 kube-dns 才支持【當咱們的集羣服務須要訪問k8s以外的集羣時，能夠選擇這種類型，而後把外部服務的IP及端口寫入到k8s服務中來，k8s的代理將會幫助咱們訪問到外部的集羣服務】後端

1 什麼是external-traffic-policy

在k8s的Service對象（申明一條訪問通道）中，有一個「externalTrafficPolicy」字段能夠設置。有2個值能夠設置：Cluster或者Local。app

1）Cluster表示：流量能夠轉發到其餘節點上的Pod。負載均衡

2）Local表示：流量只發給本機的Pod。gitlab

圖示一下：
性能

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地址。code

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

像下面這樣，負載均衡狀況就會好不少~