Question

我有一个简单的入口资源和两个服务：ess-index和ess-query。使用NodePort类型--session-afinity=None公开了服务。 Ingress资源具有以下结构：

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将从标记配置的范围中分配端口，并且每个Node将分别将该端口代理到ess-index或ess-query服务中。所以，当我进入POST时 kubectl create -f ingress.yaml它将导致以下行为：将自动创建GLBC控制器，管理以下GCE资源图（全局转发规则 - ＆gt; TargetHttpProxy - ＆gt; Url地图 - ＆gt;后端服务 - ＆gt;实例组）。根据文档，它应该显示为pod，但我无法在以下命令输出中看到它：kubectl get pods --namespace=kube-system。这是sample output我的问题是：这个负载均衡器的默认负载均衡算法是什么？当流量路由到适当的后端时会发生什么？我的理解是正确的，默认算法不是循环法，并且根据Service文档，是随机分布的（可能基于源/目标IP的某些散列等）？这很重要，因为在我的情况下，所有流量来自少量具有固定IP的机器，因此我可以看到后端实例上的非均匀流量分布。如果是这样，获得循环行为的正确方法是什么？据我所知，我可以从两个变种中选择：

自定义入口控制器。优点：它可以自动检测pod重启/等，缺点：不能支持我将来可能需要的高级l7功能（如会话持久性）
删除ingress并使用自己构建解决方案，如下所述：https://www.nginx.com/blog/load-balancing-kubernetes-services-nginx-plus/ 优点：完全可定制，缺点：如果pod重启等，你应该小心自己。

Answer 1

结合kubeproxy和cloud lb算法，使他们朝着共同目标合作仍然是一项正在进行中的工作。现在，它将最终喷涂，随着时间的推移你得到大致相等的分配，但它不会严格rr。

如果你真的希望对算法进行细粒度控制，你可以部署nginx ingress controller并将其作为Type = lb的服务公开（或者甚至在它前面贴上GCE l7）。这将为您提供Ingress语义，但允许云提供者尚未与Kube完全集成的区域的逃生舱口，如算法控制。逃生舱口为annotations或模板的完整config map。

GKE中GLBC L7的默认负载均衡算法是什么？

1 个答案: