New answers tagged

0

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 ...


0

Be aware that there you can have also this message with some charts when using helm 3 < 3.7.0 Reference: https://github.com/nextcloud/helm/issues/163


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 ...


0

Recommended way is to have an agent on the target host that would do the deployment. Possible options include Argo or Flux. Generally, ssh'ing from CICD pipeline into target host especially with Bastion or Jump Host infrastructure is insecure. Note that it is recommended to push the helm chart itself to the registry as well and treat it same way as container ...


Top 50 recent answers are included