How is / can the order between resources in gitops repo controlled?

[punkle]

Hi, This might be a bit of a naive question, please point me at the correct documentation and I'll be happy to read it.

I have a gitops repo, and flux2 deployment. In the git ops repo I have defined an ExternalSecret resource, in another I have defined a HelmRelease resource for the kubernetes-external-secrets service.

The kubernetes-external-secrets helm chart provides the ExternalSecret CRD. The kustomize logs fails with:

unable to recognize "40a6f75a-0baa-4f5c-8e8f-3ef99bcc85e8.yaml": no matches for kind "ExternalSecret" in version "kubernetes-client.io/v1

There is a dependency between these two resources. How can/should I express this dependency so as to fix this error?

[stefanprodan]

With Flux you can split your manifests into layers, for example an infra layer that gets deployed before the apps layer. The reconciliation order can be controlled using dependsOn.

Here is an example repo if you want to take a look https://github.com/fluxcd/flux2-kustomize-helm-example#bootstrap-staging-and-production

[punkle]

Brilliant, thanks @stefanprodan this is exactly what I needed.

[BuckinghamIO]

I think this idea of using dependsOn: for ordering really needs some more thought.

On the face of it it works but it does end up making for a kind of convoluted and messy file structure when you want to make things reusable or add subsitution (Which breaks after 1 layer of Kustomize.toolkit heirarchy)

Has there been more thought on better dependency management within Flux at all since this original post.

I have Cert-Manager, External Secrets both with this issue.

It gets complicated when I have resources which are in my initial layer which require ExternalSecret resources.

So I end up with something such as:

External Secrets (HelmRelease, namespace etc)
External Secret CRD resources (generating k8s secrets used further up) (Depends on initial layer)
Env (Ingress, Kafka, Prometheus, Cert-Manager etc)
Configs (More External Secrets, Configmaps etc, Cert manager Certificates) Depends on ENV, cause of Cert manager.
Apps (All our containers etc which use the External Secrets 1 level below)

If there was a way to have dependency ordering inside the kustomize.source or something this would be so much cleaner

[o6uoq]

I'm unaware of a graceful way to do this other than dependsOn and DIY scripting.

[matheuscscp]

A common way to do this is exemplified here: https://github.com/fluxcd/flux2-kustomize-helm-example/blob/main/clusters/production/infrastructure.yaml

It is common to have the following groups:

• controllers (installs CRDs)
• configs (applies CRs)
• apps

The controllers usually don't depend on each other and can be applied together in the same Flux Kustomization.

The configs i.e. CRs depend on the existence of the respective CRDs, so they need to come a second Kustomization.

Then finally apps depend on the configs, also can be deployed together.