以 Secret 形式颁发证书不存在

Question

下面是我的clusterissuer 和certificate 资源的describe 输出。我是 cert-manager 的新手，所以不能 100% 确定设置是否正确 - 我们需要使用 http01 验证，但是我们没有使用 nginx 控制器。现在我们只有 2 个微服务，所以面向公众的 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

Answer 1

我遇到了同样的问题，我遵循了 @Popopame 在 cmets 中给出的建议，建议查看 troubleshooting guide of cert-manager 以了解如何对 cert-manager 进行故障排除。或 [cert-managers 针对 acme 问题的故障排除指南] 找出 acme 流程的哪一部分破坏了设置。

似乎经常是最激烈的挑战，letsencrypt 通过请求在特定路径的端口 80 上提供特定代码来验证域所有权。例如：http://example.com/.well-known/acme-challenge/M8iYs4tG6gM-B8NHuraXRL31oRtcE4MtUxRFuH8qJmY。请注意显示letsencrypt的http://将尝试在您所需域的端口80上验证域所有权。

因此，常见错误之一是 cert-manager 无法将正确的质询放在端口 80 后面的正确路径中。例如，由于防火墙阻止了裸机服务器上的端口 80 或仅转发端口的负载均衡器443到kubernetes集群，直接重定向到443。

另外请注意，cert-manager 也会尝试验证 ACME 质询，因此您应该配置防火墙以允许来自您的服务器的请求。

如果您无法将证书转移到不同的命名空间，this 将是一个很好的起点。

在您的具体情况下，我猜想 ACME 质询存在问题，因为 CSR（证书签名请求）已创建，如最底部的描述行所示，但没有其他任何事情发生。

Answer 2

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 -n cert-manager <stage> -A 以查看该阶段内所有未完成资源的列表。请记住，在满足 challenge 后，它将不再显示在 kubectl -n cert-manager challenges 的输出中。

另外请记住，为完成挑战阶段而创建的任何 DNS 条目通常会将其 TTL 设置为约 2 分钟，因此，如果您查看 Cloudflare UI 并没有看到它们，它们可能已经超时并滚滚。

例如：

参考文献

• https://cert-manager.io/docs/configuration/acme/
• Installing and using cert-manager with k3s
• Install and Setup Cert-Manager for Automated SSL Certificates
• Make SSL certs easy with k3s
• Installing cert-manager on Kubernetes with CloudFlare DNS - Update