Kubernetes进入同一主机上运行的pod?

Kubernetes进入同一主机上运行的pod?,kubernetes,kubernetes-ingress,Kubernetes,Kubernetes Ingress,我们刚刚开始使用k8s(Ubuntu 20.04上的裸机)。到达负载平衡服务主机的入口流量是否有可能进入该主机上运行的pod(如果有) 我们有一些应用程序使用客户端一致性哈希(使用客户ID)来选择要调用的服务实例。服务实例是无状态的,但为每个客户维护内存中的ML模型。因此,让给定客户的重复请求转到相同的服务是有用的(但不是必需的)。然后,我们可以使用反亲和力使每个主机有一个pod 我们现有的服务发现机制允许客户端找到服务的所有实例以及它们运行的节点。我们所有的k8s节点都在运行Nginx入口控制

我们刚刚开始使用k8s(Ubuntu 20.04上的裸机)。到达负载平衡服务主机的入口流量是否有可能进入该主机上运行的pod(如果有)

我们有一些应用程序使用客户端一致性哈希(使用客户ID)来选择要调用的服务实例。服务实例是无状态的,但为每个客户维护内存中的ML模型。因此,让给定客户的重复请求转到相同的服务是有用的(但不是必需的)。然后,我们可以使用反亲和力使每个主机有一个pod

我们现有的服务发现机制允许客户端找到服务的所有实例以及它们运行的节点。我们所有的k8s节点都在运行Nginx入口控制器。

我相信这就是您想要的。入口不直接与POD通信,而是与服务通信。粘性会话试图通过设置关联cookie将来自同一客户端的请求绑定到同一pod

例如,这用于信令会话,其中协商请求必须与以下websocket连接位于同一主机上

例如:

apiVersion:networking.k8s.io/v1 种类:入口 元数据: 名称:最小入口 注释: nginx.ingres.kubernetes.io/rewrite-target:/ nginx.ingres.kubernetes.io/affinity:cookie nginx.ingres.kubernetes.io/affinity-mode:persistent 规格: 规则: -http: 路径: -路径:/testpath 路径类型:前缀 后端: 服务: 名称:测试 端口: 电话:80
默认情况下,关联模式为“平衡”。如果您的pod计数没有改变,您的部分客户端将丢失会话。使用“persistent”让用户始终连接到同一个pod(当然,除非它死掉)。进一步阅读:

我终于明白了这一点。这比我想象的要难多了更新:它不工作。流量经常进入错误的pod。

服务需要
外部流量策略:本地
(请参阅)

入口需要
nginx.ingres.kubernetes.io/service-upstream:“true”
()

nginx.ingres.kubernetes.io/server-alias:“~^starterservice-[a-z0-9]+\\\.example\\.com”
位是因为我们的服务发现更新了DNS,所以服务的每个实例都在其DNS名称中包含了正在运行的主机的名称

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: starterservice
  namespace: default
  annotations:
    nginx.ingress.kubernetes.io/server-alias: "~^starterservice-[a-z0-9]+\\.example\\.com"
    nginx.ingress.kubernetes.io/service-upstream: "true"
spec:
  rules:
    - host:  starterservice.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: starterservice
                port:
                  number: 8168

所以现在有一个电话
https://starterservice-foo.example.com
将转到在k8s主机foo上运行的实例。

检查问题是传入呼叫都来自同一IP。因此,分布实际上是由有效负载(客户ID)而不是调用方决定的。所以我认为设置cookie对这个用例不起作用。我们有很多相关的用例。我们有在所有实例之间共享消息队列的无状态服务。每个实例都有一个仪表板,显示它们的队列集发生了什么。因此,我们需要能够以某种方式在实例(pod)之间切换。web UI当前有指向此的所有实例的链接。嗯,好的,这更复杂。客户id是如何传递的,headers/path/body/cookie?它在body中。我们可以换个地方。此时,客户机正在选择实例:它具有主机和pod名称,并且可以通过服务发现提供任何其他可能有帮助的内容。如果我们能解决这个问题,我们可以很快将大量的基础设施投入到k8s中,因为遗留的和k8s的东西将无缝地进行互操作。更新:它不起作用。车辆经常驶入错误的吊舱。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: starterservice
  namespace: default
  annotations:
    nginx.ingress.kubernetes.io/server-alias: "~^starterservice-[a-z0-9]+\\.example\\.com"
    nginx.ingress.kubernetes.io/service-upstream: "true"
spec:
  rules:
    - host:  starterservice.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: starterservice
                port:
                  number: 8168