Cert-Manager HTTP-01挑战停滞求助(MicroK8s 1.28环境)
问题分析与解决方案
核心问题定位
你遇到的connection refused错误并非因为ACME求解器监听8089端口——这个端口是cert-manager求解器的默认内部监听端口,无需直接暴露到公网。真正的问题在于:
- 你在ClusterIssuer中指定复用现有
whoamiIngress,但该Ingress配置了force-ssl-redirect: "true",会把所有HTTP请求强制重定向到HTTPS,而ACME HTTP-01挑战必须通过HTTP访问/.well-known/acme-challenge/路径,重定向直接导致挑战请求失败。 - 复用现有Ingress的方式在cert-manager 1.13版本中对路由规则的兼容性要求更严格,容易出现路由冲突。
解决方案步骤
1. 修复ClusterIssuer配置(推荐方案)
让cert-manager自动创建临时Ingress处理ACME挑战,而非复用业务Ingress:
kind: ClusterIssuer metadata: name: letsencrypt-prod spec: acme: email: your-email@example.com server: https://acme-v02.api.letsencrypt.org/directory privateKeySecretRef: name: letsencrypt-prod solvers: - http01: ingress: class: public # 匹配你的IngressClass,MicroK8s默认IngressClass为"public",可通过`kubectl get ingressclasses`确认
2. 调整业务Ingress的SSL重定向规则(可选,若坚持复用Ingress)
如果必须复用whoami Ingress,需添加注解排除ACME挑战路径的强制重定向:
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: whoami namespace: default annotations: nginx.ingress.kubernetes.io/force-ssl-redirect: "true" nginx.ingress.kubernetes.io/ssl-redirect: "true" # 添加以下注解,针对ACME挑战路径关闭重定向 nginx.ingress.kubernetes.io/configuration-snippet: | if ($request_uri ~* "^/.well-known/acme-challenge/") { return 200; } cert-manager.io/cluster-issuer: letsencrypt-prod spec: ingressClassName: public # 明确指定IngressClass,避免版本兼容性问题 rules: - host: my.domain.com http: paths: - path: / pathType: Prefix backend: service: name: whoami port: number: 80 tls: - hosts: - my.domain.com secretName: letsencrypt-prod
3. 验证基础网络配置
- 确保服务器防火墙开放80/443端口:
sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw reload - 检查MicroK8s Ingress控制器状态:
kubectl get pods -n ingress
4. 重置证书颁发流程
删除现有失效证书及相关挑战资源,重新触发颁发:
kubectl delete certificate letsencrypt-prod kubectl delete pods -l app=cm-acme-http-solver
补充说明
cert-manager的ACME求解器监听8089是正常行为:当它创建临时Ingress时,会自动将/.well-known/acme-challenge/路径的请求转发到求解器Pod的8089端口,公网仅需访问服务器的80端口即可,无需暴露8089。
内容的提问来源于stack exchange,提问作者petwri
相关产品推荐
相关产品推荐

