For at least some of the ingress controllers out there, 2 variables must be supplied: POD_NAME and POD_NAMESPACE. The nginx ingress controller makes sure to inject these 2 variables in the container(s) as seen here (link for Azure deployment templates), HAProxy is using it (as shown here) and probably others are doing it as well.
I get why these 2 values are needed. For the nginx ingress controller the value of the POD_NAMESPACE 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 --watch-namespace parameter (the Helm chart showing this in action is here). As for POD_NAME, not having this will cause some errors in the ingress internal code (the function here) which in turn will probably prevent the ingress from running without the variables set.
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 "powerful" 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 "whoami" and get its own data? Or is this perhaps a common pattern used across Kubernetes?
It is done by design, a community that develops this functionality as it approaches the subject.
When the environment variable is started, the variables are known. Kubernetes provides these variables and pod can use them when runs.
Of course, if you have a better idea to solve this, you can suggest it in the official thread on github.
However, bare in mind that this potential solution:
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 "powerful" 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 "whoami" and get its own data? Or is this perhaps a common pattern used across Kubernetes?
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.