<p>Say you have a CI pipeline that, upon any git push/merge, logs into a kubernetes cluster and runs the command <code>fluxctl sync</code> (and then uses <code>kubectl rollout status</code> on each deployment object, to wait for completion before following up with tests). The flux daemon/agent itself may also check and perform syncs periodically (as well as checking container registries for new image tags to commit to the manifests in the repo).</p>
<p>Presuming that the git repo consists of helm releases, then flux should ensure that the hr's in the cluster are kept consistent with those in the repo. But flux shouldn't affect any cluster objects that are <em>not</em> directly represented in the repo. Instead, <em>Helm</em> is responsible for ensuring the cluster has deployments matching the hr's. (And then, the deployment controller is responsible for ensuring pods exist matching the deploy spec.)</p>
<p>The flux sync apparently does nothing if the git head commit hasn't changed (or even if the changes in the repo do not appear significant?). If you are unwilling to engineer a new commit, an option with only brief downtime would be: <code>kubectl delete hr foo</code> then <code>fluxctl sync</code>.</p>
<p>Presuming that only the deployment (rather than the hr) has been mutated, another possibility may be to issue <code>helm rollback foo &lt;latest-revision&gt;</code> (although this isn't guaranteed to succeed cleanly).</p>
<p><em>If</em> the deployment has only been edited <em>once</em>, then <code>kubectl rollout undo deploy foo</code> is appropriate.</p>

CC BY-SA 4.0
2021-11-25T10:41:45.260Z
2021-11-25T10:41:45.260Z
benjimin
<p>Flux is pretty smart and has some built it mechanism to avoid unnecessary updates.</p>
<p>Helm has a version in the Chart.yaml, I'm assuming an inconsequential commit wouldn't update this version so flux might be assuming that it doesn't need to do anything. Changing the version would be something to try.</p>
<p>To avoid the downtime problems, you need to double check your configs. Are you using the replace strategy to the install? Are you using force updates?
Both of those strategies would delete the deployments before updating and that might be the cause of your downtime.</p>

CC BY-SA 4.0
2021-11-16T11:54:28.460Z
2021-11-16T11:54:28.460Z
Magus
<p>I am using Flux to automatically deploy a Helm Release from a git repository to a Kubernetes cluster. If I directly edit a resulting <em>deployment</em> object's spec (using <code>k9s</code> or <code>kubectl edit</code>, e.g. to temporarily try a different version of container image) then Kubernetes will roll out the new pods with no downtime. How can I revert such changes, that is, how can I trigger updating of the <em>deployment</em> (and other objects) to match the <em>hr</em>, without interrupting service?</p>
<p>If I manually delete the <em>hr</em> then the service will briefly go down before I can re-run the Flux pipeline to recreate it. If I materially changed the git repo, then the modifications would auto-deploy without downtime, but re-running the pipeline with inconsequential commits appears not to refresh the <em>deployment</em>.</p>

<kubernetes><helm>
Prodding Helm to refresh a deployment?
benjimin
# Prodding Helm to refresh a deployment?

(Asked by: username_0 on 2021-11-16)

I am using Flux to automatically deploy a Helm Release from a git repository to a Kubernetes cluster. If I directly edit a resulting *deployment* object's spec (using `k9s` or `kubectl edit`, e.g. to temporarily try a different version of container image) then Kubernetes will roll out the new pods with no downtime. How can I revert such changes, that is, how can I trigger updating of the *deployment* (and other objects) to match the *hr*, without interrupting service?

If I manually delete the *hr* then the service will briefly go down before I can re-run the Flux pipeline to recreate it. If I materially changed the git repo, then the modifications would auto-deploy without downtime, but re-running the pipeline with inconsequential commits appears not to refresh the *deployment*.

**Tags:** kubernetes, helm


---

## 2 answers

### Answer by username_0 on 2021-11-25. Score: 1

Say you have a CI pipeline that, upon any git push/merge, logs into a kubernetes cluster and runs the command `fluxctl sync` (and then uses `kubectl rollout status` on each deployment object, to wait for completion before following up with tests). The flux daemon/agent itself may also check and perform syncs periodically (as well as checking container registries for new image tags to commit to the manifests in the repo).

Presuming that the git repo consists of helm releases, then flux should ensure that the hr's in the cluster are kept consistent with those in the repo. But flux shouldn't affect any cluster objects that are *not* directly represented in the repo. Instead, *Helm* is responsible for ensuring the cluster has deployments matching the hr's. (And then, the deployment controller is responsible for ensuring pods exist matching the deploy spec.)

The flux sync apparently does nothing if the git head commit hasn't changed (or even if the changes in the repo do not appear significant?). If you are unwilling to engineer a new commit, an option with only brief downtime would be: `kubectl delete hr foo` then `fluxctl sync`.

Presuming that only the deployment (rather than the hr) has been mutated, another possibility may be to issue `helm rollback foo`  (although this isn't guaranteed to succeed cleanly).

*If* the deployment has only been edited *once*, then `kubectl rollout undo deploy foo` is appropriate.


---

### Answer by username_1 on 2021-11-16. Score: 0

Flux is pretty smart and has some built it mechanism to avoid unnecessary updates.

Helm has a version in the Chart.yaml, I'm assuming an inconsequential commit wouldn't update this version so flux might be assuming that it doesn't need to do anything. Changing the version would be something to try.

To avoid the downtime problems, you need to double check your configs. Are you using the replace strategy to the install? Are you using force updates?
Both of those strategies would delete the deployments before updating and that might be the cause of your downtime.


---

