google-kubernetes-engine - 不存在作为 Secret 颁发的证书

Question

以下是describe我的 clusterissuer 的输出和 certificate资源。我是 cert-manager 的新手，所以不能 100% 确定它设置正确 - 我们需要使用 http01验证但是我们没有使用 nginx Controller 。现在我们只有 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 在评论中给出的建议，建议查看 troubleshooting guide of cert-manager了解如何对证书管理器进行故障排除。或 [cert-managers acme 问题故障排除指南] 以找出 acme 过程的哪一部分破坏了设置。
看起来，letencrypt 通过请求在特定路径的端口 80 上提供特定代码来验证域所有权，这似乎通常是最大的挑战。例如:http://example.com/.well-known/acme-challenge/M8iYs4tG6gM-B8NHuraXRL31oRtcE4MtUxRFuH8qJmY .请注意 http://这表明 letencrypt 将尝试验证所需域的端口 80 上的域所有权。
所以常见的错误之一是，证书管理器无法将正确的挑战放在端口 80 后面的正确路径中。例如，由于防火墙阻止了裸机服务器上的端口 80，或者负载均衡器仅将端口 443 转发到kubernetes 集群并直接重定向到 443。
另请注意，cert-manager 也会尝试验证 ACME 质询，因此您应该配置防火墙以允许来自您的服务器的请求。
如果您在将证书获取到不同的命名空间时遇到问题，this将是一个很好的起点。
在您的具体情况下，我猜测 ACME 挑战存在问题，因为 CSR(证书签名请求)是按照最底部的描述行所示创建的，但没有其他任何事情发生。