ignore specified resource during adding namespace

[homily707]

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?

When a namespace is specified in kustomization.yaml, provide an option to exclude certain types of resources from being modified.

Why is this needed?

if specified namespace, any user defined resource (crd) will be set a namespace, however, a cluster scope CRD with namespace will cause a error.

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

No

What other solutions have you considered?

Add a ignoreGvks field in namespace transformer.
I have pulled a request to slove this, not sure is it a good way.
And I'm willing to help if this feature is accepted.

Anything else we should know?

this feature has been discussed in #552, but closed with no improvement.
there is a pr to slove this(maybe not right) #5431

Feature ownership

• I am interested in contributing this feature myself! 🎉

[natasha41575]

Kustomize currently uses openapi data to determine whether or not a resource is clusterscoped. I think rather than adding configuration to the namespaceTransformer to exclude resources (that will open the question of whether we should provide such an option to all transformers... which is a huge discussion doesn't seem to fit the issue here), we should look into better ways to specify crd information. There is a whole project around this described in #5123. You technically can currently add this information in the openapi field - kustomize uses the endpoints provided to infer whether or not a resource is namespaceable. Adding crds here is a pretty bad user experience at the moment so I understand why users don't want to do it or don't know how to.

We have discussed maybe allowing transformers to have GVK-level granularity but so far there hasn't been a use case for it. In the scenario that you've described here, we don't actually need GVK-level granularity; we just don't want it to apply to namespace-scoped CRDs. #5431 feels like a bandaid over the actual issue, and I would much rather see us address the issue holistically by making a good story around CRD support rather than patch in a workaround that exposes a much broader feature set than what is actually needed to support this use case.

To move #5123 forward, we need a design proposal for how we can make it easy to users to specify all the CRD information that kustomize needs (e.g. namespaceability, schemas, merge strategies) in an intuitive, user-friendly way. We would be more than happy to assist you in contributing there.

TL;DR I think this feature request is asking for a feature that is not a fit for the use case it describes; it is too broad/powerful in many ways and yet it doesn't actually address the overarching CRD issues. To adequately address the actual issue described here, we should improve crd support in kustomize through #5123.

/triage out-of-scope

[homily707]

thanks for your detailed explanation~