kubernetes 滚动更新期间 Akka 集群切换

Question

我一直在尝试使用推荐的rollingUpdate plus cluster

app-version

在kubernetes中部署akka集群，以便以最短的停机时间实现平稳部署。然而，切换过程会导致延迟增加以及部署期间的后续停机。

我当前使用的滚动更新配置是

maxSurge=1

和

maxUnavailable=0

。

我想了解移交是如何进行的以及

app-version

在此过程中的作用是什么，因为我找不到任何相关文档。

新版本上线后，消息是否仍会发送到旧分片？或者所有消息流向新版本是否会造成暂时的瓶颈？无论如何，是否可以对此进行改进以保证更高的可用性？任何想法或想法将不胜感激。

Answer 1

作为零

maxUnavailable

和正

maxSurge

滚动重新部署过程的一部分，具有新应用程序版本的节点将启动并加入集群。当它们加入集群时，分片协调器（集群单例，在集群中最旧的节点上运行）将注意到它们不负责任何分片，并将为它们分配分片（精确的算法是可配置的，以确定如何积极地分配分片）它会重新平衡并选择哪些碎片）。当选定的分片被移动时，发送到这些分片的消息将被缓冲。请注意，分片托管的实体将有序关闭：如果化身这些实体的参与者缓慢停止（例如，他们有“整理”工作要做），则分片关闭过程将在一段延迟后（通常是数十秒）秒，尽管这是可调的）以“不太有序”的方式执行：完成此操作后，分片将在新节点上启动，其他节点将刷新其缓冲的消息。

新节点报告健康后，Kubernetes 选择停止旧版本的节点。理想情况下，该节点能够优雅地离开集群：在这种情况下，它将放弃对其分片的责任，并且分片协调器会将分片分配给具有新

app-version

的节点（这实际上是

app-version

适用的地方） ：这可以防止分片在部署期间注定要被 Kubernetes 停止的节点上启动）。如果这是一次不正常的离开（而不是向所有其他节点宣布它要离开，而是其他节点判定它已经失败），那么其他节点上的裂脑解析器可能需要数十秒的时间才能将其关闭以及要重新创建的碎片。

在此过程中的某个时刻，托管分片协调器的节点将在滚动升级中停止，并且在一段延迟后，新的最旧节点将接管集群单例（包括分片协调器）。最好是最旧的节点是最后一个要停止的节点：那么责任将转移到下一个版本中要部署的第一个节点。 Kubernetes 过去常常按照正确的顺序大致停止节点：然而，最近的版本改变了这种启发式方法，降低了这种可能性，尤其是对于寿命较长的部署。最近发布的 BSL（非开源，仅提供源代码）Akka 添加了对 告诉 Kubernetes 它应该尽可能避免停止托管单例的节点 的支持：在生产中使用该模块需要来自 Lightbend（我的雇主）的许可证。

分片重新平衡期间的延迟峰值是可以预料的：托管分片的节点需要时间来重建状态（保持该状态是使用集群分片的原因）。您可以通过以下方式改善峰值（并非所有这些都可能适用于您的情况，并且这并不详尽）：

• 优化实体停止的时间
• 当每个分片有超过几十个实体时，不要使用“记住实体”，因为记住实体将按照不太可能与需要实体的顺序相关的顺序在新节点上启动实体参与者记住的实体将与所需的实体竞争资源
• 增加

  maxSurge

  ，尽管理想情况下这应该保持小于

  akka.cluster.min-nr-of-members

  （以防止新节点形成单独的集群）：除其他外，这可能会减少前几个新

  app-version

  节点的负载。
• 如果使用 Akka Persistence，“最大并发恢复”配置可能会限制实体 Actor 开始处理流量的速率：此设置是为了防止恢复使数据库过载，所以要小心。
• 如果事件源，特别是对于非常长寿的实体，更积极的快照可能会有所帮助（尽管我对大多数后端的经验是，即使快照之间有数千个事件通常也不会产生那么严重的影响，尽管与州规模相关的事件将与此相关）。