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

- Nick Faughey

---

您是否已经成功实现所需的自动化解决方案？如果是，能否请您分享一些具体细节？ - Angel Todorov

@AngelTodorov 开发优先级发生了变化，这个特定的项目被忽视了。最好的方法是遵循被接受的答案中的建议。如果我有时间实际实施答案，我会更新这个问题。 - Nick Faughey

Answer 1

在Kubernetes中确实没有类似通配符域名的东西，但您可能可以使用Helm来获得所需内容。

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

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

有一篇关于这种工作流程的很棒的博客文章here - 希望这能帮助到您。

- jaxxstorm

---

请问您能否提供一个基于您上述建议的样例解决方案呢？ - Angel Todorov

@Angel Todorov，你最终想出了解决方案吗？ - mahgo

实际上，我已经很久以前就放弃了这个话题... - Angel Todorov

Answer 2

here is an example:

 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

和source相关。

- Lantanios

---

问题是关于子域名的（api.* 而不是 *.example.com），我认为默认情况下 Ingress 不支持。 - Muayyad Alsadi

@MuayyadAlsadi，我认为您没有正确解释OP的意思。它是关于将x.foo.com路由到名为x-service的服务，其中x可以是任何内容。因此，如果我输入bar.foo.com，我会进入bar-service，如果我进入bottle.foo.com，它会进入bottle-service。我仍然认为这是不支持的，但它与api.*.foo.com的路由不同。 - Nathaniel Ford

是的，我、OP和你都在谈论同一件事，“x.example.com”指向服务“x”，因此某些内容绑定到“*.example.com”，然后根据子域路由。@nathaniel-ford - Muayyad Alsadi

Answer 3

服务在本地可用

my-svc.svc.cluster.local

您可以编写一个简单的NGINX代理，它可以转发并解析子域名，并将其代理传递到http://$service，只要子域名和服务名称匹配，就像这个例子一样。

- cloudpre

---

可以提供一个在建议方法上的简单实现示例吗？ - Angel Todorov