Kubernetes的动态通配符子域入口

Question

我目前正在GKE上使用Kubernetes,使用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 环境的启发.

这是每个部署的潜在工作流程:

1. 创建feature-api-deployment.yml
2. 创建feature-api-service.yml
3. 使用新的子域规则更新ingress.yml:feature.api.mydomain.com指定serviceName: feature-api-service

但枚举和维护所有子域 - >服务映射将会因拆除部署而变得混乱,并创建大量的GCE后端(默认配额为5 ......),因此它并不理想.

Kubernetes是否有任何内置的东西可供我处理？像这样的东西是理想的选择基于匹配的子域的目标服务:

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

Answer 1

Kubernetes中肯定没有类似通配符域的任何内容，但是您可能可以使用Helm取得想要的结果

使用helm，您可以在清单中模板化变量，因此可以在helm values文件中使用分支名称

从那里，您可以让gitlab-ci在构建管道中进行helm安装，如果您正确配置了图表，则可以指定管道名称的helm参数。

有一个伟大的博客文章这样的工作流程在这里 -希望这会得到你的，你需要去。