Question

我有2个后端应用程序在gke的同一群集上运行。应用程序A和B。A具有1个容器，B具有2个容器。 A暴露于外界，并接收IP地址，然后他通过标头中的http请求将其发送给B。

B具有这样配置的Kubernetes服务对象。

apiVersion: v1
kind: Service
metadata:
  name: svc-{{ .Values.component_name }}
  namespace: {{ include "namespace" .}}
spec:
  ports:
    - port: 80
      targetPort: {{.Values.app_port}}
      protocol: TCP
  selector:
    app: pod-{{ .Values.component_name }}
  type: ClusterIP

在该配置中，来自A的http请求在应用程序B的2个pod之间平均平衡，但是当我向配置中添加sessionAffinity: ClientIP时，即使我认为每个HTTP请求都发送到同一B pod应该是循环的互动方式。

为清楚起见，我将IP地址存储在标头X-Forwarded-For中，因此该服务应对其进行检查，以确保将哪个请求发送给哪个B pod，如文档所述https://kubernetes.io/docs/concepts/services-networking/service/#ssl-support-on-aws

在我的测试中，我试图给B吊舱之一创建很大的负载，以使其尝试与第二吊舱接触而没有成功。我确保标头中具有不同的IP，并且不是因为环境中存在某种代理。 IP以前没有用于测试，因此不是因为已经存在粘性。

我现在被困住了，因为我不知道如何进一步测试它，并且一直在阅读文档，并且可能遗漏了一些东西。我的猜测是sessionAffinity禁用了ClusterIp类型的负载平衡，但这似乎不太可能...

我的问题是：

我观察到的举止正常吗？我在做什么错了？

这可能有助于了解是否仍不清楚我要说的是：https://stackoverflow.com/a/59109265/12298812

编辑：我确实在上游的客户端上进行了测试，并且我至少看到了一些请求到达B的第二个容器，但是此负载测试是针对每个请求从相同的IP执行的。所以这次我应该只能看到一个豆荚获得交通...

Answer 1

此行为表明cluster-ip服务不遵循x-forward-for标头。

请确保我建议从使用上述服务的上游客户端服务中加载测试，并查看您将获得哪种行为。您很可能会在那里看到相同的不正确行为，这会影响您的服务扩展。

也就是说，将会话亲缘关系用于内部服务非常不常见，因为客户端IP地址的变化不大。会话关联性限制了应用程序的扩展能力。通常，您将memcached或redis用作会话存储，这可能比基于会话亲和力的解决方案更具可伸缩性。

GKE具有会话亲和力（粘性会话）的后端pod之间没有负载平衡

1 个答案: