GKE中GLBC L7的默認負載均衡算法是什麼？

我有一個簡單的入口資源和兩個服務：ess-index和ess-query。服務已通過NodePort與--session-afinity=None曝光。 Ingress資源具有以下結構：GKE中GLBC L7的默認負載均衡算法是什麼？

apiVersion: extensions/v1beta1 
kind: Ingress 
metadata: 
name: ess-ingress 
spec: 
    backend: 
    serviceName: ess-query 
    servicePort: 2280 
    rules: 
    - http: 
     paths: 
     - path: /api/index 
     backend: 
      serviceName: ess-index 
      servicePort: 2280

創建的服務將具有代理模式iptables。當我將這些服務公開爲NodePort時，kubernetes master將從標記配置的範圍中分配一個端口，並且每個節點將分別將該端口代理到ess-index或ess-query服務。因此，當我POST入口與 kubectl create -f ingress.yaml它會導致以下行爲：將自動創建GLBC控制器，管理以下GCE資源圖（全局轉發規則 - > TargetHttpProxy - > Url映射 - >後端服務 - >實例組）。根據文檔，它應該顯示爲一個窗格，但在以下命令輸出中我看不到它：kubectl get pods --namespace=kube-system。這裏的sample output我的問題是：什麼是這個負載均衡的默認負載平衡算法？當流量路由到適當的後端時會發生什麼？根據Service文檔，我的理解是正確的，默認算法不是循環法，而是隨機分佈的（可能基於源/目標IP的一些散列等）？這一點很重要，因爲在我的情況下，所有流量都來自於少量具有固定IP的機器，因此我可以看到後端實例上的流量分佈不均勻。如果是這樣，那麼獲得輪循機制行爲的正確方法是什麼？據我瞭解，我可以從兩種變體中選擇：

自定義入口控制器。優點：它可以自動檢測莢重啓/等缺點：不支持，我可能需要在未來（如會話持久性）高級L7功能
刪除進入和使用建立它自己的解決方案喜歡這裏提到的：https://www.nginx.com/blog/load-balancing-kubernetes-services-nginx-plus/ 優點：完全可自定義，缺點：如果豆莢重新啓動等，你應該小心。

來源

2016-11-07 vglazkov

將kubeproxy和雲lb算法合併爲一個共同的目標仍然是一項工作。現在，它會結束噴灑，隨着時間的推移，你會得到大致平均的分配，但它不會嚴格的rr。

如果您真的想要對算法進行細粒度控制，您可以部署nginx ingress controller並將其公開爲Type = lb的服務（或者甚至在其前面粘貼GCE 17）。這將爲您提供Ingress語義，但是可以爲雲提供者尚未完全與Kube集成的區域提供逃生孵化，如算法控制。逃生艙口爲annotations或模板的完整config map。

來源

2016-11-07 18:26:17

感謝您的回覆。你能否也請指出爲什麼我看不到GLBC負載平衡器吊艙？我的索引後端服務仍然沒有大致平均分配。平衡模式有沒有可能影響到這一點？我的理解是否正確，GKE現在僅支持最大CPU平衡模式？ – vglazkov

默認是cpu，你可以切換到rps（https://cloud.google.com/compute/docs/load-balancing/http/backend-service），除非你控制器不會把它切換回rps刪除後端。 –

另請注意，此處的算法（利用率vs rps）僅爲交叉區域。在一個地區噴灑（大約2個級別的rr）：https：//cloud.google.com/compute/docs/load-balancing/http/#load_distribution_algorithm –

GKE中GLBC L7的默認負載均衡算法是什麼？

回答

相關問題