Show dependencies of a kustomization

[mbrt]

Eschewed features

• This issue is not requesting templating, unstuctured edits, build-time side-effects from args or env vars, or any other eschewed feature.

What would you like to have added?

Given a kustomization.yaml file, I would like to use an API in kustomize that tells me which kustomizations this file depends on and which local files.

Why is this needed?

In my current company, we have a large repository containing Kubernetes configuration for ~hundreds of applications in ~hundreds of environments using Kustomize. Dependencies between overlays, components, patches grew hairy and take many minutes (>30) to build.

We are trying to:

• Provide tooling to debug and understand why an overlay depends on another
• Provide tooling to understand the impact of a change during a PR

Can you accomplish the motivating task without this feature, and if so, how?

We can iterate over all overlays and run kustomize build for all of them, before and after a change is applied. This has a couple of problems:

• It takes about an hour for every change (we have >6k changes a week).
• If an unrelated kustomization is temporarily broken, this process would fail, even though it has nothing to do with the particular PR being processed.

What other solutions have you considered?

I'm trying to implement this myself, but it's quite cumbersome and not future-proof. Parsing a kustomization file is easy, but maintaining the mapping between all its fields and whether they may or may not point to a file or kustomization directory is prone to being incomplete.

Anything else we should know?

It seems that KustTarget contains all the logic of what to load, where to load it from, etc. From a superficial overview, it seems that:

• This information could be exposed by KustTarget.
• It could be plumbed and exposed by the kustomizer.Krusty official API?

Feature ownership

• I am interested in contributing this feature myself! 🎉

[k8s-ci-robot]

This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.