如何解决在 Ingress 中使用 Let's Encrypt 时出错:使用不存在将证书作为秘密颁发
我按照本教程 https://www.digitalocean.com/community/tutorials/how-to-set-up-an-nginx-ingress-with-cert-manager-on-digitalocean-kubernetes 使用证书管理器为我的入口颁发 SSL 证书,让我们加密,然后我运行此错误 Issuing certificate as Secret does not exist
。我的配置有问题吗?这是一个 Minikube 本地集群。
staging_issuer.yaml
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: email_address
# Name of a secret used to store the ACME account private key
privateKeySecretRef:
name: letsencrypt-staging
# Enable the HTTP-01 challenge provider
solvers:
- http01:
ingress:
class: nginx
ingress.yaml
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: echo-ingress
annotations:
kubernetes.io/ingress.class: "nginx"
nginx.ingress.kubernetes.io/rewrite-target: /
nginx.ingress.kubernetes.io/proxy-read-timeout: "12h"
cert-manager.io/cluster-issuer: "letsencrypt-staging"
spec:
tls:
- hosts:
- frontend.info
- backend.info
secretName: echo-tls
rules:
- host: frontend.info
http:
paths:
- backend:
serviceName: frontend
servicePort: 80
- host: backend.info
http:
paths:
- backend:
serviceName: backend
servicePort: 8080
kubectl 描述证书
Name: echo-tls
Namespace: default
Labels: <none>
Annotations: <none>
API Version: cert-manager.io/v1beta1
Kind: Certificate
Metadata:
Creation Timestamp: 2021-01-26T09:29:54Z
Generation: 1
Managed Fields:
API Version: cert-manager.io/v1alpha2
Fields Type: FieldsV1
Manager: controller
Operation: Update
Time: 2021-01-26T09:29:55Z
Owner References:
API Version: extensions/v1beta1
Block Owner Deletion: true
Controller: true
Kind: Ingress
Name: echo-ingress
UID: <UID>
Resource Version: 423812
UID: <UID>
Spec:
Dns Names:
frontend.info
backend.info
Issuer Ref:
Group: cert-manager.io
Kind: ClusterIssuer
Name: letsencrypt-staging
Secret Name: echo-tls
Status:
Conditions:
Last Transition Time: 2021-01-26T09:29:54Z
Message: Issuing certificate as Secret does not exist
Reason: DoesNotExist
Status: True
Type: Issuing
Last Transition Time: 2021-01-26T09:29:54Z
Message: Issuing certificate as Secret does not exist
Reason: DoesNotExist
Status: False
Type: Ready
Next Private Key Secret Name: echo-tls-hg5tt
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Issuing 7h56m cert-manager Issuing certificate as Secret does not exist
Normal Generated 7h56m cert-manager Stored new private key in temporary Secret resource "echo-tls-hg5tt"
Normal Requested 7h56m cert-manager Created new CertificateRequest resource "echo-tls-hmz86
解决方法
让我们从回答您关于活动的问题开始:
Events:
Type Reason Age From Message
Normal Issuing 7h56m cert-manager Issuing certificate as Secret does not exist
这不是错误,也不是阻塞因素。正如您在 type
部分看到的那样,它被标记为 Normal
。您应该担心的事件类型是 Warning
事件,如下所示:
Events:
Type Reason Age From Message
Warning Unhealthy 2m (x2 over 2m) kubelet,ip-XXX-XXX-XXX-XXX.us-west-2.compute.internal Readiness probe failed: Get http://XXX.XXX.XXX.XXX:YYY/healthz: dial tcp connect: connection refused
现在来解决您的真正问题。您提供的文档在先决条件部分明确指出,您需要有一个域名和一个 DNS A 记录,指向 Ingress 使用的 DigitalOcean 负载均衡器(在您的情况下,您希望将其指向 minikube
) .假设您是 yamls 中提到的两个域的所有者,我注意到它们指向两个不同的 IP 地址:
$ dig frontend.info
;; ANSWER SECTION:
frontend.info. 599 IN A 104.247.81.51
$ dig backend.info
;; ANSWER SECTION:
backend.info. 21599 IN A 127.0.0.1
域必须指向运行 external-ip
的机器的 minikube
地址(在我的例子中它是云虚拟机)。有了这个,这还不够,因为 minikube
通常在它自己的 docker 容器或 vm 中运行。您需要确保流量确实到达您的 minikube 集群。
为此,我使用了 kubectl port-fowarding
来公开 nginx-controller
pod:
sudo kubectl port-forward pod/ingress-nginx-controller-69ccf5d9d8-mdkrr -n kube-system 80:80 --address 0.0.0.0
Forwarding from 0.0.0.0:80 -> 80
Let's encrypt 需要有权访问您的应用程序以证明您是域的所有者。完成此操作后,您的证书对象会将其状态更改为 True
:
➜ ~ k get certificate
NAME READY SECRET AGE
echo-tls True echo-tls 104m
这是最后的测试。请注意,我使用的是我自己的域,我刚刚将其更改为 <your-domain>
。在您的情况下,这将是 frontend.info
或 backend.info
➜ ~ curl https://<your-domain> -v
-----
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN,server accepted to use h2
* Server certificate:
* subject: CN=test-domain.com
* start date: Jan 27 10:09:31 2021 GMT
* expire date: Apr 27 10:09:31 2021 GMT
* subjectAltName: host "<your-domain>" matched cert's "<your-domain>"
* issuer: C=US; O=Let's Encrypt; CN=R3
* SSL certificate verify ok.
-----
,
我也卡在那里了。但是环顾四周,这个网站似乎不断弹出https://cert-manager.io/docs/faq/troubleshooting/
我现在正在尝试自己解决问题。如果我能解决它,我会发布答案。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。