Jetstack证书管理器和GKE专用集群(无法验证ACME帐户) [英] Jetstack cert-manager and GKE private cluster (failed to verify ACME account)
问题描述
我已经在我的私有GKE集群中安装了Jetstack证书管理器.一切顺利，但我无法获得证书.我得到的错误是:
I have installed the Jetstack cert-manager within my private GKE cluster. That all went well, but I can't get a certificate issued. The error that I get is:
E1101 03:45:15.754642 1 sync.go:184] cert-manager/controller/challenges "msg"="propagation check failed" "error"="wrong status code '404', expected '200'" "dnsName"="[snip]" "resource_kind"="Challenge" "resource_name"="[snip]-certificate-2096248848-189663135-2951658629" "resource_namespace"="default" "type"="http-01"
I1101 03:45:15.755017 1 controller.go:135] cert-manager/controller/challenges "level"=0 "msg"="finished processing work item" "key"="default/[snip]-certificate-2096248848-189663135-2951658629"
I1101 03:45:25.755400 1 controller.go:129] cert-manager/controller/challenges "level"=0 "msg"="syncing item" "key"="default/[snip]-certificate-2096248848-189663135-2951658629"
I1101 03:45:25.755810 1 pod.go:58] cert-manager/controller/challenges/http01/selfCheck/http01/ensurePod "level"=0 "msg"="found one existing HTTP01 solver pod" "dnsName"="[snip]" "related_resource_kind"="Pod" "related_resource_name"="cm-acme-http-solver-b6k59" "related_resource_namespace"="default" "resource_kind"="Challenge" "resource_name"="[snip]-certificate-2096248848-189663135-2951658629" "resource_namespace"="default" "type"="http-01"
I1101 03:45:25.755897 1 service.go:43] cert-manager/controller/challenges/http01/selfCheck/http01/ensureService "level"=0 "msg"="found one existing HTTP01 solver Service for challenge resource" "dnsName"="[snip]" "related_resource_kind"="Service" "related_resource_name"="cm-acme-http-solver-qsvbv" "related_resource_namespace"="default" "resource_kind"="Challenge" "resource_name"="[snip]-certificate-2096248848-189663135-2951658629" "resource_namespace"="default" "type"="http-01"
I1101 03:45:25.755960 1 ingress.go:91] cert-manager/controller/challenges/http01/selfCheck/http01/ensureIngress "level"=0 "msg"="found one existing HTTP01 solver ingress" "dnsName"="[snip]" "related_resource_kind"="Ingress" "related_resource_name"="cm-acme-http-solver-br7d2" "related_resource_namespace"="default" "resource_kind"="Challenge" "resource_name"="[snip]-certificate-2096248848-189663135-2951658629" "resource_namespace"="default" "type"="http-01"
这与我部署的ClusterIssuer中的错误事件相对应:
This corresponds with an error event in the ClusterIssuer that I deployed:
警告ErrVerifyACMEAccount 27m(x4超过28m)证书管理器无法验证ACME帐户:获取 https ://acme-v02.api.letsencrypt.org/directory :拨打tcp:输入/输出超时
Warning ErrVerifyACMEAccount 27m (x4 over 28m) cert-manager Failed to verify ACME account: Get https://acme-v02.api.letsencrypt.org/directory: dial tcp: i/o timeout
因此，我的CertificateRequest和Certificate资源永久处于待定"状态.
Because of this my CertificateRequest and Certificate resources perpetually stay in a "pending" state.
这是在初始集群创建期间发生的.我对证书管理器&的配置入口如下:
This is happening during initial cluster creation. My configuration for the certificate manager & ingress is as follows:
apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
name: letsencrypt-uat
spec:
acme:
email: cert-manager+uat@[snip]
server: https://acme-staging-v02.api.letsencrypt.org/directory
privateKeySecretRef:
name: letsencrypt-uat-private-key
solvers:
- http01:
ingress:
class: nginx
apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
name: [snip]-uat-certificate
spec:
secretName: [snip]-uat-tls-cert
duration: 2160h
renewBefore: 360h
commonName: [snip]
dnsNames:
- [snip]
issuerRef:
name: letsencrypt-uat
kind: ClusterIssuer
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: [snip]-uat-tls-ingress
namespace: default
annotations:
kubernetes.io/ingress.class: "nginx"
cert-manager.io/cluster-issuer: letsencrypt-uat
nginx.ingress.kubernetes.io/ssl-redirect: "true"
nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
nginx.ingress.kubernetes.io/affinity: "cookie"
spec:
rules:
- host: [snip]
http:
paths:
- backend:
serviceName: [snip]-uat-webapp-service
servicePort: 80
tls:
- hosts:
- [snip]
secretName: [snip]-uat-tls-cert
我在GKE专用集群上，因此也无法运行webhook组件.该文档似乎暗示可以这样运行，但不建议这样做.
I am on a GKE private cluster and have therefore also been unable to run the webhook component. The documentation seems to imply that this it's OK, but not recommended, to run this way.
此外，我注意到文档中提到了添加防火墙规则以允许Webhook正常运行的需要.我想知道这里是否也有意义?上面的错误似乎表明存在某种与网络(防火墙?)相关的问题.
Also, I note that the documentation references the need to add a firewall rule to allow the webhook to work. And I wonder if that is also relevant here? The error above seems to indicate some kind of networking (firewall?) related issue.
环境详细信息:: GKE(1.14.7-gke.10) Kubernetes(v1.16.2)(我认为) 证书管理器(0.11.0)
Environment details:: GKE (1.14.7-gke.10) Kubernetes (v1.16.2) (I think) cert-manager (0.11.0)
已安装kubectl
也许我需要配置防火墙规则吗?
Do I need to configure a firewall rule, perhaps?
非常感谢， 本
拨号TCP:I/O超时"是一个红色鲱鱼.只要DNS需要使用我的群集进行初始化，该错误就会持续存在.我也越来越接近这样的结论，即传播错误仅仅是LetsEncrypt DNS无法看到我的与IP地址相关的域(还).
The "dial tcp: i/o timeout" is a red herring. That error persists only as long as the DNS takes to initialise with my cluster. I am also coming closer to the conclusion that the propagation error is simply LetsEncrypt DNS not seeing my domain associated with my IP address (yet).
我在这里使用A记录是否正确?我大约一个小时前进行了DNS更新-有什么方法可以查看LetsEncrypt的DNS看到的内容吗?
Is it correct that I use an A record here? I made the DNS update around an hour ago - is there any way that I can see what LetsEncrypt's DNS sees?
推荐答案
好，谢谢你们的帮助.事实证明，这与证书管理器无关.我在这里玩了两个问题:
Ok thanks both for your help. It turns out that this was nothing to do with cert-manager. I had two issues in play here:
- 当时我正在做一个GCP问题来处理网络问题(这引起了混乱)；
- 我的应用程序未正确响应HTTP挑战.
但是，最终，由于其他原因，我决定使用DNS求解器.效果很好.
However, in the end, for other reasons, I decided to use the DNS solver. This worked just fine.
再次感谢！
这篇关于Jetstack证书管理器和GKE专用集群(无法验证ACME帐户)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
