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

Question

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

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 映射 -> 后端服务 -> 实例组） .根据文档，它应该显示为一个 pod，但我在以下命令输出中看不到它：kubectl get pods --namespace=kube-system。 sample output 我的问题是：此负载均衡器的默认负载均衡算法是什么？当流量路由到适当的后端时会发生什么？我的理解是否正确，即默认算法不是循环法，并且根据 Service 文档，它是随机分布的（可能基于 source/destination IP 等的某些散列）？这很重要，因为在我的例子中，所有流量都来自少数具有固定 IP 的机器，因此我可以看到后端实例上的流量分布不均匀。如果是这样，获得循环行为的正确方法是什么？据我所知，我可以从两种变体中进行选择：

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

Answer 1

将 kubeproxy 和 cloud lb 算法结合起来以便它们朝着共同的目标合作仍在进行中。现在，它最终会喷洒，随着时间的推移，你会得到大致相等的分布，但它不会是严格的 rr。

如果您确实想要对算法进行细粒度控制，可以为模板部署 nginx ingress controller and expose it as a Service of Type=lb (or even stick a GCE l7 in front of it). This will give you Ingress semantics, but allows an escape hatch for areas that cloudproviders aren't fully integrated with Kube just yet, like algorithm control. The escape hatch is exposed as annotations or a full config map。

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

What's the default load balancing algorithm in GLBC L7 in GKE?

load-balancing

kubernetes

google-kubernetes-engine