Cert-Manager中Ingress资源缺失TLS配置导致证书签发失败的故障分析

问题背景

在使用Cert-Manager管理Kubernetes集群中的TLS证书时，用户遇到了一个典型问题：某个特定的Ingress资源未能自动获取预期的SSL证书。尽管其他新部署的应用能够正常获得证书，但针对openldap/openldap-phpldapadmin这个Ingress的证书请求始终未能成功处理。

故障现象

通过检查Cert-Manager控制器的日志，发现以下关键错误信息：

ingress 'openldap/openldap-phpldapadmin' in work queue no longer exists

这表明控制器在尝试处理该Ingress资源时，发现资源已不存在于工作队列中。同时注意到该Ingress仅配置了以下注解：

cert-manager.io/cluster-issuer: letsencrypt-prod-issuer
cert-manager.io/common-name: ldap.xxx.xx

根本原因分析

经过深入排查，发现问题根源在于Ingress资源缺少了关键的TLS配置段。Cert-Manager的工作原理是：

1. 通过Ingress资源上的注解识别需要签发证书的域名
2. 检查Ingress规范中的tls部分以确定证书应该关联的主机名
3. 创建对应的Certificate资源

当Ingress资源缺少tls配置时，Cert-Manager无法完整处理证书签发流程，最终导致控制器将请求从工作队列中丢弃。

解决方案

修复方法是为Ingress资源添加正确的TLS配置，例如：

tls:
- hosts:
  - ldap.xxx.xx
  secretName: openldap-phpldapadmin-tls

这个配置明确指定了：

1. 需要证书保护的主机名
2. 存储证书的Secret名称

经验总结

这个案例揭示了Cert-Manager使用中的一个重要实践：完整的Ingress配置必须包含：

1. 正确的Cert-Manager注解（指定签发者）
2. TLS配置段（定义证书关联的域名和存储位置）

对于Kubernetes管理员来说，当遇到证书未自动签发的情况时，检查清单应该包括：

1. Ingress资源的注解配置
2. TLS部分的完整性
3. Cert-Manager控制器的日志信息
4. 相关Certificate资源的状态

通过系统性地验证这些要素，可以快速定位和解决大多数证书签发问题。这个案例也提醒我们，在迁移或重建集群时，确保所有配置的完整性至关重要，特别是那些容易被忽视的细节部分。