只要相同的客户端通常路由到同一个pod，我就会很高兴 .
我坚持的观点：似乎Kubernetes服务模式意味着无论如何我的连接都会被随机代理 . 我可以使用会话亲和性配置我的Ingress控制器，但是一旦连接超过了它并点击服务， kube-proxy 就会随机路由我 . 服务上有 sessionAffinity: ClientIP 标志，但这对我没有帮助 - 客户端IP将始终是Ingress pod的内部IP .
kube-proxy
sessionAffinity: ClientIP
我错过了什么吗？鉴于Kubernetes目前的架构，这可能吗？
入口控制器可以完全绕过kube-proxy . 例如，haproxy控制器，does this and goes straight to endpoints . 不过它doesn't use the Ingress in the typical sense .
你可以do the same with the nginx controller，你只需要查找 endpoints 并插入它们而不是它当前使用的DNS名称（即交换this line作为指向包含 endpoints 的上游的指针） .
我评估了haproxy控制器，但无法使用会话亲和性使其可靠运行 . 经过一些研究后，我发现Nginx Ingress Controller，因为版本0.61还包括nginx-sticky-module-ng模块，现在在我们的测试环境中运行了几天 . 我创建了一个Gist来设置所需的Kubernetes部分，因为一些重要的配置在现有文档中有点难以找到 . 祝好运！
2 回答
入口控制器可以完全绕过kube-proxy . 例如，haproxy控制器，does this and goes straight to endpoints . 不过它doesn't use the Ingress in the typical sense .
你可以do the same with the nginx controller，你只需要查找 endpoints 并插入它们而不是它当前使用的DNS名称（即交换this line作为指向包含 endpoints 的上游的指针） .
我评估了haproxy控制器，但无法使用会话亲和性使其可靠运行 . 经过一些研究后，我发现Nginx Ingress Controller，因为版本0.61还包括nginx-sticky-module-ng模块，现在在我们的测试环境中运行了几天 . 我创建了一个Gist来设置所需的Kubernetes部分，因为一些重要的配置在现有文档中有点难以找到 . 祝好运！