Не могли бы вы привести простой пример реализации предлагаемого подхода?
тоящее время я использую 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