问题描述
正在使用Flux自动将git仓库中的Helm Release部署到Kubernetes集群。当他直接编辑生成的deployment对象的spec（使用k9s或kubectl edit，例如，暂时尝试不同版本的容器镜像）时，Kubernetes将无需停机即可滚动部署新的Pod。他想知道如何撤销这样的更改，即如何触发更新deployment（以及其他对象），以使其与hr匹配，同时不中断服务。
如果他手动删除hr，则服务将短暂地下线，然后他可以重新运行Flux流水线来重新创建它。如果他在git仓库中进行了实质性的更改，那么修改将在没有停机的情况下自动部署，但是重新运行包含无关紧要提交的流水线似乎不能刷新deployment。
解决方案
请注意以下操作可能涉及版本差异及风险，务必在实施前做好备份。
在处理这种情况时，我们可以考虑几种方法来使Helm在不中断服务的情况下更新Deployment。
方法1：更改Helm Chart版本
在Helm的Chart.yaml中，有一个版本字段。如果你进行了不重要的提交，可能不会更新这个版本，因此Flux可能认为它不需要做任何操作。尝试更改版本可能会是一个解决方法。
方法2：检查配置
为了避免停机问题，请仔细检查你的配置。你是否在安装时使用了replace策略？是否使用了强制更新？这些策略会在更新前删除部署，这可能导致停机问题。
方法3：使用命令进行同步
你可以在CI流水线中运行命令fluxctl sync，这会在任何git push/merge时登录到Kubernetes集群并执行同步操作。同时，Flux守护程序/代理也会定期检查并执行同步操作。如果git仓库由Helm Releases组成，Flux应该会确保集群中的hr与仓库中的保持一致。但Flux不会影响在仓库中没有直接表示的任何集群对象。相反，Helm负责确保集群具有与hr匹配的部署（然后，部署控制器负责确保存在与部署规范匹配的Pod）。
方法4：手动删除和同步
如果你不想进行新的提交，只有短暂的停机，可以尝试以下步骤：
1. 使用命令kubectl delete hr foo删除hr（foo是你的hr名称）。
2. 运行命令fluxctl sync来执行同步。
方法5：使用Helm回滚命令
如果只有部署（而不是hr）发生了变化，可以尝试以下方法：
1. 使用命令helm rollback foo <latest-revision>来回滚部署（foo是你的部署名称，是最新的修订版本）。
方法6：使用kubectl回滚命令
如果部署仅被编辑了一次，可以使用命令kubectl rollout undo deploy foo来回滚部署（foo是你的部署名称）。
通过尝试这些方法，你应该能够在不中断服务的情况下更新Deployment并解决问题。
请注意，根据情况的不同，选择合适的方法。在实施前，务必根据你的环境和流程进行测试，并在操作前进行适当的备份。