☰

Evite los conflictos de las variables de entorno del pod con enlaces estilo Docker

tag-icon • tag-icon kubernetes environment-variables
Evite los conflictos de las variables de entorno del pod con enlaces estilo Docker

Ejecutamos componentes en Kubernetes con Docker como tiempo de ejecución del contenedor. Un problema es que el entorno del pod está contaminado con variables de enlace estilo Docker como

  • SERVICENAME_PORT_8181_TCP
  • SERVICENAME_PORT_HTTP
  • .....
  • SERVICENAME_PORT

para cada servicio visible (los que están en el mismo espacio de nombres). En esta situación, es bastante fácil que las variables creadas automáticamente tengan conflictos con el entorno declarado explícitamente. Esto a veces conduce a problemas difíciles de diagnosticar. Tampoco quisiera depender de esas variables automáticas, ya que preferiría que los contenedores no dependieran de los detalles de la configuración del servicio de Kubernetes. Actualmente estoy agregando prefijos de nombres únicos a variables explícitas para evitar este tipo de conflictos.

¿Hay alguna manera de configurar el clúster para que no agregue esas variables automáticas para cada servicio visible? Alternativamente, ¿el uso de otros tiempos de ejecución containerdresolvería este problema? Me sorprende que no existan soluciones fáciles de buscar en Google para esto, ya que la configuración a través de variables de entorno se considera una buena práctica. ¿Cómo uso, en general, el entorno sin encontrarme con conflictos de nombres? ¿O los nombres de los servicios se consideran parte del contrato con los contenedores y no debería cambiarlos libremente?

Respuesta1

¿Hay alguna manera de configurar el clúster para que no agregue esas variables automáticas para cada servicio visible?

Sí y no: no en todo el clúster, que yo sepa, sino en elenableServiceLinks: falsecampo enspec:está diseñado para permitirle apagarlos

Alternativamente, ¿el uso de otros tiempos de ejecución como contenedores resolvería este problema?

No, esos nombres se agregaron con el espíritu de compatibilidad con Docker, pero no están relacionados en absoluto con Docker: soninyectado por kubelet

¿Cómo uso, en general, el entorno sin encontrarme con conflictos de nombres? ¿O los nombres de los servicios se consideran parte del contrato con los contenedores y no debería cambiarlos libremente?

Otra opción es, en lugar de prohibirlos por completo, también puedes simplemente enmascararlos.específicolos que molestan a tu aplicación; los que terminan en _HTTPson especialmente problemáticos con Spring Boot donde hay un Servicecuyo metadata: { name:nombre es súper genérico como serviceoserver

Puedes hacerlo por implementación:

env:
- name: SERVICENAME_PORT_HTTP
  # omitting the value: just sets it to the empty string in the container
# and the rest

o puede declarar un ConfigMap que contenga los ofensivos y sobrescribirlos por completo envFrom:(para no tener que parchear cada implementación afectada).

información relacionada