首页 > 解决方案 > 具有任意数量 pod 的 Kubernetes 集群中的 Cosmos DB 更改源

问题描述

我的 Cosmos 数据库中有一个集合,我想观察它的变化。我有很多文件(官方和非官方)解释如何做到这一点。但有一件事我无法以可靠的方式工作:当我没有任何共同的实例名称参考时,如何接收对多个实例的相同更改?

我这是什么意思?好吧,我在 Kubernetes 集群 (AKS) 中运行我的工作负载。我在集群中有可变数量的实例应该观察我的集合。为了使更改源正常工作,我必须为每个实例设置一个唯一的实例名称。我唯一的候选者是 pod 名称。它通常以<deployment-name>-<random string>. 例如pod-5f597c9c56-lxw5b

如果我使用 pod 名称作为实例名称,所有实例都不会收到相同的更改(这是我的要求),只有一个实例会收到更改(请参阅https://docs.microsoft.com/en-us/azure/ cosmos-db/change-feed-processor#dynamic-scaling)。我可以做的是使用 pod 名称作为提要名称,然后所有实例都会得到相同的更改。这就是我害怕在某个时候会咬我的东西;当窥视租赁容器时,我可以看到每个提要名称的一组文档。随着 pod 名称的出现和消失(名称的随机字符串部分),我担心容器会随着时间的推移而增长,从而产生一堆垃圾。我知道 Cosmos 可以处理巨大的工作量,但你知道,我喜欢保持整洁。

我怎样才能保持这东西干净整洁?我真的不想发明(或为此重用!)我的实例之间的一些协议来投票选择哪个实例从有限的名称集中获得哪个名称。

一个“简单”的解决方案是构建我自己的实例名称,如果 AKS 或 Kubernetes 为我的 pod 保存某种“索引”。我知道有状态集给了我这个,但我不想使用有状态集,因为 pod 本身并不是真正有状态的(除了这个特定方面!)。

标签: kubernetesazure-cosmosdbazure-aksazure-cosmosdb-changefeed

解决方案


有一个新的Change Feed 拉模型(目前处于预览阶段)。

区别在于:

更改提要推送模型与更改提要处理器

在您的情况下,您似乎不需要并行化(您希望所有实例都接收所有内容)。重要的部分是设计一个可以维护延续令牌的状态存储模型(或者不,如果 pod 出现故障然后重新启动,您可能不关心继续)。


推荐阅读