Не могли бы вы привести простой пример реализации предлагаемого подхода?

тоящее время я использую Kubernetes в GKE для обслуживания различных частей моего продукта на разных поддоменах с помощью ресурса Ingress. Например:api.mydomain.com, console.mydomain.com, так далее.

ingress.yml (текущий):

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

Это прекрасно работает с маршрутизацией балансировки нагрузки L7 GCE в соответствующие места. Однако я хотел бы развернуть множество развертываний ветвей функций в виде поддоменов, чтобы протестировать и продемонстрировать новые функции, прежде чем приступить к работе. Это может быть что-то вродеnew-stylesheet.console.mydomain.com или жеupgraded-algorithm.api.mydomain.com, вдохновленный GitLab CI'sокружающая среда.

Вот потенциальный рабочий процесс для каждого развертывания:

Создать файл-api-deploy.ymlСоздать файл-api-service.ymlОбновите ingress.yml новым правилом субдомена:feature.api.mydomain.com указавserviceName: feature-api-service

Но перечисление и поддержание всех сопоставлений поддоменов -> сервисов приведет к путанице со сносом развертываний и создаст тонну бэкэндов GCE (квота по умолчанию 5 ...), так что это не идеально.

Есть ли что-то встроенное в Кубернетес, которое я пропускаю, чтобы справиться с этим? Примерно так было бы идеально выбрать целевую службу на основе соответствующего субдомена:

ingress.yml (хотел)

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

Ответы на вопрос(2)

Ваш ответ на вопрос