kustomize-controller: Expose image field in the kustomization resource

[phillebaba]

Being able to use Kustomize image patching in the kustomize.fluxcd.io.Kustomize resource would be a useful feature. In cases where the Kustomization referenced is not owned by the end user, it would allow overriding of those images. This could also be useful for the work being done with automatic image updates.

The change would require a API spec change with an additional field.

apiVersion: kustomize.fluxcd.io/v1alpha1
kind: Kustomization
metadata:
  name: backend
spec:
  interval: 5m
  path: "./webapp/backend/"
  prune: true
  sourceRef:
    kind: GitRepository
    name: webapp
  healthChecks:
    - kind: Deployment
      name: backend
      namespace: dev
  timeout: 2m
  images:
    - name: postgres
      newName: my-registry/my-postgres
      newTag: v1

Alternatively we could allow overriding many other Kustomization fields in the resource, under its own field.

apiVersion: kustomize.fluxcd.io/v1alpha1
kind: Kustomization
metadata:
  name: backend
spec:
  interval: 5m
  path: "./webapp/backend/"
  prune: true
  sourceRef:
    kind: GitRepository
    name: webapp
  healthChecks:
    - kind: Deployment
      name: backend
      namespace: dev
  timeout: 2m
  override:
    images:
      - name: postgres
        newName: my-registry/my-postgres
        newTag: v1
    commonLabels:
      someName: someValue

I don't know how far it would be sane to go with the overrides though. If for example json patching would be allowed or now.

[stefanprodan]

Proposal: Patch kustomization.yaml for image updates

An alternative would be for the image update automation to patch the kustomization.yaml in Git. This way we don't have to override kustomize fields in the Kustomization CRD.

apiVersion: image.fluxcd.io/v1alpha1
kind: ImageUpdateAutomation
metadata:
  name: update-app
spec:
  gitRepository:
    name: app-repo
  update:
    imagePolicy:
      name: app-policy
    kustomization:
      path: "./deploy/overlays/dev" # <- kustomize edit set image app=app:semver

[phillebaba]

If we do it this way, would we not be able to extrapolate this information from the source ref and Kustomization resource? Or this may not be possible if the image update controller is running in a different cluster. I just feel like its a bit verbose to specify teh kustomization path both in the Kustomizer resource and the ImageUpdateAutomation resource.

It would be nicer if the image update process was a bit more "aware" of HelmReleases and Kustomizations.

[squaremo]

These two proposals (Philip's, and Stefan's) serve different use cases.

In the first, the person with control over the syncing does not have control over the config repository -- they can only refer to it. So they must resort to putting changes into the sync.

In the second, the person with control of the syncing is also able to add a kustomization.yaml there.

I don't think the first is a good way to do automation, since it is applying the change to the definition of the syncing, and not to the configuration itself. That means the configuration is not the system of record -- you need the definition of how it's synced into the cluster to know the full picture. But it might be useful if you want to reuse a configuration that you don't have any control over.

[phillebaba]

To be honest an easier solution to now "owning" the config repo is to just have a separate kustomization.yaml that refers to the repo that the end user does not have control over. Works just as well and does not require any custom solution.