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 的 environments。

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

创建特征-api-deployment.yml
创建特征-api-service.yml
使用新的子域规则更新 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 file

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

有一个很棒的博客 post 介绍了这种工作流程 here - 希望这会帮助您到达目的地。

Answer 2

服务在本地可用

my-svc.svc.cluster.local

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

Answer 3

这里有一个例子：

 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.

Kubernetes 的动态通配符子域入口

Dynamic wildcard subdomain ingress for Kubernetes

networking

load-balancing

kubernetes

google-kubernetes-engine