适用于 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. 创建功能-api-deployment.yml
2. 创建功能-api-service.yml
3. 使用新的子域规则更新入口.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 值文件中

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

这里有一篇关于这种工作流程的很棒的博客文章 - 希望这会让你到达你需要去的地方。

Answer 2

下面是一个例子：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress-wildcard-host
spec:
rules:
- host: "foo.bar.com"
http:
paths:
- pathType: Prefix
path: "/bar"
backend:
service:
name: service1
port:
number: 80
- host: "*.foo.com"
http:
paths:
- pathType: Prefix
path: "/foo"
backend:
service:
name: service2
port:
number: 80

和来源。

Answer 3

服务在本地可用

my-svc.svc.cluster.local

您可以编写一个简单的NGINX代理，该代理可以转发，只要子域和服务名称匹配，就可以解析子域并将其传递给http：//$service，就像在这种情况下一样。