helmfile sync 与 helmfile apply

Question

sync      sync all resources from state file (repos, releases and chart deps)
apply     apply all resources from state file only when there are changes

同步

The helmfile sync sub-command sync your cluster state as described in your helmfile ... Under 
the covers, Helmfile executes helm upgrade --install for each release declared in the 
manifest, by optionally decrypting secrets to be consumed as helm chart values. It also 
updates specified chart repositories and updates the dependencies of any referenced local 
charts.

For Helm 2.9+ you can use a username and password to authenticate to a remote repository.

申请

The helmfile apply sub-command begins by executing diff. If diff finds that there is any changes
sync is executed. Adding --interactive instructs Helmfile to request your confirmation before sync.
An expected use-case of apply is to schedule it to run periodically, so that you can auto-fix skews
between the desired and the current state of your apps running on Kubernetes clusters.

我通过 Helmfile repo Readme 来找出 helmfile sync 和 helmfile apply 之间的区别。似乎与 apply 命令不同，sync 命令不会在所有版本中执行 diff 和 helm upgrade。但是从单词 sync 来看，您会期望该命令应用那些已更改的版本。还提到了 helmfile apply 在周期性发布同步方面的潜在应用。为什么不为此目的使用 helmfile sync？总的来说，差异并没有变得 crystal 清楚，而且我认为可能还有更多差异。所以，我问。

Answer 1

考虑这样一个用例，您有一个每 5 分钟触发一次的 Jenkins 作业，并且在该作业中您想要升级您的 helm chart，但前提是有更改。

如果您使用每五分钟调用一次 helm upgrade --install 的 helmfile sync，您最终将每五分钟增加一次图表修订。

$ helm upgrade --install httpd bitnami/apache > /dev/null
$ helm list
NAME    REVISION        UPDATED                         STATUS          CHART           APP VERSION     NAMESPACE
httpd   1               Thu Feb 13 11:27:14 2020        DEPLOYED        apache-7.3.5    2.4.41          default
$ helm upgrade --install httpd bitnami/apache > /dev/null
$ helm list
NAME    REVISION        UPDATED                         STATUS          CHART           APP VERSION     NAMESPACE
httpd   2               Thu Feb 13 11:28:39 2020        DEPLOYED        apache-7.3.5    2.4.41          default

因此，每个 helmfile sync 都会产生新的修订。现在，如果您要运行 helmfile apply，这将首先检查差异，然后（如果找到）才会调用 helmfile sync，后者又会调用 helm upgrade --install，这不会发生.

Answer 2

其他答案中的所有内容都是正确的。但是，sync vs apply:

还有一件重要的事情需要理解

sync 将在所有版本上调用 helm upgrade。因此，将为每个版本创建一个新的 helm secret，并且版本的修订将全部递增 1。 Helm 3 使用三向战略合并算法来计算补丁，这意味着它将恢复对由 Helm 处理的实时集群 中的资源所做的手动更改；
apply 将首先使用 helm-diff 插件来确定哪些版本发生了变化，并且只有运行 helm upgrade 在发生变化的版本上。但是，helm-diff 仅将以前的 Helm 状态与新的进行比较，不考虑实时集群的状态。这意味着如果您手动修改了某些内容，helmfile apply（或更准确地说是 helm-diff 插件）可能无法检测到它，并保持原样。

因此，如果您总是通过 helm 修改实时集群，helmfile apply 是可行的方法。但是，如果您可以手动更改并希望确保实时状态与 Helm/helmfile 中定义的一致，那么 helmfile sync 是必要的。

如果您想了解更多详细信息，请查看我的博客 post helmfile: difference between sync and apply (Helm 3)

Answer 3

简单来说，这就是它们的工作原理：

helmfile sync 呼叫 helm upgrade --install
helmfile apply 调用 helm upgrade --install 当且仅当 helm diff returns 一些变化。

所以，一般来说，helmfile apply 会更快，我建议大多数时候使用它。

但是，请注意，如果有人从图表中手动删除了任何 deployment 或 configmap，helm diff 将不会因此看到任何变化，helmfile apply 将不起作用，这些资源仍将被删除，而 helmfile sync 将重新创建它以恢复原始图表配置。

Answer 4

我们发现了一个同样具有影响的重大问题。

有时 sync 或 apply 操作会因以下原因而失败：

wait: true 超时。例如。 k8s 集群需要添加更多节点，运行时间比预期的要长（但最终一切都已部署）。
postsync 挂钩出现临时错误。

在这些情况下，对管道的部署作业进行简单重试即可解决问题，但连续 helmfile apply 将跳过 helm upgrade 和挂钩执行，即使发布处于状态 [=16] =].

所以我的结论是：

apply 通常更快，但可能导致需要手动（在 CI/CD 逻辑之外）的情况。
sync 更健壮（CI/CD 友好）但通常较慢。

helmfile sync 与 helmfile apply

helmfile sync vs helmfile apply

kubernetes

kubernetes-helm

helmfile