helmfile 同步與 helmfile 應用

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呢？ 總的來說，差異並沒有變得非常明顯，我認為可能還有更多。 所以，我在問。

Answer 1

考慮這樣一個用例，您有一個 Jenkins 作業每 5 分鍾觸發一次，並且在該作業中您想要升級您的掌舵圖，但前提是有更改。

如果您使用helmfile sync每五分鍾調用一次helm upgrade --install ，您最終將每五分鍾增加一次 Chart 修訂。

$ 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與apply ，還有一件重要的事情需要理解：

• sync將在所有版本上調用helm upgrade 。 因此，將為每個版本創建一個新的 helm secret，並且版本的修訂都將加一。 Helm 3 使用三向戰略合並算法來計算補丁，這意味着它將恢復對由 Helm 處理的實時集群中的資源所做的手動更改；
• apply將首先使用 helm-diff 插件來確定哪些版本已更改，並且僅對更改的版本運行helm upgrade 。 但是， helm-diff只是將之前的 Helm state 與新的 Helm 進行比較，並沒有考慮 live 集群的 state 。 這意味着如果您手動修改某些內容， helmfile apply （或更准確地說是 helm-diff 插件）可能無法檢測到它，並保持原樣。

因此，如果您總是通過 helm 修改 live 集群， helmfile apply是 go 的方式。 但是，如果您可以進行手動更改並希望確保實時 state 與 Helm/helmfile 中定義的內容保持一致，那么helmfile sync是必要的。

---

如果您想了解更多詳細信息，請查看我的博客文章helmfile：同步和應用之間的區別（Helm 3）

Answer 3

簡而言之，這就是它們的工作方式：

• helmfile sync調用helm upgrade --install

• helmfile apply調用helm upgrade --install當且僅當helm diff返回一些更改。

所以，一般來說， helmfile apply會更快，我建議大部分時間都使用它。

但是，請考慮一下，如果有人從圖表中手動刪除了任何deployment或configmap ，那么helm diff將不會看到任何更改，因此helmfile apply將不起作用並且這些資源仍將被刪除，而helmfile sync將重新創建它以恢復原始圖表配置。

Answer 4

我們發現了一個同樣具有影響的重大問題。

有時sync或apply操作可能會因以下原因而失敗：

• wait: true 。 例如，k8s 集群需要添加更多的節點，並且操作花費的時間比預期的要長（但最終一切都部署好了）。
• 后postsync掛鈎上的臨時錯誤。

在這些情況下，對管道的部署作業進行簡單的重試即可解決問題，但連續的helmfile apply將跳過helm upgrade和 hook 執行，即使 release 狀態為failed 。

所以我的結論是：

• apply通常更快，但可能導致需要手動（在 CI/CD 邏輯之外）的情況。
• sync更健壯（CI/CD 友好）但通常更慢。