inress-nginx、cert-manager和ingressClassName

本文介绍了inress-nginx、cert-manager和ingressClassName的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

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

因此，我从我的入口中删除了kubernetes.io/ingress.class批注，而改为使用.spec.ingressClassName。

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

今天早上我收到一封电子邮件，说我的"让我们加密"证书将在10天后过期。我试着找出问题出在哪里--我不确定这是否完全是由于inress-nginx升级造成的。

我删除了CertificateRequest，看看它是否可以自行修复。我在挑战中获得了新的Ingress，但是：

质询入口正确设置了kubernetes.io/ingress.class批注，即使我的入口设置了.spec.ingressClassName-不知道如何或为什么，但看起来应该没问题。
但是，入口控制器未拾取质询入口，它显示：

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

我猜它只需要.spec.ingressClassName，尽管我认为批注应该也能正常工作。

因此，我在质询入口上手动设置了.spec.ingressClassName。入口管理员马上看到了，流程的睡觉运行很顺利，我拿到了一个新的证书。

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

说服cert-manager使用.spec.ingressClassName而不是kubernetes.io/ingress.class创建质询入口。可能在1.5或1.6中已修复此问题？
说服ingress-nginx尊重质询入口的kubernetes.io/ingress.class注释。我不知道这为什么不起作用。

问题

此问题已通过证书续订修复，无需手动设置即可正常工作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

使用cert-manager续订证书的正确方式

可以通过删除相应的密钥续订证书，但是documentation says it's not recommended：

Kubectl cert-manager介绍命令安装流程here以及其他命令和示例。

这篇关于inress-nginx、cert-manager和ingressClassName的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！

manager和ingressClassName