Hard-coded request.cpu 30m for statefulset prevents deployment in some cluster

[antoinetran]

What happened?

In an OpenShift cluster 4.15 with quota: minimal requests.cpu >= 50m, the deployment of statefulset fails.

What did you expect to happen?

Any statefulset deployment, that contains resource fields requests and limits, should not fail because of this error:

Error syncing to physical cluster: pods "my-nats-0-x-nats-x-my-vcluster" is forbidden: minimum cpu usage per Container is 50m, but request is 30m

How can we reproduce it (as minimally and precisely as possible)?

Deploy nats with helm chart, or really any statefulset, in an OpenShift cluster with with quota: minimal requests.cpu >= 50m

Anything else we need to know?

https://github.com/loft-sh/vcluster/blob/v0.20.0-alpha.4/pkg/controllers/resources/pods/translate/hosts.go#L50 specifies the hard-coded value of 30m.
Linked to #372
Recommended solution:
Add a way in values.yaml of vcluster to specify the resource field for this special initContainer that vcluster runs for each statefulset deployment.

Host cluster Kubernetes version

$ kubectl version
Client Version: v1.28.5
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.28.2-3580+6216ea1e51a212-dirty

Host cluster Kubernetes distribution

OpenShift 4.15, linked to Kubernetes version 1.28.

vlcuster version

$ vcluster --version
vcluster version 0.20.0-alpha.4

Vcluster Kubernetes distribution(k3s(default)), k8s, k0s)

k8s

OS and Arch

Linux, but I don't know exactly which distribution is used in the cluster.
OS: 
Arch:

[antoinetran]

Anyone sees a workaround? I thought about applying a limitrange, but the fact that vcluster specifies the requests/limits override that limitrange. I don't see a way of editing the vcluster image, because it is written in GO, and it's a compiled language. I can't even patch the initContainer because when it is not schedulable, it does only appear on kubectl events, but not as a Kubernetes resource.

[FabianKramm]

@antoinetran thanks for creating this issue! Yes we should add an option for this, I agree