Entrada dinâmica de subdomínio curinga para Kubernetes
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