You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
The sidecar is entirely unusable with a namespace where a ResourceQuota with hard limits has been enabled. The webhook does not set or have any capabilities to set such limits as far as I can see from the code, making it impossible to start a process where quotas are enforced.
Finally, deploy a workload identity-enabled pod with resources set to this namespace, with the proxy enable using azure.workload.identity/inject-proxy-sidecar: 'true'. It should fail to start and complain about quota errors as mentioned below.
Expected behavior
The proxy and init container will start without issues.
Logs
message: 'pods "<podName>" is forbidden: failed quota:
<resourceQuotaName>: must specify limits.memory for: azwi-proxy,azwi-proxy-init; requests.cpu
for: azwi-proxy,azwi-proxy-init; requests.memory for: azwi-proxy,azwi-proxy-init'
Network plugin and version (if this is a network-related bug): n/a
Others: n/a
Additional context
Istio accomplishes a similar end using the proxyCPU and proxyMemory settings via annotations passed in on the pod - perhaps such an approach is applicable here?
Describe the bug
The sidecar is entirely unusable with a namespace where a ResourceQuota with hard limits has been enabled. The webhook does not set or have any capabilities to set such limits as far as I can see from the code, making it impossible to start a process where quotas are enforced.
The code I'm referring to here:
Steps To Reproduce
Create a namespace and apply a ResourceQuota to it, for example:
Finally, deploy a workload identity-enabled pod with resources set to this namespace, with the proxy enable using
azure.workload.identity/inject-proxy-sidecar: 'true'
. It should fail to start and complain about quota errors as mentioned below.Expected behavior
The proxy and init container will start without issues.
Logs
Environment
kubectl version
): v1.29.2cat /etc/os-release
):uname -a
):Linux <nodeName> 5.15.0-1068-azure #77-Ubuntu SMP Fri Jun 21 21:21:03 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
Additional context
Istio accomplishes a similar end using the
proxyCPU
andproxyMemory
settings via annotations passed in on the pod - perhaps such an approach is applicable here?The text was updated successfully, but these errors were encountered: