feat(agent): select the worker ingress stack with worker_ingress instead of three template paths

[agustincelentano]

El caso de uso

Una instalación con Istio tiene que poner esto en su module "agent":

service_template        = "/app/pkg/k8s/deployment/templates/istio/service.yaml.tpl"
initial_ingress_path    = "/app/pkg/k8s/deployment/templates/istio/initial-httproute.yaml.tpl"
blue_green_ingress_path = "/app/pkg/k8s/deployment/templates/istio/blue-green-httproute.yaml.tpl"

Son tres rutas absolutas al filesystem de la imagen scopes/containers, copiadas en cada root module, para expresar una decisión de una palabra: "desplegamos con Istio". Nadie que lea ese bloque entiende que eso es un interruptor; parece configuración de templates. Y nada en plan ni en apply avisa si la imagen mueve un template: se descubre cuando falla un deploy.

Cómo funciona por debajo, leído en nullplatform/scopes v1.16.2:

• El scope k8s trae sus propios defaults en k8s/values.yaml, y apuntan a los templates de ALB Ingress: service.yaml.tpl, initial-ingress.yaml.tpl, blue-green-ingress.yaml.tpl.
• Los workflows los leen tal cual: initial.yaml usa $INITIAL_INGRESS_PATH, blue_green.yaml usa $BLUE_GREEN_INGRESS_PATH, finalize y rollback vuelven al inicial. Una env con el mismo nombre pisa el default.
• Ningún script del scope lee INGRESS_TYPE. La descripción actual de las tres variables del módulo dice "required when extra_envs.INGRESS_TYPE is 'istio'", pero esa variable no existe del lado del scope: lo único que elige el modo son los paths.

Con el default del módulo, "", el scope usa ALB Ingress. Si una instalación Istio se olvida uno de los tres paths, los deploys dejan de enrutar por los Gateways y no hay error que lo señale.

Qué cambia

Un input nuevo, worker_ingress, con dos valores:

• "alb" (default): manda las tres variables vacías, así el scope k8s usa sus templates de ALB Ingress. Es exactamente lo que el módulo hace hoy, así que ninguna instalación existente cambia.
• "istio": deriva los tres paths a los templates de Gateway API que la imagen scopes/containers hornea bajo /app/pkg/k8s/deployment/templates/istio/.

service_template, initial_ingress_path y blue_green_ingress_path siguen existiendo y, si vienen no vacías, pisan lo que worker_ingress deriva. Sirven para templates propios; dejan de ser la forma de decir "Istio". Sus descripciones ya no mencionan INGRESS_TYPE.

Con esto el bloque de arriba queda en:

worker_ingress = "istio"

y si la imagen reubica los templates, el módulo es el único lugar a tocar.

Compatibilidad

Sin cambios para nadie: el default reproduce el comportamiento actual, y quien ya pasa los tres paths a mano los sigue viendo respetados porque el override explícito gana. Una instalación Istio puede migrar reemplazando las tres líneas por worker_ingress = "istio" y el plan del agent no muestra diferencias en los values, porque los paths derivados son los mismos que venía pasando.

Tests

Cuatro runs nuevos en agent_values.tftest.hcl: el default deja los tres paths vacíos; istio deriva los tres paths correctos en el patch del worker containers; un service_template explícito gana sobre istio; un valor desconocido se rechaza en la validación. La suite del módulo queda en 29/29.

Relacionado

Es una de las tres cosas que salieron de migrar una instalación a workers y que hoy obligan a copiar internals del módulo en el root module. Las otras dos quedan para PRs aparte: que el env de deploy se aplique a una lista de packages (worker_k8s_packages) y no solo a containers, y que CLUSTER_NAME, que scope/iam/create_role lee del env, sea un input del módulo en vez de colarse por extra_envs.