Add a full kustomize resource

[jsravn]

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

I'm currently using https://www.pulumi.com/registry/packages/kubernetes/api-docs/kustomize/directory/. However it's quite limited because we can't override values like you normally would on the command line with kustomize set namespace=, etc. or your own kustomization.yaml file referring a remote resource.

Instead of simply taking a directory, it would be a lot more useful if the kustomize resource could take an object which represents a kustomization.yaml itself. Then users can specify all possible options.

So something like:

new kubernetes.kustomize.Kustomization("my-kustomize",
  {
	  resources: ["my-kustomize-project/config/default", "https://example.com/my-remote-kustomize" ],
	  namespace: myNamespace.metadata.name,
	  images: [{
        name: "controller",
        newName: "myimage",
        newTag: "latest",
      }],
      // etc.
  }

So basically, just allow specifying a kustomization.yaml equivalent in-line. This would give full customization over a kustomize project.

Affected area/feature

[danielbichuetti]

This is a really useful feature. Without being able to edit the kustomization.yaml, it restricts some fundamental principles of automation. Or maybe a way to use transformations on the kustomization.yaml file.

[EronWright]

This does seem like a useful feature.

We should keep in mind the design principle of Kustomize (from Eschewed Features), that informed the simplistic design of the Directory resource.

kustomize supports the best practice of storing one’s entire configuration in a version control system.

Changing kustomize build configuration output as a result of additional arguments or flags to build, or by consulting shell environment variable values in build code, would frustrate that goal.

kustomize insteads offers kustomization file edit commands. Like any shell command, they can accept environment variable arguments.

This sentiment is also echoed here.

I would advocate for a new resource type, e.g. Kustomize as described by the OP, to generate and apply a Kustomization. One could argue that the Pulumi program itself is the source-controlled artifact, and that the Kustomization is derived from that.