我们开始使用 Helm 管理 Kubernetes 资源，并且我们有一些用户习惯使用 来管理资源kubectl edit。我们希望 Helm 每次运行时都能清理已部署的资源，使其恢复到已知的良好状态。
我观察到它helm upgrade不会覆盖我的 ConfigMap。相反，它会合并已部署的 ConfigMap 和 Helm 模板之间的属性，从而为我提供模板化的 ConfigMap 和手动编辑的 ConfigMap 的片段。如果 Helm ConfigMap 模板中没有更改，Helm 会不是将我部署的 ConfigMap 的任何部分重置回已知良好状态。
我如何指示 Helm 始终将我的整个 Kubernetes 资源重置为 Helm 模板版本？
答案1
这不是 Helm 的设计目标，并且仍然不是。操纵非 Helm 创建的对象或忽略其“控制”下的对象的带外更改不属于 Helm 的职权范围 - 这项功能使 Helm 与其他可能更改清单的系统兼容，并使 Helm 可以安全使用。请记住，它是一个 YAML 渲染系统，而不是像 Puppet 或 SaltStack 这样的配置管理系统。它不会“强制”配置。
如果您希望实现您描述的行为，您可以在使用 Helm 重新创建相关对象之前删除它们。您可以使用 Kubernetes 命名空间来可靠地实现此目的，方法是为每个图表赋予自己的命名空间，并在图表安装之前删除命名空间作为“硬重置”的形式。
或者让那些习惯使用 编辑清单的用户kubectl不要这样做，而是指导他们将更改推送到图表或值中。如果需要进行更改，则丢弃这些更改似乎不合理 - 这正是 Helm 首先对清单执行三向合并操作的原因。我理解希望将配置保留在单点编排中的愿望，但不要指望通过不使用单点编排来实现这一点。
当将更高级别的编排实践应用于习惯于较低级别编排方法的团队时，这个问题始终会出现，并且从概念上来说，它绝不局限于 Helm。Helm 擅长通过执行合并操作来优雅地处理这种情况，但会导致编排方法运行混乱（至少它不会破坏事物或简单地失败）。首先不要制造混乱，或者将混乱限制在临时环境中，并将其收集到 Helm 图表中以供生产。