如何解决cert-manager-Acme Http解算器返回404
具有一个服务的nginx入口的kubernetes集群,我正在尝试使用cert-manager
和ACME ClusterIssuer
通过https访问来设置该服务。
我对cert-manager遵循的步骤感到满意,但目前我处于挑战ch-manager已在集群中配置为挑战过程一部分的http求解器的阶段。当我描述服务产生的挑战时,我看到它的状态为:
Reason: Waiting for http-01 challenge propagation: failed to perform self check GET request 'http://www.example.com/.well-known/acme-challenge/nDWOHEMXgy70_wxi53ijEKjUHFlzg_UJJS-sv_ahGzg': Get "http://www.example.com/.well-known/acme-challenge/nDWOHEMXgy70_wxi53ijEKjUHFlzg_UJJS-sv_ahGzg": dial tcp xx.xx.xx.xxx:80: connect: connection timed out
当我从k8s主机服务器调用求解器的URL时:
curl -H "Host: www.example.com" http://192.168.1.11:31344/.well-known/acme-challenge/nDWOHEMXgy70_wxi53ijEKjUHFlzg_UJJS-sv_ahGzg
我还给我200英镑。
注意:地址192.168.1.11是运行http求解器pod的k8s节点的ip。端口31344是http求解器容器的nodeIp服务的内部端口。
我试图弄清楚为什么挑战本身超时而不返回200。
我已经通过4g(而不是wifi)从手机测试了HTTP求解器的url,这样我就获得了200 OK,因此,这告诉我可以从外部通过防火墙并通过nginx进入http求解器。服务和吊舱对不对?因此,如果是这种情况,那么“让我们加密”无法从同一URL检索令牌还有什么其他原因?
-当前配置---
集群发行人:
apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
name: letsencrypt-staging
namespace: cert-manager
spec:
acme:
# The ACME server URL
server: https://acme-staging-v02.api.letsencrypt.org/directory
# Email address used for ACME registration
email: my.address@example.com
# Name of a secret used to store the ACME account private key
privateKeySecretRef:
name: letsencrypt-staging
# Enable the HTTP-01 challenge provider
solvers:
- selector: {}
http01:
ingress:
class: nginx
入口:
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: ing-myservice-web
namespace: myservice
annotations:
kubernetes.io/ingress.class: "nginx"
cert-manager.io/cluster-issuer: "letsencrypt-staging"
spec:
tls:
- hosts:
- www.example.com
secretName: secret-myservice-web-tls
rules:
- host: www.example.com
http:
paths:
- backend:
serviceName: svc-myservice-web
servicePort: 8080
path: /
- host: www.example.co.uk
http:
paths:
- backend:
serviceName: svc-myservice-web
servicePort: 8080
path: /
解决方法
在阅读了cert-manager
的工作原理的各个方面之后,在其他帖子上阅读了其他人的类似问题,并更好地了解了我的网络是如何建立的以及如何从外部看到的。在下面介绍我所了解的设置知识以及其后的工作,以使cert-manager
在其中的k8s集群中为我的域服务工作。
设置:
- kubernetes集群的后端服务以
nginx
入口控制器开头,并带有NodePort
服务,分别暴露了HTTP和https的端口25080和25443。 - kubernetes群集在ISP的公共IP后面的专用网络中。
解决方案:
-
在k8s集群外部的端口80上配置了本地
http proxy
,该本地nginx controller
将请求转发到NodePort
的{{1}} IP和端口25080。 -
在我的网络上将
bind9
配置为将www指向运行本地http proxy
的主机。 -
将k8s集群的
CoreDNS
配置为指向bind9
主机(而不是8.8.4.4等) -
将我的专用网络的入口点路由器配置为将任何地址端口80发送到
nginx controller
的{{1}} IP和端口25080。 -
将我的专用网络的入口点路由器配置为将任何地址端口443发送到
NodePort
的{{1}} IP和端口25443。
此解决方案的主要原因是我的ISP不允许我的私有网络中的主机通过网络的公共IP地址呼出并重新进入网络。 (我相信这对于ISP来说是很常见的,但我不知道用于描述这些类型的网络路由限制的术语是什么。
因此,为了使nginx controller
的{{1}}窗格(在k8s集群中运行)能够完成挑战,必须使其能够到达{{1} }强制通过本地托管的NodePort
进行www的网络路由,而不是出入万维网并再次进入(我的ISP不允许)。
采用此解决方案后,cert-manager
吊舱可以完成挑战,然后http solver
可以成功颁发证书。
我确信(并且我希望)有更好,更清洁的解决方案来解决这种情况,但是我自己还没有遇到任何问题,所以这是我目前拥有的解决方案。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。