<p>For at least some of the ingress controllers out there, 2 variables must be supplied: <code>POD_NAME</code> and <code>POD_NAMESPACE</code>. The nginx ingress controller makes sure to inject these 2 variables in the container(s) as seen <a href="https://github.com/kubernetes/ingress-nginx/blob/402f21bcb7402942f91258c8971ff472d81f5322/deploy/static/provider/cloud/deploy.yaml#L349-L356" rel="nofollow noreferrer">here</a> (link for Azure deployment templates), HAProxy is using it (as shown <a href="https://www.haproxy.com/blog/dissecting-the-haproxy-kubernetes-ingress-controller/" rel="nofollow noreferrer">here</a>) and probably others are doing it as well.</p>
<p>I get why these 2 values are needed. For the nginx ingress controller the value of the <code>POD_NAMESPACE</code> variable is used to potentially restrict the ingress resource objects the controller will be watching out for to just the namespace it's deployed in, through the <code>--watch-namespace</code>  parameter (the Helm chart showing this in action is <a href="https://github.com/kubernetes/ingress-nginx/blob/402f21bcb7402942f91258c8971ff472d81f5322/charts/ingress-nginx/templates/controller-deployment.yaml#L99" rel="nofollow noreferrer">here</a>). As for <code>POD_NAME</code>, not having this will cause some errors in the ingress internal code (the function <a href="https://github.com/kubernetes/ingress-nginx/blob/402f21bcb7402942f91258c8971ff472d81f5322/internal/k8s/main.go#L91" rel="nofollow noreferrer">here</a>) which in turn will probably prevent the ingress from running without the variables set.</p>
<p>Couldn't the ingress controller obtain this information automatically, based on the permissions it has to run (after all it can watch for changes at the Kubernetes level, so one would assume it's &quot;powerful&quot; enough to see its own pod name and the namespace where it was deployed)? In other words, can't the ingress controller do a sort of &quot;whoami&quot; and get its own data? Or is this perhaps a common pattern used across Kubernetes?</p>

Mihai Albert
<p><strong>It is done by design</strong>, a community that develops this functionality as it approaches the subject.</p>
<p>When the environment variable is started, the variables are known. <a href="https://kubernetes.io/docs/tasks/inject-data-application/environment-variable-expose-pod-information/" rel="nofollow noreferrer">Kubernetes provides these variables</a> and pod can use them when runs.</p>
<p>Of course, if you have a better idea to solve this, you can suggest it in the official thread on <a href="https://github.com/kubernetes/ingress-nginx/issues" rel="nofollow noreferrer">github</a>.</p>
<p>However, bare in mind that this potential solution:</p>
<blockquote>
<p>Couldn't the ingress controller obtain this information automatically, based on the permissions it has to run (after all it can watch for changes at the Kubernetes level, so one would assume it's &quot;powerful&quot; enough to see its own pod name and the namespace where it was deployed)? In other words, can't the ingress controller do a sort of &quot;whoami&quot; and get its own data? Or is this perhaps a common pattern used across Kubernetes?</p>
</blockquote>
<p>will require an extra step. Firstly, pod will have to have additional privileges, secondly, when it is started, it will not have these variables yet.</p>
