基于 Kubernetes 服务的 HTTP 标头的一致性哈希答案

【问题标题】：Consistent Hashing based on HTTP header for Kubernetes Service基于 Kubernetes 服务的 HTTP 标头的一致性哈希
【发布时间】：2021-01-19 12:47:49
【问题描述】：

我有一个名为 orderProcessor 的 K8s 服务，有 5 个 pod。基于orderId HTTP 请求标头，我想将 HTTP 调用路由到特定的 pod。

例如：

带有orderId ABC 的requestId 应该总是去Pod A，而带有orderId PQR 的requestId 应该总是去Pod B

如果 pod A 关闭并被 Pod C 替换，那么所有带有 orderId ABC 的请求都应该转到 Pod C。

基本上，对于相同的 header 值，请求应该总是在同一个 pod 中结束。

这在服务级别上可行吗？如何做到这一点？

【问题讨论】：

你能分享你当前的配置吗？你已经尝试过什么？我们需要有关您的用例的更多详细信息，以便能够为您提供帮助。
在服务级别上是不可能的。 Kubernetes 服务工作在第 4 层，因此没有“HTTP 标头”的概念。您可能在第 7 层的入口控制器上运气更好，并且至少应该具备执行您要求的技术能力。有许多 Ingress Controller 实现支持基于 cookie 的粘性会话（例如 nginx，但根据您的描述，它并不是您想要的
入口控制器将流量传递给服务而不是 Pod，因此它也无济于事。我发现，配置为反向代理的常规 nginx pod 和作为后端端点的 StatefulSet pod 的组合可以解决问题。 StatefullSet 中的每个 pod 在 Kubernetes DNS 服务中都有自己的永久名称和 A 记录，因此您可以在 nginx 配置中参考 pod 名称。

【解决方案1】：

这是一个社区 wiki 答案。随意扩展它。

正如在 cmets 中已经提到的，无法在服务级别对其进行配置，因为它在没有“HTTP 标头”概念的第 4 层上运行。

替代方法是为该任务选择合适的Ingress 控制器。例如，您可以选择：

请记住，不同的控制器支持不同的注释集，因此如果您将它们混合在一起，其中一些将无法满足。您可以找到上述here 和here 之间的一些关键区别。

编辑：

包括来自 cmets 的 VASャ建议：

我侦察，一个普通的 nginx pod 的组合配置为反向代理和 StatefulSet pod 作为后端端点可以做诡计。 StatefullSet 中的每个 pod 都有自己的永久名称和 A 记录在 Kubernetes DNS 服务中，所以你可以参考 nginx 中的 pod 名称配置。

【讨论】：