时间戳

首页 > 解决方案 > 使用专有供应商更新 Kubernetes 中的 StatefulSet？

kubernetes - 使用专有供应商更新 Kubernetes 中的 StatefulSet？

问题描述

我无法正确理解 Kubernetes，但我们的应用程序依赖于专有的闭源供应商，而后者又依赖于 Solr。我已经阅读了有关使用 StatefulSets 滚动更新的文章，但它们似乎依赖于应用程序意识到并考虑新的模式版本，如果不反编译和跳过很多圈子，我们就无法做到这一点。让我描述一下我们正在尝试做的事情：

WebService Version 1 需要升级到 WebService Version 2，这个升级不是我们的代码，只是我们的代码依赖的供应商代码。把它想象成更新操作系统。

但是，WebService 版本 1 依赖于 Solr 版本 1。托管模式不同，并且 Solr 版本 1 和 2 之间存在重大更改。Solr 版本和模式都不同。如果 WebService 版本 1 遇到 Solr 版本 2，它将无法工作，或者更糟糕的是运行中断 Solr 版本 2。反过来也是如此，如果我们更新 WebService 版本 2 并且它获得 Solr 版本 1，它将破坏它。

我唯一能想到的就是让 Kubernetes 基本上为每个版本启动一个 pod，并且在 WebService 和 Solr 都启动 2 之前不降低 1。

这似乎不对，我理解正确吗？

标签： kubernetes

解决方案

似乎Solr 的金丝雀发布策略所暗示的只是拥有一个新的 StatefulSet，其标签与之前版本的标签相同。

由于标签可以分配给许多对象和网络级别，服务基于这些路由请求，因此请求将被重定向到两个 StatefulSet，模拟金丝雀发布模型。

按照这个逻辑，你可以有一个v1 StatefulSet，比如8个副本，另一个v2 StatefulSet有2 个。因此，大约 80% 的请求应该命中v1，大约 20% v2（实际上并非如此，只是为了说明）。

从那里，您可以使用每个副本的数量，StatefulSet直到您“推出” 100% 的副本v2，而无需停机。

现在，如果您以上述方式标记每个二重奏（应用程序 + Solr 版本），这可以在您的场景中工作。

每个二人组将收到约 N% 的请求，具体取决于它拥有的副本数量。您可以慢慢减少副本的数量*duo* v1并增加下一个更新版本。

这种方法的缺点是使用更多资源，因为您将运行完整应用程序堆栈的两个版本。但是，升级整个堆栈时没有停机时间，您可以控制“推出”的百分比。

推荐阅读