我想这很难放在组织外部的人能够理解的环境中，因为 k8s 架构有很大不同。
我们对服务使用蓝/绿部署，并使用 helm 生成要应用的 k8s 对象。
所以当我们正常部署新版本时，我们会生成k8s目标文件，包括service、deployment和hpa。这些都是“彩色”物体，指向新的交替角色。
我们应用 hpa 和部署对象，然后推出新的部署对象，然后将服务上的“角色”标签设置为新颜色，然后将服务上的“角色”标签设置为新颜色，然后然后我们将旧的部署缩减到零个 Pod。在正常部署中，这会神奇地使 HPA 完成其工作，并扩展到 HPA 中指定的最小 Pod 数量。这一切工作正常。
上面描述的这些步骤实际上是在两个单独的 Jenkins 构建中执行的，第一个我们称为“DEPLOY”构建，第二个我们称为“SWITCH_LIVE”。 “DEPLOY”构建仅创建 k8s 对象并进行推出，但不会更改活动颜色。 “SWITCH_LIVE”就是这样做的。
当我们尝试进行“回滚”时，问题就出现了，我认为我们可以通过简单地对 SWITCH_LIVE 作业进行 Jenkins“重放”来实现。在我们的上下文中，这意味着我们只需更改为替代颜色，即当前活动颜色之前的活动颜色。我的理论是，当我们更改“角色”标签并更改选择器时，当前活动颜色的 HPA 将启动，并生成最小数量的 pod。我看到的是，在我们更改部署中的标签和选择器后，没有任何反应。
如果我同时重播“DEPLOY”作业和“SWITCH_LIVE”作业，它基本上会达到预期的效果，但该策略的问题是 DEPLOY 作业会执行其他操作，例如重新生成所有 k8s 对象和应用程序配置图。这并不像我想要的那么少。
然后我发现，如果我只是重播 SWITCH_LIVE 作业，然后手动重新应用新颜色的部署对象，即使没有任何更改，它也会突然开始操作并开始创建新颜色的 pod。
虽然这可行，但我需要一种方法让 SWITCH_LIVE 作业自动执行此操作。在 SWITCH_LIVE 作业中，正如我提到的，我当前仅更新服务对象的角色和选择器，并且不对新的部署对象执行任何操作。是否有一些在正常操作中无害的东西会“推动”部署或 HPA 执行其需要执行的操作？