ingress nginx，cert-manager和ingressClassName

Question

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

因此，我从入口中删除了kubernetes.io/ingress.class注释，并将.spec.ingressClassName放在后面。

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

今天早上，我收到一封电子邮件，说我的加密证书在10天内到期。我试着找出它的问题所在-不是肯定的，完全是由于进口-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

它是如何工作的(概念)

我将描述这个过程是如何工作的主要步骤，所以在几乎所有情况下，故障排除都是直接的。我要把letsencypt staging当作issuer。

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

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

知道了这一点，如果有什么问题发生了，您可以按链子向下走，并使用kubectl describe命令查找问题出现的位置。

故障排除示例

我故意在.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有问题，值得检查一下：

发现并修正了“错误”：

$ 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

使用证书管理器更新证书的正确方法

可以通过删除相应的秘密来更新证书，但是，文档上说不推荐

删除与证书资源关联的秘密资源是，而不是手动旋转私钥的推荐解决方案。手动旋转私钥的推荐方法是使用以下命令触发证书资源的重新颁发(需要kubectl证书管理器插件)： kubectl cert-manager renew cert-1

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

有用的链接：

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