Atualmente, estou usando o Kubernetes no GKE para veicular as várias partes do meu produto em diferentes subdomínios com o recurso Ingress. Por exemplo:api.mydomain.com, console.mydomain.com, etc.

ingress.yml (atual):

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

Isso funciona maravilhosamente, com o roteamento do balanceador de carga L7 GCE para os locais apropriados. O que eu gostaria de fazer, no entanto, é implantar muitas implantações de ramificação de recursos como subdomínios para testar e demonstrar novos recursos antes de avançar para a produção. Estes podem ser algo comonew-stylesheet.console.mydomain.com ouupgraded-algorithm.api.mydomain.com, inspirado nos CIs do GitLabambientes.

Aqui está um fluxo de trabalho potencial para cada implantação:

Criar feature-api-deployment.ymlCriar feature-api-service.ymlAtualize ingress.yml com a nova regra de subdomínio:feature.api.mydomain.com especificandoserviceName: feature-api-service

Mas enumerar e manter todos os mapeamentos de subdomínio-> ficarão confusos ao derrubar implantações e criar uma tonelada de back-end do GCE (a cota padrão é 5 ...), portanto não é o ideal.

Existe algo embutido no Kubernetes que estou ignorando para lidar com isso? Algo assim seria ideal para escolher um serviço de destino com base em um subdomínio correspondente:

ingress.yml (procurado)

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