我目前正在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的启发。
这是每个部署的潜在工作流程:
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
答案 0 :(得分:5)
肯定没有像kubernetes中可用的通配域这样的东西,但是你可能会想要使用Helm
使用helm,您可以在清单中模拟变量,这样您就可以将分支的名称放在掌舵values file
中从那里,您可以让gitlab-ci在构建管道中执行helm安装,如果正确配置图表,则可以指定管道名称的helm参数。
有一篇关于此类工作流程的精彩博客文章here - 希望这会让您获得所需的资源。
答案 1 :(得分:1)
服务在本地可用
my-svc.svc.cluster.local
您可以编写一个简单的NGINX代理,该代理可以转发该文件,以解析子域并将其传递给http:// $ service,只要在这种情况下子域和服务名称匹配即可。
答案 2 :(得分:0)
这是一个例子:
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。