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的默认负载均衡算法是什么？

回答

相关问题