Actualmente estoy usando Kubernetes en GKE para servir las diversas partes de mi producto en diferentes subdominios con el recurso Ingress. Por ejemplo:api.mydomain.com, console.mydomain.cometc.

ingress.yml (actual):

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress
spec:
  rules:
  - host: api.mydomain.com
    http:
      paths:
        - backend:
            serviceName: api-service
            servicePort: 80
  - host: console.mydomain.com
    http:
      paths:
        - backend:
            serviceName: console-service
            servicePort: 80

Eso funciona de maravilla, con el enrutador de equilibrador de carga L7 GCE a los lugares apropiados. Sin embargo, lo que me gustaría hacer es implementar muchas implementaciones de ramas de características como subdominios para probar y demostrar nuevas características antes de pasar a producción. Estos podrían ser algo comonew-stylesheet.console.mydomain.com oupgraded-algorithm.api.mydomain.com, inspirado en los CI de GitLabambientes.

Aquí hay un flujo de trabajo potencial para cada implementación:

Crear feature-api-implementación.ymlCrear feature-api-service.ymlActualice ingress.yml con la nueva regla de subdominio:feature.api.mydomain.com especificandoserviceName: feature-api-service

Pero enumerar y mantener todas las asignaciones de subdominio-> servicio se complicará con la eliminación de implementaciones, y creará una tonelada de backends GCE (la cuota predeterminada es 5 ...) por lo que no es ideal.

¿Hay algo integrado en Kubernetes que estoy pasando por alto para manejar esto? Algo como esto sería ideal para elegir un servicio de destino basado en un subdominio coincidente:

ingress.yml (buscado)

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress
spec:
  rules:
  - host: *.api.mydomain.com
    http:
      paths:
        - backend:
            serviceName: {value of *}-api-service
            servicePort: 80