helm upgrade 安装整个图表还是仅安装更改的清单
Does hem upgrade reinstall entire chart or only altered manifests
运行helm upgrade时，helm 是重新安装图表中的所有清单，还是仅重新安装已更改的清单？
我似乎找不到与此相关的任何文档。欢迎任何参考或文档。
提前致谢。
这些东西没有区别。 Kubernetes 是一个融合系统。
取决于您更新的对象的资源类型。
Helm 本身从不决定应该更新什么。它只是根据您的配置从模板生成对象并将它们应用到 Kubernetes。
现在，我们来谈谈 Kubernetes 如何处理对象。每个对象都有可以就地更新和不能就地更新的参数。
例如，在 Deployment 中您可以更新它的注释或标签，但是如果您要在 spec 中更新相同的值（这实际上是 [=12= 的模板） ]), 它将创建具有该值的新 RS，而新 RS 将创建新的 Pods.
因此，如果您调用 helm upgrade，例如，一个生成的对象具有一些无法在现有对象（就地）上更新的新值，那么 Kubernetes 将创建一个新对象来替换旧的。
这是您在升级过程中创建的每个对象的独立过程，因此一些对象将被替换（重新创建）而一些 - 不会。
Helm 仅针对它认为已更改的内容发送 Kubernetes 清单。
Helm 3 升级说明中对此进行了一些讨论，更具体地说 Improved Upgrade Strategy: 3-way Strategic Merge Patches:
Helm 2 used a two-way strategic merge patch. During an upgrade, it compared the most recent chart's manifest against the proposed chart's manifest (the one supplied during helm upgrade). It compared the differences between these two charts to determine what changes needed to be applied to the resources in Kubernetes. If changes were applied to the cluster out-of-band (such as during a kubectl edit), those changes were not considered. [...]
In Helm 3, we now use a three-way strategic merge patch. Helm considers the old manifest, its live state, and the new manifest when generating a patch.
这意味着如果您执行 kubectl scale deployment 或 kubectl edit deployment 之类的操作，特别是如果您使用的是 Helm 2，从 Helm 的角度来看，这可能会导致事情变得 "lost"：由于旧的 Helm 管理内容和建议的 Helm 管理内容相同，因此即使实时集群状态不同，它也不会发送更新。上面链接的升级说明中有一些具体示例。
实际上我发现这意味着两件事：
对于几乎所有设置，如果可以，请尝试通过 Helm 管理它们。不要使用 kubectl edit 对 Helm 管理的资源进行手动更改。 （kubectl scale 可能没问题，具体取决于您的部署过程的参与程度；HorizontalPodAutoscaler 之类的东西也会直接更改 replicas:。）
如果 Helm（至少第 2 版）感到困惑，您可能需要 helm del --purge 现有版本，然后再重新安装它。
运行helm upgrade时，helm 是重新安装图表中的所有清单，还是仅重新安装已更改的清单？
我似乎找不到与此相关的任何文档。欢迎任何参考或文档。
提前致谢。
这些东西没有区别。 Kubernetes 是一个融合系统。
取决于您更新的对象的资源类型。
Helm 本身从不决定应该更新什么。它只是根据您的配置从模板生成对象并将它们应用到 Kubernetes。
现在，我们来谈谈 Kubernetes 如何处理对象。每个对象都有可以就地更新和不能就地更新的参数。
例如，在 Deployment 中您可以更新它的注释或标签，但是如果您要在 spec 中更新相同的值（这实际上是 [=12= 的模板） ]), 它将创建具有该值的新 RS，而新 RS 将创建新的 Pods.
因此，如果您调用 helm upgrade，例如，一个生成的对象具有一些无法在现有对象（就地）上更新的新值，那么 Kubernetes 将创建一个新对象来替换旧的。
这是您在升级过程中创建的每个对象的独立过程，因此一些对象将被替换（重新创建）而一些 - 不会。
Helm 仅针对它认为已更改的内容发送 Kubernetes 清单。
Helm 3 升级说明中对此进行了一些讨论，更具体地说 Improved Upgrade Strategy: 3-way Strategic Merge Patches:
Helm 2 used a two-way strategic merge patch. During an upgrade, it compared the most recent chart's manifest against the proposed chart's manifest (the one supplied during
helm upgrade). It compared the differences between these two charts to determine what changes needed to be applied to the resources in Kubernetes. If changes were applied to the cluster out-of-band (such as during akubectl edit), those changes were not considered. [...]In Helm 3, we now use a three-way strategic merge patch. Helm considers the old manifest, its live state, and the new manifest when generating a patch.
这意味着如果您执行 kubectl scale deployment 或 kubectl edit deployment 之类的操作，特别是如果您使用的是 Helm 2，从 Helm 的角度来看，这可能会导致事情变得 "lost"：由于旧的 Helm 管理内容和建议的 Helm 管理内容相同，因此即使实时集群状态不同，它也不会发送更新。上面链接的升级说明中有一些具体示例。
实际上我发现这意味着两件事：
对于几乎所有设置，如果可以，请尝试通过 Helm 管理它们。不要使用
kubectl edit对 Helm 管理的资源进行手动更改。 （kubectl scale可能没问题，具体取决于您的部署过程的参与程度；HorizontalPodAutoscaler 之类的东西也会直接更改replicas:。）如果 Helm（至少第 2 版）感到困惑，您可能需要
helm del --purge现有版本，然后再重新安装它。