In Flux v1, it was possible to set up incoming webhooks withįlux-recv as a sidecar to Flux, which while it worked nicely, it isn’t nicely integrated and frankly feels bolted-on, sort of like an after-market part. In Flux v2, this can actually be used as a real strategy it is straight-forward to implement and covered by documenation: That sounds great, but is not really how things work in Flux v1.
#SHOULD I GET F LUX UPDATE#
There is an idealized use case of GitOps we might explain as: when an update comes, a pull-request is automatically opened and when it gets merged, it is automatically applied to the cluster. When there is a fault, the new design allows that other processes should not be impacted by the fault. One Kustomization can fail reconciling, or one GitRepository can fail syncing (for whatever reason including its own configurable timeout period), without interrupting the whole Flux system.Īn error is captured as a Kubernetes Event CRD, and is reflected in the Status of the resource that had an error. The effect of this circumstance is a complete Denial-of-Service for changes to any resources managed by Flux v1 - it goes without saying, this is very bad.įailures in Flux v2 are handled gracefully, with each controller performing separate reconciliations on the resources in their domain. If manifest generation takes too long, timeout errors in Flux v1 can pre-empt the main loop and prevent the reconciliation of manifests altogether. Flux v2 only expects cluster operators to run one source-controller instance, allowing to manage multiple repositories, or multiple clusters (or an entire fleet) with just one Flux installation.įundamentally, Flux v1 was one single configuration and reconciliation per daemon process, while Flux v2 is designed to handle many configurations for concurrent resources like git repositories, helm charts, helm releases, tenants, clusters, Kustomizations, git providers, alert providers, (… the list continues to grow.) Flux v2 is more reliable and observableĪs many advanced Flux v1 users will know, Flux’s manifest generation capabilities come at a heavy cost.
Sortable image tags (this is a breaking change.)įlux v1 requires one Flux daemon to be running per git repository/branch that syncs to the cluster. That’s right, rate limiting undoutedly happened because of abusive clients pulling image metadata from many images (like Flux v1 did,) images that might only be stored for the purpose of retention policies, that might be relegated to cold storage if they were not being periodically retrieved. This came to a head when Docker Hub started rate-limiting image pulls, because of the expense of this operation performed casually and at scale. Flux v2, but it was judged by the maintainers that the design of Flux importantly required some breaking changes to resolve some key architectural issues.įlux v1 implementation of image automation has serious performance issues scaling into thousands of images. One can debate the design choices made in Flux v1 vs. Some architectural issues in the original design of Flux weren’t practical to resolve, or weren’t known, until after implementations could be attempted at scale. While there are many Flux v1 users in production, and some of them are running at very large scales, Flux users with smaller operations or those that haven’t needed to scale maybe didn’t notice that Flux v1 actually doesn’t scale very well at all. There are some great reasons to follow the Flux organization’s latest hard work and consider upgrading to Flux v2: Flux v1 runtime behavior doesn’t scale well We hope that Flux users can all be persuaded to upgrade. Why should I upgradeįlux v2 includes some breaking changes, which means there is some work required to migrate. Automated deployment of new container imagesįrequently asked questions Migrate to Flux v2įlux v1 is in maintenance on the road to becoming formally superseded by Flux v2.
0 kommentar(er)
