k8s-v1.18.4-tke.37 + dnspod-0.3.3 自动续费免费证书遇到问题了，创建的certificate一直为false状态！

[helong1997]

我的k8s版本为 v1.18.4-tke.37 ，dnspod版本为 0.3.3，cert-manager版本为1.7.0
想实现k8s证书的自动续期，域名是dnspod上申请的，但是创建的certificate一直为false状态（中间换了cert-manager几个版本都不行）。

[helong1997]

这是certificate日志，请帮我分析下可能是什么问题？？

[xlh001]

请问该问题你已经解决了吗? @helong1997

[BetaCat0]

需要去看一下自定义资源(CRD) acme.cert-manager.io/v1 下的 Challenge 的状态，还需要结合下 cert-manager 服务本身的运行日志判断当前问题。
我在 cert-manager 1.9.1 + k8s 1.28.3-aliyun.1 + 这个 repo 的 master 版本把 ACME (DNS01) 跑起来了。
分享下我遇到的状况：

• 需求
  给类似 *.example.com 做通配证书。
• 过程
  我是根据 cert-manager官方文档 创建 issuer 开始一步一步配置，查阅了DNS01文档，安装了这个 webhook 。第一轮状况就和 @helong1997 看到的情况一样。我读了下源码发现首先我的 issuer 配置有问题，最后 issuer spec 配置大概是这样：

...
spec:
  acme:
    email: <邮箱>
    privateKeySecretRef:
      name: letsencrypt-staging
    server: 'https://acme-staging-v02.api.letsencrypt.org/directory'
    solvers:
      - dns01:
          cnameStrategy: Follow # 这个配置来自 https://cert-manager.io/docs/configuration/acme/dns01/#delegated-domains-for-dns01，我这里因为是 CNAME 解析，所以也就加了
          webhook:
            config:
              apiID: <DNS pod 配置的 api-id，就是有些  ACME bot 里的 PD_ID>
              apiTokenSecretRef:
                key: api-token
                name: <存储了api-token的 secret 对象，key 就是上面 key 对应的名称（这里是  api-token）>
            groupName: <安装 webhook 时填写的 groupName>
            solverName: dnspod # 源码里发现的
        selector:
          dnsZones:
            - example.com # 结合我的需求就是这样配置 dns zone

...

配置完成后，重试流程。发现这次是 cert-manager 报权限错误，原因是 cert-manager 下的 cert-manager-webhook-dnspod 这个 serviceaccount 没有权限读取我配置的 secret (就是 webhook.config.config.apiTokenSecretRef.name 指向的这个 secret)。
检查了相关的 role 和 rolebinding，我把 role 换到了 clusterrole，rolebinding 也换到了 clusterrolebinding。当然这块可以灵活处理，在相应的 namespace 下创建新的 role，再创建和 cert-manager 下的 cert-manager-webhook-dnspod 的 rolebinding 也是 ok 的。最后可以通过运行

kubectl -n <目标命名空间> auth can-i get secrets --as=system:serviceaccount:cert-manager:cert-manager-webhook-dnspod 

检查是否具备权限。
顺便一提我把 role 中的 rules 权限改成了可以 get 所有 secret，和安装配置不太一样：

...
rules:
- apiGroups:
  - ""
  resources:
  - secrets
  verbs:
  - get
  - watch

解决了上述问题，我重启了一下 cert-manager 的 cert-manager-webhook-dnspod deployment。
重试流程，这次一直卡在我请求的域名的 propagation check（通过检查 cert-manager 日志）。查阅相关文档 ，在 cert-manager 里加了它说的额外启动参数（kubectl apply 的直接改 deployment 里 container 的启动参数就行），就可以了。
接下来的错误就是 letscecrypt 服务器一直没有检查到那个 TXT 的记录，再翻了下文档配置了那个 CNAME ，至此就再没有遇到其他问题了。

• 总结
  cert-manager-webhook-dnspod 程序功能上没有问题，但是文档不够完整（缺少how-to）。如果从官方文档示例开始配置，就会遇到前面说的权限错误的问题，因此感觉作者也可以适当提权，提升使用体验。
  另外看到 cert-manager 下有个 cert-manager-webhook-dnspod-cluster-issuer cert-manager.io/v1 的 Clusterissuer ，可能作者本意是让大家用这个，如果有文档描述它的部署结构就好了。

[BetaCat0]

更新：在ingress侧使用 cert-manager.io/cluster-issuer: cert-manager-webhook-dnspod-cluster-issuer就没有前面说的权限问题了，配置了其他 issuer 了我才恍然大悟 x x