深入分析cert-manager中HTTP-01挑战404错误的排查与解决

在Kubernetes环境中使用cert-manager进行证书管理时，HTTP-01挑战过程可能会出现404错误。本文将通过一个实际案例，详细分析这类问题的排查思路和解决方法。

问题现象

用户在使用cert-manager 1.13.2版本（后升级至1.14.5）时，部署了三组相似的Ingress资源，其中两组工作正常，但第三组始终无法完成证书签发。具体表现为：

1. 挑战pod正常运行，日志显示已成功接收挑战请求
2. 直接访问挑战pod IP或通过Ingress访问挑战路径均返回404错误
3. cert-manager持续报告"wrong status code '404', expected '200'"错误

排查过程

初步验证

首先验证了挑战pod的基本功能：

• 确认pod处于运行状态
• 通过curl直接访问pod IP和端口，确认404响应来自pod本身
• 检查pod日志，发现确实记录了挑战请求

环境对比

对比工作正常和不正常的Ingress配置，发现两者几乎完全相同，唯一的区别是主机名不同。这表明问题可能不在Ingress配置本身，而是与环境中的其他因素有关。

深入分析

通过进一步排查发现：

1. 系统中存在一个遗留的nginx服务，专门用于处理ACME挑战
2. 该服务配置了/.well-known/acme-challenge/路径的Ingress规则
3. 这个遗留配置与新部署的cert-manager挑战pod产生了冲突

问题根源

问题的根本原因在于路径冲突：

1. cert-manager创建的挑战pod虽然运行，但由于遗留Ingress规则的存在，无法正确接收和响应挑战请求
2. 外部请求被遗留的nginx服务拦截，而该服务没有对应的挑战token，因此返回404
3. 即使直接访问挑战podIP，也因为某种原因（可能是内部路由或配置）无法获取正确的挑战响应

解决方案

最终解决方案非常简单：

1. 删除包含遗留nginx服务的整个namespace
2. 移除所有相关的Ingress规则
3. cert-manager立即开始正常工作，顺利完成挑战并签发证书

经验总结

1. 环境清理：在部署新服务前，确保清理所有相关的遗留配置
2. 路径冲突检查：当出现404错误时，不仅要检查目标服务，还要检查是否有其他服务可能拦截相同路径
3. 分层验证：从podIP直接访问可以帮助确定问题是出在服务本身还是路由层面
4. 日志分析：即使日志显示请求已接收，也要确认请求是否被正确处理

最佳实践建议

1. 在部署cert-manager前，全面检查环境中是否存在其他ACME挑战处理机制
2. 使用命名空间隔离不同的ACME挑战处理服务
3. 定期清理不再使用的测试资源
4. 考虑使用DNS-01挑战方式，可以避免HTTP路径相关的冲突问题

通过这个案例，我们可以看到Kubernetes环境中配置冲突可能导致cert-manager工作异常。系统化的排查方法和对环境的全面了解是解决这类问题的关键。