Las dos lecciones anteriores construyeron los almacenes: un ConfigMap con la configuración de tienda-web y un Secret con las credenciales de postgres-reservas. En ambas viste una sola forma de llevarlos al contenedor, el fichero montado, y en ambas quedó aplazada la otra: la variable de entorno, que es la que aparece en la inmensa mayoría de los manifiestos reales y la única que entienden las imágenes de terceros como postgres:16 o redis:7.2-alpine. Esta lección la cubre entera y unifica las dos anteriores: cómo se declaran, las cuatro fuentes de las que pueden venir, cómo un pod puede consultar datos sobre sí mismo con la Downward API, qué pasa cuando la misma clave llega por dos caminos, por qué el shell no expande lo que crees, y sobre todo la limitación que lo condiciona todo: una variable de entorno no cambia mientras el proceso vive. Al final tendrás el catálogo completo de variables de los seis componentes de Rutas Norte en los tres entornos.

1. Qué es realmente una variable de entorno en un contenedor
2. env con valor literal
3. envFrom: volcar un ConfigMap o un Secret entero
4. valueFrom: tomar una clave concreta
5. La Downward API: fieldRef
6. La Downward API: resourceFieldRef
7. Expansión de variables con $(VAR)
8. Interacción con command y args
9. Precedencia y colisiones
10. La limitación fundamental: no se refrescan
11. El hash de la configuración en una anotación
12. Variable de entorno frente a fichero montado
13. El catálogo de variables de Rutas Norte

Antes de la sintaxis conviene entender el mecanismo, porque explica casi todas las sorpresas.

Cuando el kubelet arranca un contenedor, construye una lista de pares CLAVE=valor y se la pasa al runtime (containerd), que a su vez la entrega al kernel en la llamada execve() que lanza el proceso principal. A partir de ahí:

• El proceso guarda esa lista en su propia memoria (environ).
• Nadie desde fuera puede modificarla. No hay una llamada al sistema para cambiar el entorno de otro proceso. Ni Kubernetes, ni el kubelet, ni kubectl.
• Los procesos hijos la heredan en el momento de crearse.

De aquí se deduce todo lo que viene después: por qué hay que reiniciar el pod al cambiar un ConfigMap, por qué las variables son visibles en /proc/<pid>/environ, y por qué el contenido de una variable es siempre una cadena de texto (no existen números ni booleanos en el entorno de un proceso).

Comprobémoslo:

Hay tres orígenes mezclados en esa lista:

1. Las que vienen de la imagen (PATH, HOME): las define el Dockerfile o la imagen base.
2. Las que hemos declarado nosotros (DB_HOST, NIVEL_LOG).
3. Las que inyecta Kubernetes automáticamente: HOSTNAME (el nombre del pod) y las variables de descubrimiento de Services (KUBERNETES_SERVICE_HOST, REDIS_CACHE_SERVICE_HOST...).

Esas últimas son un vestigio de los inicios de Kubernetes, heredado de Docker links. Tienen dos limitaciones serias: solo aparecen los Services que ya existían cuando arrancó el pod, y solo los del mismo namespace. Por eso nadie las usa hoy: el descubrimiento se hace por DNS, como verás en DNS Interno. Si tienes muchos Services y quieres una lista de entorno limpia, se pueden desactivar con enableServiceLinks: false en spec del pod.

La forma más simple. Es una lista, no un mapa, y ese es el primer detalle que confunde:

Las comillas en los valores numéricos y booleanos no son opcionales. El campo value es de tipo string en el esquema de la API. Si escribes value: 5432, el analizador de YAML produce un entero y la validación falla:

El mismo problema con value: true, con value: no (YAML 1.1 lo interpreta como booleano) y con value: 08:00 (lo interpreta como sexagesimal). Regla práctica: pon comillas en todos los valores de env que no sean claramente texto.

Cuándo usar un valor literal en lugar de un ConfigMap:

Cuando el ConfigMap tiene diez claves y las quieres todas, escribir diez bloques valueFrom es absurdo. envFrom las vuelca de golpe:

Con este ConfigMap:

El contenedor recibe NIVEL_LOG, TIEMPO_ESPERA_MS y MAX_PLAZAS_POR_RESERVA con esos valores. El nombre de la clave se convierte literalmente en el nombre de la variable, lo que impone una condición: las claves deben ser nombres válidos de variable de entorno (letras, dígitos y _, sin empezar por dígito).

¿Qué pasa si una clave no es válida? Kubernetes la ignora en silencio y lo registra como un evento:

Este es exactamente el motivo por el que en la lección de ConfigMaps insistí en separar el ConfigMap de ficheros del ConfigMap de variables. Un nginx.conf no puede ser una variable de entorno, pero convive perfectamente en el mismo objeto y estropea el envFrom.

envFrom admite un prefijo, que resuelve el problema de las colisiones entre fuentes:

Resultado dentro del contenedor:

Fíjate en DB_password en minúsculas: el prefijo se antepone tal cual, sin cambiar el resto. Si quieres DB_PASSWORD, la clave del Secret debe llamarse PASSWORD. Es un motivo razonable para nombrar las claves de los Secrets en mayúsculas cuando sabes que se consumirán con envFrom.

Por defecto, si el ConfigMap o el Secret referenciado no existe, el pod no arranca: se queda en CreateContainerConfigError.

Con optional: true el pod arranca sin esas variables:

Úsalo con cuidado. Es apropiado para configuración verdaderamente opcional (un ConfigMap de banderas de funcionalidad que solo existe en dev), pero es peligroso para lo esencial: un fallo silencioso donde el pod arranca con la configuración a medias es mucho peor de diagnosticar que un pod que no arranca. En Rutas Norte, optional: true solo se usa para el ConfigMap de banderas experimentales.

Cuando quieres una sola clave, o cuando el nombre de la variable debe ser distinto del de la clave, se usa valueFrom:

Esta es la forma recomendada por defecto frente a envFrom, y por tres razones sólidas:

1. Es explícita. Al leer el Deployment sabes exactamente qué variables recibe el contenedor. Con envFrom hay que ir a mirar el ConfigMap.
2. Desacopla nombres. La aplicación espera LOG_LEVEL y nuestro ConfigMap se llama NIVEL_LOG porque el equipo trabaja en español. valueFrom lo traduce sin renombrar nada.
3. Mínimo privilegio. Al pod solo llegan las claves que necesita, igual que hacíamos con items en los volúmenes.

Y una advertencia sobre secretKeyRef: aunque la referencia sea limpia, el valor acaba en el entorno del proceso. Es visible en /proc/<pid>/environ para cualquier proceso del contenedor, y muchos frameworks vuelcan el entorno completo en las páginas de error de depuración. Para credenciales de alto valor, el fichero montado de la lección anterior sigue siendo mejor opción.

Hasta ahora la configuración venía de fuera. La Downward API ("API hacia abajo") permite lo contrario: que el contenedor conozca datos sobre sí mismo y sobre el pod que lo contiene, sin hablar con la API de Kubernetes ni necesitar permisos.

El caso de Rutas Norte: cuando un cliente reporta que una reserva falló a las 22:47, queremos poder buscar en las trazas qué pod y qué nodo atendieron esa petición. Con 6 réplicas de api-reservas repartidas por 3 nodos, sin esa información la investigación es imposible.

Campos disponibles en fieldRef:

Dos restricciones que hay que conocer:

• Solo se admiten esos campos. No puedes pedir spec.containers[0].image ni un campo arbitrario del pod. Para eso hay que hablar con la API, que es lo que veremos en ServiceAccounts.
• metadata.labels y metadata.annotations sin especificar clave solo funcionan en un volumen downwardAPI, no en env. En env hay que indicar la clave concreta entre corchetes.

Veamos el resultado y su valor real:

Y así queda una traza de api-reservas que use esas variables:

Con esa línea, el diagnóstico es inmediato: todos los errores vienen del mismo pod y del mismo nodo, así que el problema no es la aplicación sino ese nodo concreto (o su ruta de red hasta postgres-reservas). Sin la Downward API, esa correlación no existe.

Un detalle importante sobre ENTORNO: podríamos haberlo puesto como literal value: "pro", pero entonces tendríamos el dato duplicado (en la etiqueta y en la variable) con riesgo de que se desincronicen. Leerlo de metadata.labels['entorno'] garantiza que siempre coincide con la etiqueta real del pod. Es una aplicación directa del esquema de etiquetado del módulo 2.

Existe también la variante de fichero, útil cuando quieres todas las etiquetas o anotaciones:

Y con una ventaja: a diferencia de las variables, este fichero sí se actualiza si cambian las etiquetas del pod, con el mismo mecanismo de la lección de ConfigMaps.

La segunda mitad de la Downward API expone los recursos declarados del contenedor, que estudiaremos a fondo en Cuotas y Límites:

Recursos disponibles: limits.cpu, requests.cpu, limits.memory, requests.memory, limits.ephemeral-storage, requests.ephemeral-storage.

El divisor decide la unidad: 1m da milicores, 1 da cores enteros (redondeando hacia arriba), 1Mi da mebibytes, 1Gi gibibytes. Si lo omites, el valor por defecto es 1, lo que para memoria significa bytes y produce números incómodos como 536870912.

¿Para qué sirve esto en la práctica? Para que el proceso se dimensione a sí mismo. Es un problema real y muy común: muchos entornos de ejecución no ven los límites de cgroups y creen que disponen de toda la memoria y todas las CPU del nodo, con lo que dimensionan sus pools de hilos y sus montones de memoria a lo grande y acaban en OOMKilled.

Aplicado a api-reservas (Node.js):

Ese 384 es el 75 % de 512Mi. Lo ideal sería calcularlo, pero la expansión $(VAR) del apartado siguiente no hace aritmética, así que en la práctica se calcula en el entrypoint del contenedor leyendo MEMORIA_LIMITE_MB:

Para la JVM existe el equivalente automático (-XX:MaxRAMPercentage=75), que es la opción preferible cuando el lenguaje la ofrece.

Kubernetes permite referenciar unas variables desde otras usando la sintaxis $(NOMBRE):

Las reglas, que hay que conocer con precisión:

Regla 1: la sintaxis es $(VAR), con paréntesis. No ${VAR} ni $VAR. Esas dos son sintaxis de shell y Kubernetes las deja intactas.

Regla 2: solo se expanden variables definidas ANTES en la misma lista env. El orden importa:

Cuando una referencia no se puede resolver, queda literal. No hay error ni aviso, y el valor $(DEFINIDA_DESPUES) llega tal cual a la aplicación. Es una fuente de errores silenciosos.

Regla 3: no se expanden las variables que vienen de envFrom. Las de envFrom se procesan como un bloque y no participan en la expansión de las de env. Si necesitas componer con una clave de un ConfigMap, tráela primero con valueFrom:

Regla 4: no se expanden las variables de la imagen. $(PATH) o $(HOME) no se resuelven: Kubernetes solo conoce las que él mismo define.

Regla 5: $$ escapa el dólar. Si tu contraseña contiene $( literal, escríbelo $$(.

Aquí está el malentendido más frecuente del tema, y merece un apartado propio.

Esto funciona: Kubernetes expande $(LOTE_MAXIMO) en args con las mismas reglas del apartado anterior, y el proceso recibe --lote=50.

Pero esto no funciona:

Y esto tampoco:

La causa de la confusión: no hay shell. Cuando escribes command: ["/app/worker"], containerd ejecuta ese binario directamente con execve(). No se invoca /bin/sh, así que nadie expande $VAR ni ${VAR}: esa expansión es un trabajo del shell, y el shell no está en la cadena.

Las tres opciones y cuándo usar cada una:

Si usas la segunda forma, dos avisos importantes:

Aviso 1: el shell se convierte en el PID 1 y muchos shells no reenvían las señales a sus hijos. Eso rompe la terminación ordenada con SIGTERM que estudiaste en la lección de Pods: al borrar el pod, el proceso real no recibe la señal y muere de golpe al agotarse el periodo de gracia. La solución es exec:

Con exec, el shell se reemplaza por el programa, que hereda el PID 1 y recibe las señales.

Aviso 2: es una puerta de entrada a la inyección de comandos. Si una variable viene de una fuente poco fiable y la interpretas en un sh -c, un valor como ; rm -rf / se ejecuta. Con $(VAR) de Kubernetes eso no pasa: el valor se pasa como argumento, no se interpreta.

Y un recordatorio de la lección anterior: nunca pongas una credencial en args, ni siquiera expandida desde un Secret. kubectl describe pod muestra Args con el valor ya resuelto.

Cuando MISMA_CLAVE llega por varias vías, ¿cuál gana? El orden de resolución es estricto:

La regla en una frase: env siempre gana sobre envFrom, y dentro de cada bloque gana la última entrada.

Ejemplo completo para ver los cuatro niveles:

Gana debug, el de env. Y si eliminamos ese bloque env, ganaría warn, el del último configMapRef.

Consejos para no sufrir con esto:

1. Evita las colisiones en lugar de gestionarlas. Un ConfigMap por propósito y sin claves repetidas.
2. Usa prefix cuando volques varias fuentes con envFrom.
3. Ante la duda, comprueba el valor efectivo, que es la única verdad:

4. Cuidado con las variables de la imagen. Una imagen base puede definir NODE_ENV=production en su Dockerfile, y si no la sobrescribes explícitamente estará ahí sin que aparezca en ningún manifiesto tuyo. kubectl exec ... -- env la revela.

Volvemos al mecanismo del apartado 1. Las variables de entorno se fijan en execve() y nadie puede cambiarlas después. La consecuencia es tajante:

Si cambias un ConfigMap o un Secret, los pods que ya corren no verán el cambio nunca, por muchas horas que esperes.

Demostración:

El objeto vale trace y el proceso sigue viendo debug. Y seguirá así hasta el fin de los tiempos.

Comparativa con lo que sí se refresca:

Las tres salidas posibles:

1. Reiniciar los pods a mano. Funciona y es lo que hicimos al rotar credenciales:

El problema es que hay que acordarse. Si alguien cambia el ConfigMap en una pull request y olvida el reinicio, la plataforma queda en un estado en el que el manifiesto dice una cosa y los pods hacen otra. Ese desfase silencioso es peligroso: se descubre semanas después, cuando un pod se reinicia por otro motivo y de repente cambia de comportamiento sin que nadie haya tocado nada.

2. Usar fichero montado para lo que deba cambiar en caliente.

3. Automatizar el reinicio con un hash, que es la solución elegante y el apartado siguiente.

La técnica es sencilla y se ha convertido en un patrón estándar: guardar un resumen (hash) del contenido del ConfigMap y del Secret en una anotación del template del pod.

La clave es que Kubernetes dispara un despliegue nuevo cuando cambia cualquier cosa dentro de spec.template, incluidas sus anotaciones. Como el hash depende del contenido de la configuración, cambiar la configuración cambia el hash, cambiar el hash cambia el template, y cambiar el template dispara el despliegue progresivo.

En el manifiesto:

Cómo se calcula el hash en el pipeline de despliegue:

Es importante hacer el hash solo de .data: si lo hicieras del objeto completo, el resourceVersion cambiaría en cada actualización aunque el contenido fuese idéntico, y tendrías despliegues espurios.

Cuatro ventajas de este patrón:

1. Cambiar la configuración despliega solo. No hay que acordarse de nada.
2. Queda historial. Aparece en kubectl rollout history y se puede deshacer con rollout undo, igual que un cambio de código.
3. No hay desfase. El pod que corre siempre corresponde al ConfigMap vigente.
4. Es auditable. La anotación dice a qué versión exacta de la configuración corresponde cada revisión.

Vale la pena saber que las herramientas del ecosistema hacen esto por ti:

Para Rutas Norte, mientras trabajamos con YAML plano, el script de arriba en el pipeline es suficiente. En el módulo 10 lo sustituiremos por Kustomize.

Ya tienes todos los elementos para decidir. Esta es la tabla de decisión:

Reglas de decisión para Rutas Norte:

1. Configuración no sensible y estable durante la vida del pod → variable de entorno. NIVEL_LOG, TIEMPO_ESPERA_MS, REDIS_HOST. Es lo más simple y lo entiende todo el mundo.
2. Ficheros de configuración → volumen. El nginx.conf de tienda-web, el reglas-tarifas.json de api-reservas.
3. Credenciales de alto valor → volumen, con *_FILE si la imagen lo admite. La contraseña de postgres-reservas para api-reservas.
4. Credenciales exigidas por imágenes de terceros → variable con secretKeyRef, sin alternativa. POSTGRES_PASSWORD en la imagen oficial de PostgreSQL.
5. Configuración que debe cambiarse en caliente → volumen. El MODO_MANTENIMIENTO de nginx.
6. Identidad del pod → Downward API en variables. Es información inmutable durante la vida del pod, así que la limitación no molesta.

Cerramos con el inventario completo, que es también el estado de la plataforma al terminar esta lección. Marco en cada caso el origen: L literal, CM ConfigMap, S Secret, DA Downward API.

tienda-web casi no usa variables: su configuración es el nginx.conf del ConfigMap montado, porque nginx lee un fichero, no el entorno. Es el ejemplo perfecto de la regla 2.

Observa DB_POOL_MAX: crece con el entorno porque en producción hay más réplicas y más tráfico en puentes y vacaciones, pero no puede crecer sin límite, porque max_connections de PostgreSQL es finito y réplicas × DB_POOL_MAX no debe superarlo. Con 4 réplicas y DB_POOL_MAX: 25 son 100 conexiones. Es exactamente el tipo de cálculo que hay que documentar en el YAML con un comentario.

Aquí no hay elección: la imagen oficial de PostgreSQL lee esas variables. Es la regla 4. El PGDATA en un subdirectorio es una precaución imprescindible cuando llegue el volumen persistente del módulo 5: el punto de montaje suele contener un lost+found que impide inicializar la base de datos.

allkeys-lru es una decisión de negocio: redis-cache es la caché de disponibilidad de plazas y es prescindible, así que preferimos que descarte las claves menos usadas antes que rechazar escrituras.

En dev el SMTP apunta a mailhog, un capturador de correo local: en desarrollo no se envían correos reales a clientes. Es una decisión de protección de datos, no de comodidad, y es exactamente el tipo de cosa que la separación de configuración hace posible.

Reunimos todo lo aprendido en un único manifiesto, que es el estado real del componente al cerrar esta lección:

Este manifiesto se puede publicar sin filtrar nada. Contiene referencias, no valores. Es exactamente el listón que nos pusimos al empezar el módulo.

Consejos:

1. valueFrom por defecto, envFrom solo cuando sean muchas y ya se llamen bien. La trazabilidad del manifiesto vale más que ahorrar líneas.
2. Añade la Downward API a todo componente desde el primer día. El coste es de seis líneas y el día del incidente vale su peso en oro.
3. Documenta cada variable con un comentario en el manifiesto: qué hace, qué rango es válido, quién la consume.
4. Ordena env por bloques —literales, ConfigMap, Secret, Downward API, compuestas— como en el manifiesto final del apartado 13. Se lee mucho mejor.
5. Ante cualquier duda, kubectl exec -- env. El manifiesto es la intención; el entorno del proceso es la realidad.

Crea un pod de diagnóstico llamado inspector-config en rutas-norte-dev que reciba variables por los cuatro caminos y las imprima:

1. Un literal COMPONENTE=inspector.
2. Todas las claves del ConfigMap api-reservas-config con el prefijo CFG_.
3. Únicamente la clave password del Secret postgres-reservas-credenciales, con el nombre CLAVE_BD.
4. El nombre del pod, el nodo y la etiqueta entorno por Downward API.
5. Una variable RESUMEN compuesta con $(VAR) que contenga <componente>@<nodo>:<entorno>.

Aplica el manifiesto, muestra la salida y explica por qué el punto 5 solo funciona si las variables están en el orden correcto.

1. Despliega api-reservas con LOG_LEVEL proveniente del ConfigMap.
2. Comprueba el valor efectivo dentro del pod.
3. Cambia el ConfigMap a trace y espera tres minutos. Comprueba de nuevo el valor en el pod y el valor del objeto.
4. Monta además el mismo ConfigMap como volumen en /etc/config y repite el experimento. ¿Qué diferencia observas?
5. Implementa la técnica del hash: calcula el sha256 del .data del ConfigMap, ponlo en una anotación del template y demuestra que al cambiar el ConfigMap y recalcular el hash se dispara un despliegue.

Un compañero ha desplegado worker-notificaciones con este fragmento y se queja de que el trabajador procesa lotes de tamaño ${LOTE_MAXIMO} en lugar de 200:

1. Explica qué está mal en args y qué está bien en command, y por qué son casos distintos.
2. Corrige el manifiesto usando la sintaxis de Kubernetes.
3. Explica por qué este command con sh -c es problemático para la terminación ordenada del módulo 2 y corrígelo.
4. Reescribe el fragmento sin usar shell en absoluto.
5. Si LOTE_MAXIMO viniera de un envFrom en lugar de un valueFrom, ¿funcionaría la expansión $(LOTE_MAXIMO) en args? Justifícalo.

Solución 1

El punto 5 funciona porque COMPONENTE, NODO_NOMBRE y ENTORNO están definidas antes que RESUMEN en la lista env. Kubernetes resuelve la lista en orden y solo puede sustituir lo que ya ha procesado. Si RESUMEN estuviera en primera posición, el valor sería literalmente $(COMPONENTE)@$(NODO_NOMBRE):$(ENTORNO), sin ningún error ni aviso.

Y observa el efecto colateral que sirve de advertencia: CLAVE_BD con la contraseña aparece en el log del pod, porque el comando hace env. Cualquiera con kubectl logs la ve, y en producción ese log iría al sistema centralizado del módulo 7. Nunca vuelques el entorno en un contenedor que consuma secretos.

Solución 2

El objeto vale trace, el proceso sigue en debug. Con el volumen añadido:

El mismo ConfigMap, el mismo pod, el mismo instante, dos valores distintos. El fichero se refrescó y la variable no. Esa es la diferencia en una sola pantalla.

El hash:

Ahora sí. Y con historial:

Solución 3

1. args está mal, command está bien. En args se ha escrito $LOTE_MAXIMO con la sintaxis del shell; Kubernetes solo entiende $(VAR), así que deja el texto tal cual y el programa recibe --cola=$LOTE_MAXIMO. En command, en cambio, la expansión ${LOTE_MAXIMO} sí funciona, pero no la hace Kubernetes: la hace el sh -c que se está ejecutando. Son dos expansiones distintas hechas por dos actores distintos, y confundirlas es el origen del error.

Además hay un segundo problema oculto: cuando se define command con sh -c "...", el contenido de args se añade como argumentos posicionales del shell ($0, $1...), no del programa. Ese --cola=... no llega a ningún sitio útil.

2. Corregido con sintaxis de Kubernetes:

3. El problema del sh -c sin exec: el shell es el PID 1 del contenedor y /app/worker es su hijo. Cuando Kubernetes borra el pod envía SIGTERM al PID 1, es decir, al shell. La mayoría de shells no reenvían señales a sus hijos, así que el trabajador no se entera y sigue procesando correos hasta que expira el terminationGracePeriodSeconds (30 s por defecto) y llega el SIGKILL, que lo mata en seco. Si estaba enviando un correo de confirmación, se pierde.

Con exec, el shell se reemplaza a sí mismo por el trabajador, que pasa a ser el PID 1 y recibe el SIGTERM directamente.

4. Sin shell en absoluto, que es lo correcto:

Sin shell no hay problema de señales, no hay riesgo de inyección de comandos, y la expansión la hace Kubernetes antes de arrancar nada. Lo más limpio de todo sería que /app/worker leyera directamente LOTE_MAXIMO de su entorno y prescindir de args.

5. No, no funcionaría. La expansión $(VAR) solo alcanza a las variables definidas en la lista env anterior a su uso. Las que vienen por envFrom se resuelven como un bloque separado y no participan en la expansión ni de env ni de args. --cola=$(LOTE_MAXIMO) llegaría literal. La solución es traerla explícitamente con valueFrom antes de usarla, aunque también venga en el envFrom.

Con esta lección cierras el bloque de configuración del módulo. Entiendes el mecanismo real —la lista CLAVE=valor que el kubelet entrega a execve() y que queda congelada en el proceso— y de ahí se deduce todo lo demás. Dominas las cuatro fuentes: el literal con sus comillas obligatorias, envFrom con prefix y optional y su trampa de las claves no válidas que se ignoran en silencio, valueFrom con configMapKeyRef y secretKeyRef como opción recomendada por explícita y por permitir renombrar, y la Downward API en sus dos formas, fieldRef para la identidad del pod y resourceFieldRef para que el proceso se dimensione a sí mismo y no acabe en OOMKilled.

Sabes que api-reservas registra ahora en cada traza qué pod y qué nodo la atendieron, lo que convierte un incidente inabordable en un diagnóstico de dos minutos. Conoces las cinco reglas de la expansión $(VAR) —paréntesis, orden, nada de envFrom, nada de la imagen, $$ para escapar— y por qué en command/args no hay shell salvo que lo pidas, con las consecuencias que eso arrastra: ${VAR} no se expande, y si usas sh -c sin exec rompes la terminación ordenada del módulo 2. Tienes clara la precedencia (env gana a envFrom, y dentro de cada bloque gana el último) y la forma de comprobar la verdad, que siempre es kubectl exec -- printenv.

Y sobre todo tienes interiorizada la limitación que gobierna las decisiones de diseño: las variables de entorno no se refrescan nunca, con la solución del hash de la configuración en una anotación del template que convierte un cambio de ConfigMap en un despliegue progresivo con historial y rollback. Con la tabla de decisión "variable frente a fichero" ya no dudas dónde poner cada cosa, y el catálogo completo de los seis componentes de Rutas Norte por entorno es el mapa de la plataforma tal como está ahora: una sola imagen por componente, cero credenciales en Git y toda la variabilidad concentrada en k8s/entornos/.

Quedan dos deudas del módulo 2, y las dos son de recursos. Ningún namespace tiene cuota, así que un despliegue equivocado en rutas-norte-dev —una réplica de más, un bucle de reinicio, un pod que pide 16 GiB— puede consumir la capacidad del clúster y dejar sin sitio a rutas-norte-pro. Y los requests y limits que llevamos escribiendo desde el módulo 2 están puestos a ojo, sin ningún criterio. La lección siguiente, Cuotas y Límites de Recursos, lo aborda: verás quién usa las requests (el planificador) y quién los limits (el kubelet a través de cgroups), la diferencia crucial entre la CPU, que se estrangula, y la memoria, que mata el proceso con OOMKilled, qué pasa cuando la suma de límites supera la capacidad del clúster, y pondrás una ResourceQuota a cada uno de los tres entornos de Rutas Norte para que dev no pueda volver a asustar a pro.