颁发证书作为 Secret 不存在
Issuing certificate as Secret does not exist
下面是我的 clusterissuer 和 certificate 资源的 describe 输出。我是 cert-manager 的新手，所以不能 100% 确定设置是否正确——我们需要使用 http01 验证，但是我们没有使用 nginx 控制器。现在我们只有 2 个微服务，所以面向 public 的 IP 地址只属于一个 k8s 服务（负载均衡器类型），它将流量路由到一个 pod，其中一个 Extensible Service Proxy 容器位于容器 运行宁应用程序代码。使用此设置，除了以下错误之外，我什么也没得到，但是正如我提到的，我是 cert-manager 和 ESP 的新手，因此可能配置不正确...
Name: clusterissuer-dev
Namespace:
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
API Version: cert-manager.io/v1beta1
Kind: ClusterIssuer
Metadata:
Creation Timestamp: 2020-08-07T18:46:29Z
Generation: 1
Resource Version: 4550439
Self Link: /apis/cert-manager.io/v1beta1/clusterissuers/clusterissuer-dev
UID: 65933d87-1893-49af-b90e-172919a18534
Spec:
Acme:
Email: email@test.com
Private Key Secret Ref:
Name: letsencrypt-dev
Server: https://acme-staging-v02.api.letsencrypt.org/directory
Solvers:
http01:
Ingress:
Class: nginx
Status:
Acme:
Last Registered Email: email@test.com
Uri: https://acme-staging-v02.api.letsencrypt.org/acme/acct/15057658
Conditions:
Last Transition Time: 2020-08-07T18:46:30Z
Message: The ACME account was registered with the ACME server
Reason: ACMEAccountRegistered
Status: True
Type: Ready
Events: <none>
Name: test-cert-default-ns
Namespace: default
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
API Version: cert-manager.io/v1beta1
Kind: Certificate
Metadata:
Creation Timestamp: 2020-08-10T15:05:31Z
Generation: 2
Resource Version: 5961064
Self Link: /apis/cert-manager.io/v1beta1/namespaces/default/certificates/test-cert-default-ns
UID: 259f62e0-b272-47d6-b70e-dbcb7b4ed21b
Spec:
Dns Names:
dev.test.com
Issuer Ref:
Name: clusterissuer-dev
Secret Name: clusterissuer-dev-tls
Status:
Conditions:
Last Transition Time: 2020-08-10T15:05:31Z
Message: Issuing certificate as Secret does not exist
Reason: DoesNotExist
Status: False
Type: Ready
Last Transition Time: 2020-08-10T15:05:31Z
Message: Issuing certificate as Secret does not exist
Reason: DoesNotExist
Status: True
Type: Issuing
Next Private Key Secret Name: test-cert-default-ns-rrl7j
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Requested 2m51s cert-manager Created new CertificateRequest resource "test-cert-default-ns-c4wxd"
最后一项 - 如果我 运行 命令 kubectl get certificate -o wide 我得到以下输出。
NAME READY SECRET ISSUER STATUS AGE
test-cert-default-ns False clusterissuer-dev-tls clusterissuer-dev Issuing certificate as Secret does not exist 2d23h
我遇到了同样的问题，我遵循了@Popopame 在评论中给出的建议，建议查看 troubleshooting guide of cert-manager 以了解如何对 cert-manager 进行故障排除。或 [cert-managers acme 问题故障排除指南] 找出 acme 进程的哪一部分破坏了设置。
似乎经常是 letsencrypt 通过请求在特定路径的 80 端口提供特定代码来验证域所有权的 acme-challenge。例如：http://example.com/.well-known/acme-challenge/M8iYs4tG6gM-B8NHuraXRL31oRtcE4MtUxRFuH8qJmY。请注意显示 letsencrypt 的 http:// 将尝试验证所需域的端口 80 上的域所有权。
所以一个常见的错误是，证书管理器无法将正确的质询放在端口 80 后面的正确路径中。例如，由于防火墙阻止了裸机服务器上的端口 80 或负载均衡器只转发443端口到kubernetes集群，直接重定向到443。
另外请注意，cert-manager 也会尝试验证 ACME 质询，因此您应该配置防火墙以允许来自您的服务器的请求。
如果您无法将证书转移到不同的命名空间，this 将是一个很好的起点。
在您的具体情况下，我猜测 ACME 质询存在问题，因为 CSR（证书签名请求）是按照最底部描述行中的指示创建的，但没有发生其他任何事情。
1。使用 Helm 进行设置
到目前为止，我发现的最简单的方法是使用 helm v3 安装 cert-manager。我能够按如下方式在 k3s 集群上进行设置：
$ helm repo add jetstack https://charts.jetstack.io
$ helm repo update
$ helm install \
cert-manager jetstack/cert-manager \
--namespace cert-manager \
--version v1.2.0 \
--create-namespace \
--set installCRDs=true
2。设置 ClusterIssuer
安装后，您需要创建一个 ClusterIssuer，然后可以在从 let's encrypt 请求证书时使用它。
$ more cert-clusterissuer.yaml
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-stg
namespace: cert-manager
spec:
acme:
email: my_letsencrypt_email@mydom.com
server: https://acme-staging-v02.api.letsencrypt.org/directory
privateKeySecretRef:
# Secret resource that will be used to store the account's private key.
name: le-issuer-acct-key
solvers:
- dns01:
cloudflare:
email: my_cloudflare_email@mydom.com
apiTokenSecretRef:
name: cloudflare-api-token-secret
key: api-token
selector:
dnsZones:
- 'mydomdom.org'
- '*.mydomdom.org'
部署它，注意它会被部署到与 cert-manager 相同的名称空间中：
$ kubectl apply -f cert-clusterissuer.yaml
$ kubectl -n cert-manager get clusterissuers
NAME READY AGE
letsencrypt-stg True 53m
3。设置 Cloudflare API 令牌秘密
将您的 Cloudflare API 令牌部署到一个秘密中，再次将其放入 cert-manager 命名空间：
$ more cloudflare-api-token.yaml
apiVersion: v1
kind: Secret
metadata:
name: cloudflare-api-token-secret
namespace: cert-manager
type: Opaque
stringData:
api-token: <my cloudflare api token key>
$ kubectl -n cert-manager -f cloudflare-api-token.yaml
4。创建测试证书
现在尝试从 let's encrypt 请求生成证书：
$ more test-certificate.yaml
apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
name: le-test-mydomdom-org
namespace: cert-manager
spec:
secretName: le-test-mydomdom-org
issuerRef:
name: letsencrypt-stg
kind: ClusterIssuer
commonName: 'le-test.mydomdom.org'
dnsNames:
- "le-test.mydomdom.org"
$ kubectl -n cert-manager apply -f test-certificate.yaml
5。调试证书创建
然后您可以在请求流经各个阶段时观察该请求。我相信流程是 certificates -> certificaterequests -> orders -> challenges.
注意： 了解这个一般流程对我理解请求在 kubernetes 中失败的地方非常有帮助，因为我试图调试它。
调试时，您通常需要执行 kubectl get -n cert-manager <stage> -A 以查看该阶段所有未完成资源的列表。请记住，在满足 challenge 后，它将不再显示在 kubectl get -n cert-manager challenges.
的输出中
另外请记住，为完成挑战阶段而创建的任何 DNS 条目通常会将其 TTL 设置为 ~2 分钟，因此如果您查看 Cloudflare UI 并且没有看到它们，它们可能已经超时并退出。
例如：
参考资料
下面是我的 clusterissuer 和 certificate 资源的 describe 输出。我是 cert-manager 的新手，所以不能 100% 确定设置是否正确——我们需要使用 http01 验证，但是我们没有使用 nginx 控制器。现在我们只有 2 个微服务，所以面向 public 的 IP 地址只属于一个 k8s 服务（负载均衡器类型），它将流量路由到一个 pod，其中一个 Extensible Service Proxy 容器位于容器 运行宁应用程序代码。使用此设置，除了以下错误之外，我什么也没得到，但是正如我提到的，我是 cert-manager 和 ESP 的新手，因此可能配置不正确...
Name: clusterissuer-dev
Namespace:
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
API Version: cert-manager.io/v1beta1
Kind: ClusterIssuer
Metadata:
Creation Timestamp: 2020-08-07T18:46:29Z
Generation: 1
Resource Version: 4550439
Self Link: /apis/cert-manager.io/v1beta1/clusterissuers/clusterissuer-dev
UID: 65933d87-1893-49af-b90e-172919a18534
Spec:
Acme:
Email: email@test.com
Private Key Secret Ref:
Name: letsencrypt-dev
Server: https://acme-staging-v02.api.letsencrypt.org/directory
Solvers:
http01:
Ingress:
Class: nginx
Status:
Acme:
Last Registered Email: email@test.com
Uri: https://acme-staging-v02.api.letsencrypt.org/acme/acct/15057658
Conditions:
Last Transition Time: 2020-08-07T18:46:30Z
Message: The ACME account was registered with the ACME server
Reason: ACMEAccountRegistered
Status: True
Type: Ready
Events: <none>
Name: test-cert-default-ns
Namespace: default
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
API Version: cert-manager.io/v1beta1
Kind: Certificate
Metadata:
Creation Timestamp: 2020-08-10T15:05:31Z
Generation: 2
Resource Version: 5961064
Self Link: /apis/cert-manager.io/v1beta1/namespaces/default/certificates/test-cert-default-ns
UID: 259f62e0-b272-47d6-b70e-dbcb7b4ed21b
Spec:
Dns Names:
dev.test.com
Issuer Ref:
Name: clusterissuer-dev
Secret Name: clusterissuer-dev-tls
Status:
Conditions:
Last Transition Time: 2020-08-10T15:05:31Z
Message: Issuing certificate as Secret does not exist
Reason: DoesNotExist
Status: False
Type: Ready
Last Transition Time: 2020-08-10T15:05:31Z
Message: Issuing certificate as Secret does not exist
Reason: DoesNotExist
Status: True
Type: Issuing
Next Private Key Secret Name: test-cert-default-ns-rrl7j
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Requested 2m51s cert-manager Created new CertificateRequest resource "test-cert-default-ns-c4wxd"
最后一项 - 如果我 运行 命令 kubectl get certificate -o wide 我得到以下输出。
NAME READY SECRET ISSUER STATUS AGE
test-cert-default-ns False clusterissuer-dev-tls clusterissuer-dev Issuing certificate as Secret does not exist 2d23h
我遇到了同样的问题，我遵循了@Popopame 在评论中给出的建议，建议查看 troubleshooting guide of cert-manager 以了解如何对 cert-manager 进行故障排除。或 [cert-managers acme 问题故障排除指南] 找出 acme 进程的哪一部分破坏了设置。
似乎经常是 letsencrypt 通过请求在特定路径的 80 端口提供特定代码来验证域所有权的 acme-challenge。例如：http://example.com/.well-known/acme-challenge/M8iYs4tG6gM-B8NHuraXRL31oRtcE4MtUxRFuH8qJmY。请注意显示 letsencrypt 的 http:// 将尝试验证所需域的端口 80 上的域所有权。
所以一个常见的错误是，证书管理器无法将正确的质询放在端口 80 后面的正确路径中。例如，由于防火墙阻止了裸机服务器上的端口 80 或负载均衡器只转发443端口到kubernetes集群，直接重定向到443。
另外请注意，cert-manager 也会尝试验证 ACME 质询，因此您应该配置防火墙以允许来自您的服务器的请求。
如果您无法将证书转移到不同的命名空间，this 将是一个很好的起点。
在您的具体情况下，我猜测 ACME 质询存在问题，因为 CSR（证书签名请求）是按照最底部描述行中的指示创建的，但没有发生其他任何事情。
1。使用 Helm 进行设置
到目前为止，我发现的最简单的方法是使用 helm v3 安装 cert-manager。我能够按如下方式在 k3s 集群上进行设置：
$ helm repo add jetstack https://charts.jetstack.io
$ helm repo update
$ helm install \
cert-manager jetstack/cert-manager \
--namespace cert-manager \
--version v1.2.0 \
--create-namespace \
--set installCRDs=true
2。设置 ClusterIssuer
安装后，您需要创建一个 ClusterIssuer，然后可以在从 let's encrypt 请求证书时使用它。
$ more cert-clusterissuer.yaml
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-stg
namespace: cert-manager
spec:
acme:
email: my_letsencrypt_email@mydom.com
server: https://acme-staging-v02.api.letsencrypt.org/directory
privateKeySecretRef:
# Secret resource that will be used to store the account's private key.
name: le-issuer-acct-key
solvers:
- dns01:
cloudflare:
email: my_cloudflare_email@mydom.com
apiTokenSecretRef:
name: cloudflare-api-token-secret
key: api-token
selector:
dnsZones:
- 'mydomdom.org'
- '*.mydomdom.org'
部署它，注意它会被部署到与 cert-manager 相同的名称空间中：
$ kubectl apply -f cert-clusterissuer.yaml
$ kubectl -n cert-manager get clusterissuers
NAME READY AGE
letsencrypt-stg True 53m
3。设置 Cloudflare API 令牌秘密
将您的 Cloudflare API 令牌部署到一个秘密中，再次将其放入 cert-manager 命名空间：
$ more cloudflare-api-token.yaml
apiVersion: v1
kind: Secret
metadata:
name: cloudflare-api-token-secret
namespace: cert-manager
type: Opaque
stringData:
api-token: <my cloudflare api token key>
$ kubectl -n cert-manager -f cloudflare-api-token.yaml
4。创建测试证书
现在尝试从 let's encrypt 请求生成证书：
$ more test-certificate.yaml
apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
name: le-test-mydomdom-org
namespace: cert-manager
spec:
secretName: le-test-mydomdom-org
issuerRef:
name: letsencrypt-stg
kind: ClusterIssuer
commonName: 'le-test.mydomdom.org'
dnsNames:
- "le-test.mydomdom.org"
$ kubectl -n cert-manager apply -f test-certificate.yaml
5。调试证书创建
然后您可以在请求流经各个阶段时观察该请求。我相信流程是 certificates -> certificaterequests -> orders -> challenges.
注意： 了解这个一般流程对我理解请求在 kubernetes 中失败的地方非常有帮助，因为我试图调试它。
调试时，您通常需要执行 kubectl get -n cert-manager <stage> -A 以查看该阶段所有未完成资源的列表。请记住，在满足 challenge 后，它将不再显示在 kubectl get -n cert-manager challenges.
另外请记住，为完成挑战阶段而创建的任何 DNS 条目通常会将其 TTL 设置为 ~2 分钟，因此如果您查看 Cloudflare UI 并且没有看到它们，它们可能已经超时并退出。
例如：