helmfile sync vs helmfile применить 

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 Readme выяснить разницу между helmfile sync а также helmfile apply. Похоже, что в отличие от команды apply, команда sync не выполняетdiff а также helm upgradeчерт возьми из всех выпусков. Но от словаsync, вы ожидаете, что команда применит те выпуски, которые были изменены. Также упоминается о потенциальном примененииhelmfile applyпериодической синхронизации релизов. Почему бы не использоватьhelmfile syncдля этого? В целом, разница не стала кристально очевидной, и я подумал, что, вероятно, это могло быть больше. Итак, я спрашиваю.

Источник

4 ответа

Решение

Рассмотрим вариант использования, когда у вас есть задание Jenkins, которое запускается каждые 5 минут, и в этом задании вы хотите обновить свою диаграмму управления, но только при наличии изменений.

Если вы используете helmfile sync который вызывает helm upgrade --install каждые пять минут вы будете увеличивать версию диаграммы каждые пять минут.

$ 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 этого не произойдет.

Источник

В остальных ответах все правильно. Однако есть еще одна важная вещь, которую нужно понять с vs:

  • syncбуду звонить по всем релизам. Таким образом, для каждого выпуска будет создан новый секрет руля, и все ревизии выпусков будут увеличены на одну. Helm 3 использует трехсторонний стратегический алгоритм слияния для вычисления исправлений, что означает, что он вернет ручные изменения, внесенные в ресурсы в активном кластере, обрабатываемые Helm;
  • apply сначала будет использовать плагин helm-diff, чтобы определить, какие выпуски были изменены, и будет запускать только helm upgradeна измененных. Однако helm-diff сравнивает только предыдущее состояние Helm с новым, оно не принимает во внимание состояние активного кластера . Это означает, что если вы что-то изменили вручную (или, точнее, плагин helm-diff), возможно, это не обнаружит и оставит как есть.

Таким образом, если вы всегда изменяете живой кластер через helm, helmfile applyэто путь. Однако, если вы можете вносить изменения вручную и хотите убедиться, что текущее состояние согласовано с тем, что определено в Helm / helmfile, тогда helmfile sync это необходимо.

Если вам нужны более подробные сведения, моим сообщением в блоге ознакомьтесь сhelmfile: разница между синхронизацией и применением (Helm 3)

Источник

Проще говоря , вот как они оба работают:

  • звонки

  • звонки helm upgrade --installтогда и только тогда, когда возвращает некоторые изменения.

Так что, в общем, это будет быстрее, и я предлагаю использовать его большую часть времени.

Но учтите, что если кто-то удалил какие-либо deploymentс или configmaps вручную с диаграммы, helm diffследовательно, никаких изменений не будет, helmfile applyработать не будет и эти ресурсы все равно будут удалены, а helmfile syncвоссоздаст его, восстанавливая исходную конфигурацию диаграммы.

Источник

Мы обнаружили одну существенную проблему, которая также имеет значение.

Иногда операция или может завершиться неудачей из-за:

  • Тайм-аут с wait: true. Например, кластеру k8s необходимо добавить больше узлов, и операция занимает больше времени, чем ожидалось (но в конечном итоге все развернуто).
  • Временная ошибка на postsyncкрюк.

В этих случаях простая повторная попытка задания развертывания конвейера решит проблему, но последовательная helmfile applyпропустит оба helm upgradeи выполнение хука, даже если релиз находится в статусе failed.

Итак, мои выводы:

  • applyобычно быстрее, но может привести к ситуациям, когда требуется ручное управление (вне логики CI/CD).
  • syncболее надежен (удобен для CI/CD), но обычно медленнее.
Источник
Другие вопросы по тегам