我无法正确理解Kubernetes，但是我们的应用程序依赖于专有的闭源供应商，而后者又依赖于Solr。我已经阅读了有关使用StatefulSets进行滚动更新的文章，但是它们似乎依赖于应用程序是否知道并考虑新的架构版本，而如果不对它们进行反编译和跳很多圈，我们将无能为力。让我描述一下我们要做什么：
WebService版本1需要升级到WebService版本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。
这似乎不正确，我是否正确理解了这一点？
答案 0 :(得分：0)
这并不是Kubernetes可以解决的真正问题。首先确定您将如何手动执行，然后可以开始确定如何使其自动化。如果需要零停机时间，我能想象到的最好的事情就是分别启动新的Solr集群，而不是进行就地升级，然后分别启动指向新Solr的新应用程序。但是您将需要弄清楚如何在升级期间在两个Solr集群之间实时同步数据。但是同样，Kubernetes在这里既无济于事，也无碍，问题不在于启动或管理容器，这是您体系结构中的后勤问题。
答案 1 :(得分：0)
canary release strategy with Solr的建议似乎只是拥有一个新的StatefulSet，其标签与上一个版本相同。
由于labels can be assigned to many objects和网络级别的服务基于这些请求路由请求，因此将发生的情况是，请求将被重定向到两个StatefulSet，从而模拟了Canary发布模型。
按照这种逻辑，您可以拥有一个v1 StatefulSet，例如， 8 个副本，另一个v2 StatefulSet，其具有 2 。因此，约80％的请求应该达到v1，约20％的v2（实际上并不是为了说明）。
从那里开始，您可以使用每个StatefulSet的副本数量，直到“推出” v2的副本的100％，而没有停机时间。
现在，如果您以上述方式标记每个二重奏（应用程序+ Solr版本），这将在您的情况下起作用。
每个二人组都会收到〜N％的请求，具体取决于其拥有的副本数量。您可以缓慢减少*duo* v1的副本数量，并增加下一个更新的版本。
这种方法的缺点是要使用更多资源，因为您将运行完整应用程序堆栈的两个版本。但是，升级整个堆栈时没有停机时间，您可以控制“推出”的百分比。