Para al menos algunos de los controladores de entrada que existen, se deben proporcionar 2 variables: POD_NAME y POD_NAMESPACE . El controlador de entrada nginx se asegura de inyectar estas 2 variables en los contenedores como se ve aquí (enlace para las plantillas de implementación de Azure), HAProxy lo está usando (como se muestra aquí ) y probablemente otros también lo estén haciendo.
Entiendo por qué estos 2 valores son necesarios. Para el controlador de entrada nginx, el valor de la variable POD_NAMESPACE se usa para restringir potencialmente los objetos de recursos de entrada que el controlador estará vigilando solo al espacio de nombres en el que se implementa, a través del parámetro --watch-namespace (el gráfico de Helm que muestra esto en la acción está aquí ). En cuanto a POD_NAME , no tener esto causará algunos errores en el código interno de ingreso (la función aquí ) que a su vez probablemente evitará que el ingreso se ejecute sin las variables configuradas.
¿No podría el controlador de ingreso obtener esta información automáticamente, en función de los permisos que tiene para ejecutarse (después de todo, puede observar cambios en el nivel de Kubernetes, por lo que uno supondría que es lo suficientemente "poderoso" para ver su propio nombre de pod y el espacio de nombres donde se desplegó)? En otras palabras, ¿no puede el controlador de ingreso hacer una especie de "whoami" y obtener sus propios datos? ¿O es quizás un patrón común utilizado en Kubernetes?
Está hecho por diseño , una comunidad que desarrolla esta funcionalidad a medida que aborda el tema.
Cuando se inicia la variable de entorno, se conocen las variables. Kubernetes proporciona estas variables y el pod puede usarlas cuando se ejecuta.
Por supuesto, si tiene una mejor idea para resolver esto, puede sugerirla en el hilo oficial en github .
Sin embargo, tenga en cuenta que esta posible solución:
¿No podría el controlador de ingreso obtener esta información automáticamente, en función de los permisos que tiene para ejecutarse (después de todo, puede observar cambios en el nivel de Kubernetes, por lo que uno supondría que es lo suficientemente "poderoso" para ver su propio nombre de pod y el espacio de nombres donde se desplegó)? En otras palabras, ¿no puede el controlador de ingreso hacer una especie de "whoami" y obtener sus propios datos? ¿O es quizás un patrón común utilizado en Kubernetes?
requerirá un paso adicional. En primer lugar, el pod deberá tener privilegios adicionales; en segundo lugar, cuando se inicie, aún no tendrá estas variables.