Kubernetes的动态通配符子域入口 [英] Dynamic wildcard subdomain ingress for Kubernetes

问题描述

我目前正在GKE上使用Kubernetes，通过Ingress资源在不同子域上为产品的各个部分提供服务.例如:api.mydomain.com，console.mydomain.com等

I'm currently using Kubernetes on GKE to serve the various parts of my product on different subdomains with the Ingress resource. For example: api.mydomain.com, console.mydomain.com, etc.

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的环境.

That works wonderfully, with the L7 GCE load balancer routing to the appropriate places. What I would like to do, however, is deploy many feature-branch deployments as subdomains to test and demonstrate new features before pushing to production. These could be something like new-stylesheet.console.mydomain.com or upgraded-algorithm.api.mydomain.com, inspired by GitLab CI's environments.

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

Here's a potential workflow for each deployment:

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

1. Create feature-api-deployment.yml
2. Create feature-api-service.yml
3. Update ingress.yml with new subdomain rule: feature.api.mydomain.com specifying serviceName: feature-api-service

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

But enumerating and maintaining all subdomain->service mappings will get messy with tearing down deployments, and create a ton of GCE backends (default quota is 5...) so it's not ideal.

Kubernetes内置了什么我可以处理的东西?这样的事情对于根据匹配的子域选择目标服务将是理想的选择:

Is there anything built in to Kubernetes that I'm overlooking to handle this? Something like this would be ideal to pick a target service based on a matched subdomain:

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

推荐答案

在Kubernetes中当然没有像通配符域那样的东西，但是您可以使用

There certainly isn't anything like wildcard domains available in kubernetes, but you might be able to get want you want using Helm

有了头盔，您可以在清单中模板化变量，因此您可以将分支的名称放在头盔中

With helm, you can template variables inside your manifests, so you can have the name of your branch be in the helm values file

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

From there, you can have gitlab-ci do the helm installation in a build pipeline and if you configure your chart correctly, you can specify a helm argument of the pipeline name.

关于这种工作流程，有一篇很棒的博客文章

There's a great blog post about this kind of workflow here - hopefully this'll get your where you need to go.

这篇关于Kubernetes的动态通配符子域入口的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！