首页
学习
活动
专区
圈层
工具
发布
50 篇文章
1
kubernetes与velero的第一次尝试
2
在Kubernetes中如何针对Namespace进行资源限制?
3
kubernetes之metrics-server安装与配置
4
kubernetes部署metrics-server
5
Kubernetes1.20.9摘掉一个master节点再重新加入(ETCD需要注意的)
6
Kubernetes 1.17.17升级到1.18.20
7
Kubernetes 1.18.20升级到1.19.12
8
Kubernetes 1.19.12升级到1.20.9(强调一下selfLink)
9
Kubernetes 1.16.15升级到1.17.17
10
使用 kainstall 工具一键部署 kubernetes 高可用集群
11
附034.Kubernetes_v1.21.0高可用部署架构二
12
附016.Kubernetes_v1.17.4高可用部署
13
附022.Kubernetes_v1.18.3高可用部署架构一
14
附024.Kubernetes_v1.18.3高可用部署架构二
15
使用 StatefulSet 部署 etcd 集群
16
Kubernetes 稳定性保障手册 -- 极简版
17
Linux(centos7)离现安装kubernetes1.19.2和docker——组件部分
18
docker register 私有仓库部署 - http模式
19
KubeSphere 开源 KubeEye:Kubernetes 集群自动巡检工具
20
K8S 中的 CPUThrottlingHigh 到底是个什么鬼?
21
全链路分布式跟踪系统 Apache SkyWalking 入门教程
22
pod Evicted的状态究竟是何人所为
23
使用 ezctl 工具部署和管理 Kubernetes 集群
24
Kubernetes部署策略详解
25
kubernetes容器探针检测
26
使用Spring Boot实现动态健康检查HealthChecks
27
真一文搞定 ingress-nginx 的使用
28
K8S备份、恢复、迁移神器 Velero
29
一次关于k8s kubectl top 和 contained ps 不一致的问题探究
30
kubernetes备份恢复之velero
31
使用 Velero 进行集群备份与迁移
32
TKE集群中nginx-ingress使用实践
33
使用velero进行kubernetes灾备
34
Kubernetes 映射外部服务
35
运维体系建设套路
36
k8s解决pod调度不均衡的问题
37
ingress中虚拟路径解决方案
38
容器下的两地三中心建设
39
k8s集群外的主机访问pod的解决方案
40
k8s基础-健康检查机制
41
k8s基础-标签使用
42
ingress-nginx请求改写
43
nginx ingress server alias 多域名多证书问题
44
JAVA | Java 解决跨域问题 花式解决跨域问题
45
如何通过ingress-nginx实现应用灰度发布?
46
在Kubernetes(k8s)中使用GPU
47
使用 Prometheus-Operator 监控 Calico
48
使用Kubespray部署Kubernetes集群
49
云原生下的CI/CD:Argo CD 详解,手把手教你入门
50
Pod的健康检查机制
清单首页k8s文章详情

nginx ingress server alias 多域名多证书问题

背景

有时候需要多域名指向同一个 ingress 路由规则,比如 a.com a.cn 指向同一个 server

问题

通过查阅nginx-ingress的官方文档,可以知道有一个annotations 叫 server alias

https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#server-alias 可以帮助我们完成上述需求,

eg如下:

代码语言:javascript
复制
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: aaa-ingress
  annotations:
    nginx.ingress.kubernetes.io/server-alias: "a.cn"
  labels:
    name: aaa
spec:
  rules:
    - host: a.com
      http:
        paths:
          - path: /
            backend:
              serviceName: aaa
              servicePort: 80

这里有个问题,我们知道 在一个域名时,我们配证书一般是这样配置的

根据密钥生成证书secret

代码语言:javascript
复制
kubectl create secret tls a-com-https --key a-com.key --cert a-com.crt
代码语言:javascript
复制
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: aaa-ingress
	annotations:
    nginx.ingress.kubernetes.io/server-alias: "a.cn"
  labels:
    name: aaa
spec:
  rules:
    - host: a.com
      http:
        paths:
          - path: /
            backend:
              serviceName: aaa
              servicePort: 80
	tls:
    - hosts:
        - a.com
      secretName: a-com-https

很简单的就配置好了

自然而然,在多域名时候仿照上述配置就有了如下配置

代码语言:javascript
复制
kubectl create secret tls a-cn-https --key a-cn.key --cert a-cn.crt
代码语言:javascript
复制
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: aaa-ingress
	annotations:
    nginx.ingress.kubernetes.io/server-alias: "a.cn"
  labels:
    name: aaa
spec:
  rules:
    - host: a.com
      http:
        paths:
          - path: /
            backend:
              serviceName: aaa
              servicePort: 80
	tls:
    - hosts:
        - a.com
      secretName: a-com-https
		- hosts:
        - a.cn
      secretName: a-cn-https

然后我们分别访问一下 a.coma.cn

此时 a.com 可以正常访问,但是 a.cn 会提示证书错误

这是为什么呢?

我们可以进入到 nginx-ingress-controller 的容器内看下生成的 nginx.conf,看看他到底帮我们做了些什么?

这是生成后的nginx.conf

我们可以看到,实际上,nginx-ingress-controller 把设置的 alias 全部配置到了 server_name 中,此时证书加载的其实是 a.com (tls 下的第一个证书),自然而且第二个域名访问时出现证书错误也是合理的。

解决

知道了问题所在,那可以怎么解决一下呢?

不用 server alias 就好了,每一个域名转发规则单独配置

代码语言:javascript
复制
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: aaa-ingress
  labels:
    name: aaa
spec:
  rules:
		- host: a.cn
      http:
        paths:
          - path: /
            backend:
              serviceName: aaa
              servicePort: 80
    - host: a.com
      http:
        paths:
          - path: /
            backend:
              serviceName: aaa
              servicePort: 80
	tls:
    - hosts:
        - a.com
      secretName: a-com-https
		- hosts:
        - a.cn
      secretName: a-cn-https

上述配置就可以完成,但是同样也带来了一个问题

就是每个规则都需要配置多遍,但如果后期改动没有同时修改,就会导致出错。但目前没有找到合适的解决方案

结论

上述的解决方案还是有问题的,同时在生产环境上,一般也不是 ingress 的 lb 直接提供服务,一般外层还会有一层 cdn,我觉得将 tls 证书绑定在云厂商的 cdn 上比较合适,cdn 到 lb 直接使用 http 进行转发,同时还可以享受云厂商提供的证书的动态更新功能,自己在 ingress 管理证书在每年换证书时还需要手动更新一次。

下一篇
举报
领券