during on boarding of existing installed application flux doing reinstalling it again during reconciliation

[tanmoyrsc]

I want to on-board my existing application to fluxcd to maintain it through Fluxcd in future. the problem I found that when I adding Kustomization of the existing application to fluxcd, flux again doing re-installation of the application during reconciliation. Is there any way to skip the flux reconciliation for on boarding of existing application?

Br,
Tanmoy

[kingdonb]

It isn't clear what you are describing fits within the design of Flux or Kubernetes.

Can you clarify? Flux reconciles declarative artifacts, so the intended design and outcome is that the declarative artifact is a static definition of the intent, and reconciling it against the cluster should have no impact because the definition of the intent does not change itself after the intent is actuated by controller/operators that run on the cluster.

This is aligned with https://opengitops.dev which defines GitOps as a continuous reconciling process.

Can you be more specific about the application, what you mean by re-installation, and what is the impact of reconciling that you wish to avoid?

There are many cases where reconciling an entire resource is undesirable (for example, the persistent volume which has a section in the spec indicating whether that resource is already bound and details about what context binds it to the cluster, a given node, etc.) - those cases are generally handled in Flux using a field manager, so they can be reconciled continuously without creating any impact.

I'm suggesting there is an X-Y problem and we need to know more about your use case in order to help you solve it. You don't want Flux to skip reconciling, because then you won't be doing GitOps. You will lose the ability to correct drift, or apply new changes.

Flux doesn't distinguish between "old changes" and "new changes" - there is no way for Flux to detect that your new configuration is new and only reconcile it piecewise then when something has changed; the design is for continuous reconciliation.

There is an accommodation in Kustomize Controller's Kustomization reconciler for ignoring an unspecified part of the config, so you can have drift as long as it's not in conflict with the definition in Git, but I don't want to provide too many details until I am sure I understood what your issue is, (at the risk of confusing you further, here's what I mean): https://fluxcd.io/flux/components/kustomize/kustomizations/#controlling-the-apply-behavior-of-resources

[tanmoyrsc]

My objective is to gitops onboarding of manually deployed applications. For example I have a manually deployed application ABC running in k8s cluster. I created the Kustomizations of the ABC application and pushed to a git repository, after that I add the git repository as a git source of fluxcd. Now the issue is Fluxcd uninstall existing manually deployed ABC application and reinstall it during reconciliation.

Now expectation is flux will not reinstall/change the application until any changes pushed to git repository. is this possible to achieve?

[tanmoyrsc]

Hi Any update on this?

[stefanprodan]

Flux does not change objects in cluster unless their state in etcd drifts from what's in Git. I guess your manifests in Git are diffrent and that's why this happens.

Now the issue is Fluxcd uninstall existing manually deployed ABC application and reinstall it during reconciliation.

What do you mean by uninstall? There is no such thing in Flux, this is a Helm operation. Are you using HelmReleases?

[Gauravdeep1992]

Hi
I have tried an onboarding steps as mentioned below but facing an error during reconciliation
Step 1) I deployed nginx pod using helm-charts in K8s cluster and resulting , it came up and running.

Step 2) The next objective is to deploy or upgrade the same nginx-pod using same helm-chart and manifests (deployment.yaml and service.yaml) but by using a helm-release.yaml and gitrepository.yaml

But we are getting the below error

kubectl get helmrelease

NAME AGE READY STATUS
eiimp-nginx 13m False Helm upgrade failed for release default/eiimp-nginx with chart [email protected]: error while running post render on files: may not add resource with an already registered id: Deployment.v1.apps/eiimp-nginx.[noNs]

Step 3) Then we tried for upgradation just by uplifting the version in Charts.yaml then the upgrade was picked with version 0.1.1 but the error we got as below

kubectl get helmrelease

NAME AGE READY STATUS
eiimp-nginx 22m False Helm upgrade failed for release default/eiimp-nginx with chart [email protected]: error while running post render on files: may not add resource with an already registered id: Deployment.v1.apps/eiimp-nginx.[noNs]

So wish to know that this scenario is possible or doable in FluxCD or not i.e an already running k8s resource (pod or deployed) can be migrated on FluxCD without any downtime or not ? The expectation is an older pods which is running should not be restarted if we are using the exactly same manifests and charts on FluxCD

Request response on this query