【问题标题】:Dynamic Stateful routing (inter µ-service affinity) in Kubernetes / IstioKubernetes / Istio 中的动态有状态路由(微服务间关联)
【发布时间】:2020-09-01 22:29:36
【问题描述】:

我有一个通用 Java 微服务(“DB 服务”)的 ReplicaSet,它可以基于元数据与任何 JDBC 数据库交互。当上游微服务调用这个数据库微服务时,它会分配一个 JDBC 连接池。假设数据库 DBA 为我提供了 50 个连接以用于特定用例(我的系统可以“执行”的一些元数据部署单元)。

我希望有两个数据库副本,每个副本在本地连接池中创建 25 个连接 (MAX / 2)。从今以后,上游微服务现在应该只将它的调用路由到这两个副本,这两个副本现在包含这两个连接池,同时绕过其他没有创建任何连接的 X DB 副本。

如果上游微服务为此用例添加了唯一的 HTTP 标头(“StatefulRoute=ConnectionName”),K8s 和/或 Istio 是否会被欺骗将请求路由到已创建这些本地 JDBC 的 DB 副本的子集这个用例的连接池?

请注意,随着时间的推移,用户可以部署许多其他用例,每个用例可能还需要 JDBC 连接。这些用例应该基于已经繁忙的数据库副本的就绪检查传播到其他数据库副本。

我设想一个额外的资源管理器微服务(导体),每个 DB 副本都将与之交互以询问 1)我可以为此请求分配一个连接池,2)我可以分配多少个连接。

当第一个(未初始化的)数据库副本收到新请求(尚未建立路由)时,它将与资源管理器交互。然后,该管理器应动态配置 K8s / Istio(REST 调用?),以便今后将请求(针对特定用例)路由到此副本。

资源管理器将是一个 Singleton,或者如果它成为瓶颈,一个 ReplicaSet 使用分布式缓存来跟踪“连接池授权”。如果连接用完了,它将 ping 数据库副本,这些副本有一段时间没有发送心跳(可能已被 K8s 重新启动)。如果它发现一个副本没有响应,它将允许一个新的新副本根据剩余的可用连接(在数据库端)分配一个连接池。

如果所有先前初始化的副本仍然存在并为请求提供服务(因此最大物理数据库连接正在使用中),管理器将拒绝连接请求,然后请求的数据库副本将返回错误(“不再可用于服务请求的连接”)到上游微服务。

有人遇到过这个要求吗?

这不是用户会话亲和性,通常涉及入口。这涉及到集群内两个微服务之间的亲和性。

谢谢。

【问题讨论】:

  • 如果我理解正确,您是在问 istio 是否可以发送带有标头 StatefulRoute=ConnectionName 的请求,比如说您的 pod 的版本 1?
  • 是的,不知何故,我需要为我的 pod 版本动态创建一个“子集分布集”,这些版本创建了一个有状态连接池。例如,“Connection1DB2”将被路由到版本 1 和 3,而“Connection2Oracle”将被路由到版本 2 和 4 - 如果所述版本已服务于初始(随机路由)请求并因此成为“选择”创建的版本连接池。由于我永远不知道用户将在集群上“部署”哪些用例(程序流),因此我无法预先配置任何这些。谢谢。

标签: kubernetes routes istio stateful affinity


【解决方案1】:

如果您想配置 istio 流量路由,可以遵循的链接很少。

首先我会看一下bookinfo example,它很容易安装,您可以尝试对其进行设置。

然后按照这个关于 request routing 的 istio 文档进行操作,它解释了如何使您的虚拟服务和目标规则与您的 pod 的正确子集相匹配。

正如提到的herehere,我们可以在那里学习如何添加您的标头,该标头将用于将流量路由到您的pod 的适当版本。


看看这个例子

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
  ...
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v1

所以我们有 3 个审核部署子集,v1、v2 和 v3 以及为它们提供的服务。您可以在这里查看how 它已构建,每个审核部署都有一个应用程序和版本标签,我们可以在我们的虚拟服务和目标规则中使用它们。

kubectl get pods
reviews-v1-874083890-f0qf0                  2/2       Running   0          6m
reviews-v2-1343845940-b34q5                 2/2       Running   0          6m
reviews-v3-1813607990-8ch52                 2/2       Running   0          6m

kubectl get services
reviews                    10.0.0.170   <none>        9080/TCP             6m

正如您在上面的虚拟服务中看到的,如果有一个最终用户名恰好是 jason 的用户,那么它将整个流量发送到 v2,如果没有,则默认情况下它将所有内容发送到 v1。

【讨论】:

  • 感谢您的建议!
猜你喜欢
  • 2020-02-29
  • 2016-04-11
  • 2014-09-25
  • 2021-06-20
  • 2020-06-01
  • 1970-01-01
  • 1970-01-01
  • 2020-10-09
  • 1970-01-01
相关资源
最近更新 更多