kubernetes - 是否可以进行滚动更新并在Kubernetes中保留相同版本？

Question

背景:

我们当前使用的是持续交付管道，在管道的最后，我们将生成的Docker镜像以及最新的应用程序配置(在启动Docker容器时设置为环境变量)部署到某些服务器上。连续交付内部版本号用作Docker镜像的版本，并且当前也是部署到服务器的此版本。

尽管有时我们需要更新应用程序配置(环境变量)并重用现有的Docker镜像。今天，我们只需部署具有更新配置的现有Docker镜像即可。

现在，我们正在考虑切换到Kubernetes，而不是我们自己构建的解决方案。因此，如果我们将持续交付管道生成的版本号也反射(reflect)为Kubernetes中的Pod版本(即使我们部署了当前部署的相同版本的Docker镜像，但具有不同的环境变量)，那对我们来说将是很好的。

问题:

我已经阅读了rolling-update的文档，但这并不表示您可以进行滚动更新，而只能更改与pod关联的环境变量，而无需更改其版本。

这可能吗？

有解决方法吗？

这是我们应该完全避免的事情，并且使用更“库伯尔网络友好”的其他方法吗？

Answer 1

滚动更新只是按比例缩小了一个ReplicationController，而按比例放大了另一个。因此，它将以受控的速率删除旧的 pods 并制作新的 pods 。因此，如果新的复制 Controller json文件具有不同的环境变量和相同的镜像，则新的容器也将具有该变量。

实际上，即使您不更改json文件中的任何内容，除了一个标签值(您必须更改一些标签)之外，您也将获得具有相同图像和环境的新容器。我想您可以使用它来滚动重启？

滚动更新时，您可以选择要更改的标签。 Kubernetes没有正式的“版本”概念。您可以根据需要创建一个名为“版本”的标签，也可以创建一个“contdelivver”标签。

我想如果我穿上你的鞋子，我会考虑两种选择:

选项1 :(至少)在rcs上放置两个标签，一个用于docker镜像版本(IIUC也是连续交付版本)，另一个用于“环境版本”。如果您将环境变量存储在git中，则可能是git commit，或者更随意。因此，您的广告连播可能带有“imgver = 1.3，envver = a34b87”之类的标签。

选项2:将当前最知名的复制 Controller 存储为版本控制(git，svn，whatevs)中的json(或yaml)文件。然后将版本控制中的修订号用作单个标签(例如“version = r346”)。这与您的连续交付标签不同。
它是 pods 整个配置的标签。