Migrate to Flux v2 #413
Replies: 7 comments 15 replies
-
|
Utility snippet for removing the finalizers: {
for resource in kustomization gitrepository helmrelease helmrepository; do
for item in $(kubectl get ${resource} -n gotk-system -o jsonpath='{.items[*].metadata.name}'); do
kubectl -n gotk-system patch $resource $item -p '{"metadata":{"finalizers":null}}' --type=merge
done
done
} |
Beta Was this translation helpful? Give feedback.
-
|
As the big area of "image update functionality" is nearing completion (80% done, 2021-02-03), the image update migration guide is looking for feedback and early testing. If you are interested in this area, please go check it out. |
Beta Was this translation helpful? Give feedback.
-
|
We are getting closer to a request-for-testing period, before we call it GA. What are relevant steps we want to take in the next weeks?
|
Beta Was this translation helpful? Give feedback.
-
|
do live migration from v1 to v2 on youtube or zoom call maybe |
Beta Was this translation helpful? Give feedback.
-
|
https://www.meetup.com/GitOps-Community/events/276539791/ cc @staceypotter and @stealthybox |
Beta Was this translation helpful? Give feedback.
-
|
👋 Hot off the press is this 📺 video by Leigh (@stealthybox) on Migrating from Flux v1 -> v2: https://youtu.be/vwvTwLQhXVI |
Beta Was this translation helpful? Give feedback.
-
|
The "Migrate from .flux.yaml and kustomize" doc looks great! Are there any plans to write one for a generic generator "flux.yaml", for example if using a custom command to generate manifests? |
Beta Was this translation helpful? Give feedback.
-
|
I see, thanks for the response! So the only path to using Flux v2 if we have a custom manifest generation script is to build our own controller, similar to the Kustomization Controller? |
Beta Was this translation helpful? Give feedback.
-
|
I am preparing a suite of example GitHub Actions that do manifest generation to cover several well-known The decision at this point is, if you need some manifest generation that is above and beyond what Kustomize and envsubst provide, it should be done on a CI platform and published through a git branch. You can use any custom binary that you want in a CI job, we will publish further additional examples for different CI platforms as time and broadly expressed interest dictates. |
Beta Was this translation helpful? Give feedback.
-
|
The CI approach makes sense, its what I'm currently pursuing as well; the main question is how to support multiple different environment branches. Presumably the CI job will have to commit generated manifests to some branch, and Flux configured to pick them up; but if there are MULTIPLE environment branches it seems unclear how to set this up. Thanks for the response! |
Beta Was this translation helpful? Give feedback.
-
|
Indeed it is more complicated that way, and most users probably will have multiple environments so this is not a scenario that we can ignore. The guide is WIP in https://github.com/fluxcd/flux2/pull/1083/files There are several note/hint callouts that are intended to lead you in the direction of a better solution for this, but I'm afraid it's still not very clear and the PR needs more work to merge. |
Beta Was this translation helpful? Give feedback.
-
|
The section at the bottom is titled "Adapting for Flux v2" and has the examples that are closest to what Flux v2 canonically recommends; the examples in the body of the guide are more focused on making things work as closely to how they work in Flux v1. There is an example that uses
(edit: I wrote this statement above out of reflex, but it is questionable. I do not think environment branches are the recommended way to handle multi-cluster in Flux v2.) ... and you can use either manifest gen techniques to write the commit to deploy into each branch like the guide describes, or use Flux v2 I think this is where Kustomization bases and resource references are meant to be used to solve the problem in the most modern/updated way, without environment branches. |
Beta Was this translation helpful? Give feedback.
-
|
Hi . I am having a hard time in setting up flux on my Mac using bootstrap. when I try to run bootstrap command I get a health check error as below. Am I okay to ignore this ? ◎ waiting for Kustomization "flux-system/flux-system" to be reconciled |
Beta Was this translation helpful? Give feedback.
-
|
Sorted out here #1265 It was a transient error due to slow network. |
Beta Was this translation helpful? Give feedback.
-
|
Hi... I use flux 1 in a very basic way, I have a deployment yaml file with the image provided by you guys on dockerhub and with some Is it possible to have something like that working with flux2? Any links to deployment files I could use as an example? |
Beta Was this translation helpful? Give feedback.
-
|
The bootstrap guide shows how to do this, it is more moving parts than before, but what you get with bootstrap that you don't get with What you want is a single GitRepository and a single Kustomization that applies whatever yaml file or files you push in the git tree. Bootstrap provides the example, it produces two files, one is called "gotk-sync" We recommend the bootstrap guide, or Getting Started guide, for Flux beginners because it teaches these important concepts that you can't use Flux without. However, as more complicated setups are explained in follow-on links that appear at the end of the Getting Started guide, you don't need to follow them if what you want is just what you described. You can simplify and pare down instead of scaling up. The simplest Flux v2 installation is just |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for all the migration guides. They all look great! 👍 |
Beta Was this translation helpful? Give feedback.
-
|
I'll just add a couple of points to clarify our motivation and issues. We're managing quite a bit (100s) of resources by Flux and we're not quite comfortable migrating all of them to Flux v2 at once, esp. in production. Hence we're trying to run both v1 and v2 in parallel and gradually migrate manifests from v1 to v2. The issue we're seeing with this approach though is that (sometimes) flux v1 tries to delete resources which are being taken over by flux v2, which causes disruption. The process is something like this
When flux v1 starts back up and discovers that some of the manifests are not there, while resources are still present, it removes them. As a workaround, we're considering removing the Perhaps, it's much simpler and I'm just missing some docs. |
Beta Was this translation helpful? Give feedback.
-
|
The You could use If you are using deprecated features like Lots of effort was placed on the migration documents, but there could still be gaps. If I was to suggest where issues are most likely to come from, it will be from incompletely migrating, running both versions side-by-side, which is a configuration I personally haven't tested very well together or very long, or well enough to know where the worst edge cases are likely to be encountered. Not to mince words, I would recommend solving all issues in a staging environment, then completing the migration at once when all known issues are solved. While possible, it's strictly not recommended to run both Flux v1 and Helm Operator + Flux v2 and Helm Controller all together, and I wouldn't really recommend doing so in production for very long, if even at all. I've tried to focus more on gaining the relevant experience with Flux v2 so that I can support the migration for users of Flux v2 and advertise all of the relevant features there, with as little emphasis as possible on the old versions. We have tried to make sure the migration is smooth and that all important use cases are addressed by it, so folks can get all the way on Flux v2. As a consequence, there is simply less attention on issues related to running Flux v1 even from myself, the lead primarily responsible for Flux v1 maintenance. Transparently, my most important goal is to get everyone off the boat first. |
Beta Was this translation helpful? Give feedback.
-
|
@kingdonb thanks for your quick response, much appreciated. 🙌 |
Beta Was this translation helpful? Give feedback.
-
Migrate from Flux v1
If you are using Flux v1, please consider retooling your CD pipelines with flux2.
Starting with flux2 v0.8, the default controllers and their APIs are considered stable and production ready, please see the roadmap for a more details.
To find out what differences are between v1 and v2 please read the FAQ.
Flux guides
.flux.yamland kustomizeHelm guides
Beta Was this translation helpful? Give feedback.
All reactions