[英]Supporting wildcard domains for TLS: Kubernetes Ingress on GKE
I'm working on an application that deploys kubernetes resources dynamically, and I'd like to be able to provision a shared SSL certificate for all of them.我正在开发一个动态部署 kubernetes 资源的应用程序,我希望能够为所有这些资源提供共享的 SSL 证书。 At any given time, all of the services have the path
*.*.*.example.com
.在任何给定时间,所有服务都具有路径
*.*.*.example.com
。
I've heard that cert-manager will provision/re-provision certs automatically, but I don't necessarily need auto-provisioning if its too much overhead.我听说 cert-manager 会自动配置/重新配置证书,但如果开销太大,我不一定需要自动配置。 The solution also needs to be able to handle these nested url subdomains.
该解决方案还需要能够处理这些嵌套的 url 子域。
Any thoughts on the easiest way to do this?对最简单的方法有什么想法吗?
Have a look at nginx-ingress , which is a Kubernetes Ingress Controller that essentially makes it possible to run Nginx reverse proxy/web server/load balancer on Kubernetes. Have a look at nginx-ingress , which is a Kubernetes Ingress Controller that essentially makes it possible to run Nginx reverse proxy/web server/load balancer on Kubernetes.
nginx-ingress is built around the Ingress resource. nginx-ingress 是围绕Ingress资源构建的。 It will watch Ingress objects and manage nginx configuration in config maps.
它将监视 Ingress 对象并管理配置映射中的 nginx 配置。 You can define powerful traffic routing rules, caching, url rewriting, and a lot more via the Kubernetes Ingress resource rules and nginx specific annotations .
您可以通过 Kubernetes 入口资源规则和nginx 特定注释来定义强大的流量路由规则、缓存、url 重写等等。
Here's an example of an Ingress with some routing.这是一个带有一些路由的 Ingress 示例。 There's a lot more you can do with this, and it does support wildcard domain routing .
你可以用它做更多的事情, 它确实支持通配符域路由。
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/rewrite-target: /$1
cert-manager.io/cluster-issuer: letsencrypt-prod
name: my-ingress
spec:
rules:
- host: app1.domain.com
http:
paths:
- backend:
serviceName: app1-service
servicePort: http
path: /(.*)
- host: app2.sub.domain.com
http:
paths:
- backend:
serviceName: app2-service
servicePort: http
path: /(.*)
tls:
- hosts:
- app1.domain.com
secretName: app1.domain.com-tls-secret
- hosts:
- app2.sub.domain.com
secretName: app2.sub.domain.com-tls-secret
The annotations section is really important.注释部分非常重要。 Above indicates that nginx-ingress should manage this Ingress definition.
上面表明 nginx-ingress 应该管理这个 Ingress 定义。 This annotations section allows to specify additional nginx configuration, in the above example it specifies a url rewrite target that can be used to rewrite urls in the rule section.
此注释部分允许指定额外的 nginx 配置,在上面的示例中,它指定了一个 url 重写目标,可用于重写规则部分中的 url。
See this community post for installing nginx-ingress on GKE.有关在 GKE 上安装 nginx-ingress 的信息,请参阅 此社区帖子。
You'll notice the annotations also have a cert manager specific annotation which, if installed will instruct cert manager to issue certificates based on the hosts and secrets defined under the tls
section.您会注意到注释还有一个证书管理器特定的注释,如果安装了该注释,它将指示证书管理器根据
tls
部分下定义的主机和机密颁发证书。
Using cert-manager in combination with nginx-ingress, which isn't that complicated, you can set up automatic certificate creation/renewals.将cert-manager与 nginx-ingress 结合使用,这并不复杂,您可以设置自动证书创建/更新。
It's hard to know the exact nature of your setup with deploying dynamic applications.很难知道部署动态应用程序的设置的确切性质。 But some possible ways to achieve the configuration are:
但实现配置的一些可能方法是:
The more fine grained the more control, but a lot more moving parts.粒度越细,控制越多,但活动部件也越多。 I don't see this as a problem.
我不认为这是一个问题。 For the last two options, it really depends on the nature of your dynamic application deployments.
对于最后两个选项,它实际上取决于您的动态应用程序部署的性质。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.