[Feature] Better way of disabling pod proxy vars injection
- Dominant language
- TypeScript
- Stars
- 2.1k
- Forks
- 395
- Avg merge
- 4d 15h
- Merged PRs (30d)
- 14
Description
### ETA: Currently no ETA
Note: This is an estimate and is subject to change
---
**Is your feature request related to a problem? Please describe.**
Since recently an AKS cluster can be configured in-place with proxy vars, so without recreating the whole cluster.
This is a very nice feature especially so that nodes do not need direct internet access. As an additional effect the proxy vars are also injected into all pods. That can be countered by adding the annotation `"kubernetes.azure.com/no-http-proxy-vars":"true"` to a pod.
This feels very cumbersome to do when the goal is to only inject those vars into the nodes.
**Describe the solution you'd like**
Separated proxy settings for nodes and pods.
That would open up the possibility to set the proxy vars only for nodes and leave pods without the injection.
**Describe alternatives you've considered**
- Alternatively, less cumbersome would be the option to turn off the pod proxy vars injection on namespace level by adding the possibility to configure the annotation on the namespace level.
This would avoid having to add the annotation to each pod.
- An option to configure the injection to pods or nodes or both. This seems less flexible compared to having a separate config for nodes and pods.
**Additional context**
Additionally observed behavior:
The pods injection into a pod is not necessarily always a problem since when proxy vars were set already they are not overwritten, but additional versions are added (e.g. when HTTPS_PROXY was set already it is not overwritten but https_proxy, http_proxy and HTTP_PROXY will be set, same for no_proxy/NO_PROXY). Depending on the framework / tool / library some of the other vars might "win" compared to what was set beforehand, so turning of the injection is most probably the way to go.
As mentioned we are able to turn off the injection but a less cumbersome way would be very nice.
Contributor guide
Assessment
This issue has not been assessed yet.