背景
我们目前正在使用持续交付管道，在管道的最后，我们将生成的Docker镜像与最新的应用程序配置（在启动Docker容器时设置为环境变量）一起部署到某些服务器。持续交付构建号用作Docker映像的版本，并且它当前也是部署到服务器的此版本。
有时我们需要更新应用程序配置（环境变量）并重用现有的Docker镜像。今天，我们只需使用更新的配置部署现有的Docker镜像。
现在我们正在考虑改用Kubernetes而不是我们的家庭解决方案。因此，如果我们的持续交付管道生成的版本号也反映为Kubernetes中的pod版本（即使我们部署了当前部署但具有不同环境变量的相同版本的Docker镜像），对我们来说也不错。
问题：
我已阅读rolling-update的文档，但它并未表明您可以执行滚动更新，仅更改与pod关联的环境变量没有改变它的版本。
答案 0 :(得分：2)
滚动更新只是缩小一个replicationController并扩展另一个。因此，它会以受控速率删除旧的pod并制作新的pod。因此，如果新的复制控制器json文件具有不同的env变量和相同的图像，那么新的pod也将具有该变量。
事实上，即使您没有更改json文件中的任何内容，除了一个标签值（您必须更改某个标签），您将获得具有相同图像和环境的新窗格。我想你可以用它来进行滚动重启吗？
您可以选择在进行滚动更新时要更改的标签。没有正式的Kubernetes概念“版本”。如果需要，您可以制作一个名为“版本”的标签，或“contdelivver”或其他任何标签。
我想如果我在你的鞋子里，我会看两个选择：
选项1：在rcs上放置（至少）两个标签，一个用于docker镜像版本（其中，IIUC也是连续交付版本），另一个用于“环境版本”。这可能是一个git提交，如果你将你的环境变量存储在git中，或者更随意的东西。所以，你的pod可能有像“imgver = 1.3，envver = a34b87”这样的标签，或类似的东西。
选项2：将当前最知名的复制控制器存储为版本控制中的json（或yaml）文件（git，svn，whatevs）。然后使用版本控制中的修订号作为单个标签（例如“version = r346”）。这与您的持续交货标签不同。 它是pod的整个配置的标签。