How to make a predefined Kustomization yaml work after create the git source

[hatzhang]

I am trying to play fluxcd without using bootstrap. I am using install and create source git command to connect fluxcd to my git repo, like the following.

$ flux install --version=master
$ flux create source git myrepo ...

Then i use create kustomization command .

$ flux create kustomization staging \
    --source=myrepo \
    --path="./clusters/staging" \
...

And under staging folder, i have two files.

$ ls
kustomization.yaml  stagingrelease.yaml

$ cat kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

commonLabels:
  env: staging
  app: accounting

bases:
  - ../../base/apps
 
$ cat stagingrelease.yaml
apiVersion: kustomize.toolkit.fluxcd.io/v1beta1
kind: Kustomization

metadata:
  name: apprelease
  namespace: flux-system
spec:
  interval: 5m
  path: "."
  prune: true
  validation: client
  sourceRef:
    kind: GitRepository
    name: myrepo

It worked. But i am expecting in some way, a Kustomization with the name apprelease will be created by fluxcd. But i only got a Kustomization created by command line.

$ k get ks --all-namespaces
NAMESPACE     NAME        READY   STATUS                                                              AGE
flux-system   staging   True    Applied revision: master/1aaa2953e58e9081a7c1cdf8d3e2d2535fa27f8a   27m

So what am i missing here? Is there a way to tell fluxcd to use the predefined kustomize ? How to connect the command created Kustomization to a predefined yaml?

[stefanprodan]

The path is relative to the source root, see here an example https://github.com/fluxcd/flux2-kustomize-helm-example/blob/main/clusters/staging/apps.yaml

[hatzhang]

With the path in the yaml modified to path: "./clusters/staging" , and clear fluxcd with flux uninstall --crds, and rerun the previous commands, the result does not change. Still can't get a ks named apprelease. So how to trigger the predefined Kustomization without using flux create kustomize?

[kingdonb]

In a folder with a kustomization.yaml, only files referenced as bases or resources will be synchronized. If you placed stagingrelease.yaml next to kustomization.yaml then it makes sense it wasn't applied, since it wasn't referenced in kustomization.yaml.

If you want to apply arbitrary YAML files, you have to do it in a directory that does not include kustomization.yaml.

Try moving these two files into separate directories and see if that helps. Alternatively, you could list the other YAML files you want to apply as resources in the kustomization, or put them in a base listed by the kustomization.

Kustomize controller will apply arbitrary yaml files from the selected directory, if the directory is missing kustomization.yaml – these are two different, and unfortunately somewhat confusing, operating modes of the kustomize controller in flux.

[hatzhang]

By arrange the folder structure to the following, and make some adjustment to the path defined, i got two ks now.

$ tree .
.
├── apps
│   └── kustomization.yaml
└── stagingrelease.yaml
$ cat apps/kustomization.yaml | grep bases --after-context=2
bases:
  - ../../../base/apps
$ cat stagingrelease.yaml | grep path
  path: "./clusters/staging/apps"  

The two ks is like this:

$ k get -n flux-system ks
NAME         READY   STATUS                                                              AGE
apprelease   True    Applied revision: master/d1f57eb3fd2ff8c8269a643b33aa873e0ec5ffe9   18m
bjstaging    True    Applied revision: master/d1f57eb3fd2ff8c8269a643b33aa873e0ec5ffe9   40h

But now i am not so sure about what each ks for. Let's say the base/apps defines a helmrelease. And if i uninstall the release mannually using helm uninstall, and then do flux reconcile kustomization apprelease, the helm installation won't come back; instead if do flux reconcile kustomization bjstaging which is created by flux cli, the helm installation will come back.
So does this mean apprelease is useless? I do add a patchesJson6902 to apprelease and it won't patch.

[yebyen]

When you have a helmrelease cr that maps to a Helm release, and you uninstall Helm release with helm delete or helm uninstall as you described, the helmrelease custom resource is the thing that brings it back to life.

I'm not sure I understand your question but whatever that helmrelease is named, it will still be on the cluster, and reconciling that object will do the helm install again.

Reconciling the parent kustomization shouldn't have any effect on downstream helmrelease objects unless they have been changed in the kustomization source.

[yebyen]

https://blog.sldk.de/2021/02/introduction-to-gitops-on-kubernetes-with-flux-v2/ This article shows exactly how kustomization are applied (and explained nicely for me why we call it "kustomize-controller" and not "plain yamls controller" when it's commonly used not just for Kustomize, but also for just applying plain yamls.)

Here’s a simplified walk-through of how the kustomize-controller is going to install our k8s resources.

Checkout the configured branch from ssh://[email protected]/${username}/cluster-name
Change the working directory to the specified path: ./cluster
Build a root Kustomize yaml at this location if no explicit one is available:

kustomize create --autodetect --recursive > kustomization.yaml

So you see, the root path that Flux applies uses Kustomize too, with autodetection and recursing enabled.