ingress-nginx、cert-manager 和 ingressClassName

Question

我最近将ingress-nginx升级到了 1.0.3 版。

因此，我从 ingress 中删除了kubernetes.io/ingress.class注释，并使用.spec.ingressClassName代替。

我正在运行cert-manager-v1.4.0 。

今天早上我收到一封电子邮件，说我的 Let's Encrypt 证书将在 10 天后过期。 我试图找出它有什么问题 - 不肯定这完全是由于 ingress-nginx 升级。

我删除了CertificateRequest以查看它是否会自行修复。 我通过挑战获得了一个新的Ingress ，但是：

1. 挑战入口正确设置了kubernetes.io/ingress.class注释，即使我的入口使用.spec.ingressClassName代替 - 不知道如何或为什么，但似乎应该没问题。

2. 但是，入口控制器没有接收到挑战入口，它说：

ingress class annotation is not equal to the expected by Ingress Controller

我想它只需要.spec.ingressClassName即使我认为注释也应该起作用。

所以我在挑战入口上手动设置.spec.ingressClassName 。 入口控制器立即看到了它，其余的过程运行顺利，我得到了一个新证书 - 是的。

在我看来，这种情况会再次发生，所以我需要知道如何：

1. 说服cert-manager使用.spec.ingressClassName而不是kubernetes.io/ingress.class创建挑战入口。 也许这是在 1.5 或 1.6 中修复的？

2. 说服ingress-nginx尊重挑战入口的kubernetes.io/ingress.class注释。 我不知道为什么这不起作用。

Answer 1

问题

该问题已通过证书续订解决，无需在挑战入口中手动设置spec.ingressClassName即可正常工作（我在旧版本中看到过），问题出在其他地方。

同样在最后可用的（在编写时） cert-manager v1.5.4挑战入口具有“开箱即用”的正确设置：

spec:
  ingressClassName: nginx
---
$ kubectl get ing
NAME                        CLASS    HOSTS            ADDRESS         PORTS     AGE
cm-acme-http-solver-szxfg   nginx    dummy-host       ip_address      80        11s

工作原理（概念）

我将描述此过程如何工作的主要步骤，以便在几乎所有情况下都可以直接进行故障排除。 我将作为issuer进行letsencypt staging 。

当请求创建certificate时有一个链， issuer遵循该链来完成（所有资源都有所有者 - 链中的先前资源）：

main ingress resource -> certificate -> certificaterequest -> order -> challenge -> challenge ingress 。

知道了这一点，如果出现问题，您可以通过链向下并使用kubectl describe命令查找问题出现的位置。

故障排除示例

我故意在入口.spec.tls.hosts错误的域添加到.spec.tls.hosts并应用它。 下面是链的样子（所有名称都是唯一的！）：

见证书：

$ kubectl get cert
NAME                     READY   SECRET                          AGE
lets-secret-test-2       False   lets-secret-test-2              15m

描述我们感兴趣的certificate （你可以注意到我改变了域，已经有秘密了）：

$ kubectl describe cert lets-secret-test-2
Events:
  Type    Reason     Age   From          Message
  ----    ------     ----  ----          -------
  Normal  Issuing    16m   cert-manager  Existing issued Secret is not up to date for spec: [spec.commonName spec.dnsNames]
  Normal  Reused     16m   cert-manager  Reusing private key stored in existing Secret resource "lets-secret-test-2"
  Normal  Requested  16m   cert-manager  Created new CertificateRequest resource "lets-secret-test-2-pvb25"

这里没什么可疑的，继续前进。

$ kubectl get certificaterequest
NAME                           APPROVED   DENIED   READY   ISSUER                REQUESTOR                                         AGE
lets-secret-test-2-pvb25       True                False   letsencrypt-staging   system:serviceaccount:cert-manager:cert-manager   19m

描述certificaterequest请求：

$ kubectl describe certificaterequest lets-secret-test-2-pvb25
Events:
  Type    Reason           Age   From          Message
  ----    ------           ----  ----          -------
  Normal  cert-manager.io  19m   cert-manager  Certificate request has been approved by cert-manager.io
  Normal  OrderCreated     19m   cert-manager  Created Order resource default/lets-secret-test-2-pvb25-2336849393

同样，一切看起来都很好，没有错误，继续order ：

$ kubectl get order
NAME                                  STATE     AGE
lets-secret-test-2-pvb25-2336849393   pending   21m

它说pending ，那更接近：

$ kubectl describe order lets-secret-test-2-pvb25-2336849393

Events:
  Type    Reason   Age   From          Message
  ----    ------   ----  ----          -------
  Normal  Created  21m   cert-manager  Created Challenge resource "lets-secret-test-2-pvb25-2336849393-3788447910" for domain "dummy-domain"

Challenge可能会有所启发，继续前进：

$ kubectl get challenge
NAME                                             STATE     DOMAIN           AGE
lets-secret-test-2-pvb25-2336849393-3788447910   pending   dummy-domain   23m

描述它：

$ kubectl describe challenge lets-secret-test-2-pvb25-2336849393-3788447910

检查status ：

Status:
  Presented:   true
  Processing:  true
  Reason:      Waiting for HTTP-01 challenge propagation: failed to perform self check GET request 'http://dummy-domain/.well-known/acme-challenge/xxxxyyyyzzzzz': Get "http://dummy-domain/.well-known/acme-challenge/xxxxyyyyzzzzz": dial tcp: lookup dummy-domain on xx.yy.zz.ww:53: no such host
  State:       pending

现在很明显domain ，值得检查一下：

发现并修复了mistake ：

$ kubectl apply -f ingress.yaml
ingress.networking.k8s.io/ingress configured

秘密ready ！

$ kubectl get cert
NAME                     READY   SECRET                          AGE
lets-secret-test-2       True    lets-secret-test-2              26m

使用 cert-manager 更新证书的正确方法

可以通过删除相应的机密来更新证书，但是文档说不推荐这样做：

删除与证书资源关联的 Secret 资源不是手动轮换私钥的推荐解决方案。 手动轮换私钥的推荐方式是使用以下命令触发证书资源的重新发布（需要 kubectl cert-manager 插件）：

kubectl cert-manager renew cert-1

Kubectl cert-manager命令安装过程在这里描述以及其他命令和示例。

有用的链接：

• 证书管理器证书 - 概念
• 证书管理器 - 证书请求
• ACME 订单和挑战