logo标签列表

颁发证书时，由于秘密（Secret）不存在，因此无法进行。

google-kubernetes-enginecert-manager
46
以下是我clusterissuer和certificate资源的describe输出。我刚接触 cert-manager，所以不确定是否已正确设置 - 我们需要使用http01验证方式，但我们没有使用nginx控制器。现在我们只有两个微服务，所以面向公众的IP地址只属于一个k8s服务（类型为loadbalancer），该服务将流量路由到一个pod，其中运行应用程序代码的容器前面有一个可扩展服务代理容器。使用这种设置，我无法获得任何超出下面错误的东西，但是正如我提到的，我对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
我使用了以下命令：kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.16.1/cert-manager.yaml。 - NealR
1
好的，我和你处于同样的情况，你在裸机 Kubernetes 上安装了 cert-manager 吗？你能否按照这些链接操作：https://cert-manager.io/docs/faq/troubleshooting/ 和 https://cert-manager.io/docs/faq/acme/。看看它在哪里阻塞，对我来说，它在挑战部分，因为 cert-manager 无法访问我的服务器的端口80，我明天会解决这个问题，如果你有同样的问题，请告诉我！ - Popopame
2
我解决了这个问题，对我来说，其中一个ACME挑战赛引起了麻烦，你能跟着他的链接走一下吗：https://cert-manager.io/docs/faq/troubleshooting/。很可能证书没有创建是因为在过程中出现了错误，请按照说明操作，并给我们提供精确的错误信息 :) - Popopame
2
你能解决这个问题吗？ - Shivangi Bhardwaj
这个YouTube视频对我在排除故障方面非常有帮助 - https://www.youtube.com/watch?v=BlzRx6ROiX0&ab_channel=carpie.net。视频详细介绍了整个过程。 - slm
显示剩余4条评论
3个回答
19

我遇到了同样的问题，我按照@Popopame在评论中给出的建议查看cert-manager的故障排除指南来解决cert-manager的故障，或者查看[用于acme问题的cert-manager故障排除指南]以找出acme过程中哪个部分破坏了设置。

似乎经常是acme-challenge导致问题，这是letsencrypt通过请求在特定路径上提供某个代码来验证域所有权的地方。例如：http://example.com/.well-known/acme-challenge/M8iYs4tG6gM-B8NHuraXRL31oRtcE4MtUxRFuH8qJmY。请注意 http:// ，表示letsencrypt将尝试在所需域的80端口上验证域所有权。

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

还要注意，cert-manager也会尝试验证ACME挑战，因此您应该配置防火墙允许来自您的服务器的请求。

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

在您的特定情况下，我猜测ACME挑战存在问题，因为CSR（证书签名请求）是根据最底部的描述行创建的，但没有发生其他任何事情。

1
这基本上就是问题所在。我的入口设置为强制使用https，这导致了验证失败。最初将该标志设置为“false”可以解决问题。 - NealR
我仍然不明白你是如何解决问题的，你能展示一下代码吗？ - Duru Cynthia Udoka
"Code" 取决于您的防火墙解决方案、应该响应 ACME 挑战的 Web 服务器或位于 k8s 集群前面的反向代理。因此，请检查端口 80 是否允许，如果不允许，请打开它。检查您的反向代理是否将端口 80 转发到 k8s ingress（如果您使用了反向代理）。然后检查您的 Web 服务器/ingress 是否接受端口 80 的连接并回答 ACME challenge。您可以通过在 http://<YOUR_DOMAIN>/.well-known/acme-challenge/<TOKEN> 中打开浏览器手动检查。 - sebisnow
在我的情况下，.well-known由istio管理。确保您的Pod显示2个容器 - 您的容器和注入的istio-proxy容器。如果您只看到1个容器，请执行以下操作： kubectl label namespace your-namespace istio-injection=enabled --overwrite以便部署istio-proxy。 - undefined
16

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
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 get clusterissuers
NAME              READY   AGE
letsencrypt-stg   True    53m

3. 设置 Cloudflare API Token 密钥

将您的 Cloudflare API token 部署到一个 secret 中，并将其放置在 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 apply -f cloudflare-api-token.yaml

4. 创建测试证书

现在尝试从 Let's Encrypt 请求生成证书：

$ more test-certificate.yaml
apiVersion: cert-manager.io/v1
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 中找不到它们，则很可能已经超时并被删除。

例如：

ss#1

参考资料

只有一个快速的问题，我需要为ClusterIssuer使用命名空间吗？ 文档说如果我们需要所有命名空间的证书，则需要使用不带命名空间的ClusterIssuer。 - PraveenMak
@PraveenMak 不需要为ClusterIssuer提供命名空间是没有意义的。slm应该先阅读文档-https://cert-manager.io/docs/concepts/issuer/ - Stephan Kristyn
@stevek-pro你能详细说明一下吗？我不明白这个问题。我们是在讨论ClusterIssuer yaml中的这个部分吗？namespace: cert-manager？ - slm
@stevek-pro，我们谈论的是这一部分吗？-- “如果您想创建一个可以在多个命名空间中使用的单个Issuer，则应考虑创建ClusterIssuer资源。这与Issuer资源几乎相同，但是非命名空间化，因此可以用于在所有命名空间中发行证书。” - slm
是的，你引用的K8s文档部分就是我所指的。K8s文档明确指出了“非命名空间”，但你提供了一个命名空间“cert-manager”。对我来说，那时候这并没有起作用。 - Stephan Kristyn
1

我在DigitalOcean上遇到了这个问题，对我来说，禁用proxy protocol和tls-passthrough解决了这个问题。

这些配置应该在ingress-nginx服务中进行注释：

# Enable proxy protocol
service.beta.kubernetes.io/do-loadbalancer-enable-proxy-protocol: "true"
# Specify whether the DigitalOcean Load Balancer should pass encrypted data to backend droplets
service.beta.kubernetes.io/do-loadbalancer-tls-passthrough: "true"
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接