Add new built-in transformer for resource-quotas (requests/limits)

[evemorgen]

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?

To improve the management of pod resource quotas, I propose adding a new built-in transformer to the Kustomize tool. This transformer will simplify the process of setting resource requests and limits for pods within Kubernetes manifests.

Currently, Kustomize supports a multitude of built-in transformers for common use cases including ReplicaCountTransformer, ImageTagTransformer, etc. Another common use case we often run into is overriding pod resource quotas (requests/limits) - currently done with patching - however, it would be much nicer and make manifests more readable to use a built-in transformer for that.

An example implementation could be:

kustomization.yaml

...
resourceQuotas:
  - name: some-deployment
     requests:
         memory: 1250Mi
         cpu: 100m
     limits:
         memory: 3000Mi
         cpu: 500m 

Why is this needed?

It would provide a more user-friendly simplified syntax to achieve the common task of setting appropriate resource quotas for pods.

By implementing this transformer, Kustomize users will benefit from a more convenient and streamlined approach to managing pod resource quotas. It will simplify the process of setting requests and limits, especially when dealing with a large number of pods or multiple environments.

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

This can be currently done with both inline patch and patch strategic merge.

An example would be:

kustomization.yaml

...
patchesStrategicMerge:
- patch.yaml

patch.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: some-deployment
spec:
  template:
    spec:
      containers:
        - name: some-deployment
          resources:
            limits:
              memory: 1250Mi
            requests:
              memory: 1250Mi

What other solutions have you considered?

I briefly research if it could be done with existing tools but couldn't find an elegant solution.

Anything else we should know?

No response

Feature ownership

• I am interested in contributing this feature myself! 🎉

Thank you for considering this enhancement proposal. I look forward to hearing your thoughts and collaborating on this feature addition.

[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/test-infra repository.

[seh]

The "replicas" field is already hard to use for anything but the simplest kustomizations. The new field proposed here would pose the same problem: To which manifests does this patch apply? Once you learn the answer, you then start asking how to exclude some manifests from its too-broad coverage.

[natasha41575]

For use cases such as this, I would highly recommend you first experiment by writing your own custom transformer. If we see broad adoption of particular custom transformers, we can consider making them builtin.

I'd like to be careful about broadening the scope of builtin transformers and instead prioritize making it easy for users to write their own custom ones. This will help keep kustomize flexible, powerful, and maintainable.

[evemorgen]

Thanks @natasha41575, that makes a lot of sense. I'll try this approach.