cert-manager - Acme Http Solver 返回 404

Question

拥有一个 nginx 入口的 kubernetes 集群，我正在尝试使用 cert-manager 和 ACME ClusterIssuer 设置 https 访问。

我对 cert-manager 所遵循的步骤感到相当满意，但我目前处于对 cert-manager 作为挑战过程的一部分在集群中配置的 http 求解器提出挑战的阶段。当我描述服务生成的挑战时，我看到它的状态为：

Reason:      Waiting for http-01 challenge propagation: failed to perform self check GET request 'http://www.example.com/.well-known/acme-challenge/nDWOHEMXgy70_wxi53ijEKjUHFlzg_UJJS-sv_ahGzg': Get "http://www.example.com/.well-known/acme-challenge/nDWOHEMXgy70_wxi53ijEKjUHFlzg_UJJS-sv_ahGzg": dial tcp xx.xx.xx.xxx:80: connect: connection timed out

当我从我的 k8s 主机服务器调用求解器的 url 时：

curl -H "Host: www.example.com" http://192.168.1.11:31344/.well-known/acme-challenge/nDWOHEMXgy70_wxi53ijEKjUHFlzg_UJJS-sv_ahGzg

我得到了 200 的回复。

注意：地址 192.168.1.11 是运行 http solver pod 的 k8s 节点的 ip。而 31344 端口是 http solver pod 的 nodeIp 服务的内部端口。

我试图弄清楚为什么挑战本身会超时而没有得到 200 分。

我已经通过 4g（而不是 wifi）从我的手机测试了 http 求解器的 url，这样我得到了 200 OK 所以，这告诉我 http 求解器可以从外部通过防火墙并通过 nginx 进入服务和 pod 对吗？因此，如果是这种情况，那么 Let's Encrypt 无法从同一 URL 检索令牌还有什么其他原因？

--- 当前配置 ---

集群发行者：

apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
 name: letsencrypt-staging
 namespace: cert-manager
spec:
 acme:
   # The ACME server URL
   server: https://acme-staging-v02.api.letsencrypt.org/directory
   # Email address used for ACME registration
   email: my.address@example.com
   # Name of a secret used to store the ACME account private key
   privateKeySecretRef:
     name: letsencrypt-staging
   # Enable the HTTP-01 challenge provider
   solvers:
   - selector: {}
     http01:
       ingress:
         class: nginx

入口：

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: ing-myservice-web
  namespace: myservice
  annotations:
    kubernetes.io/ingress.class: "nginx"
    cert-manager.io/cluster-issuer: "letsencrypt-staging"
spec:
  tls:
  - hosts:
    - www.example.com
    secretName: secret-myservice-web-tls
  rules:
  - host: www.example.com
    http:
      paths:
      - backend:
          serviceName: svc-myservice-web
          servicePort: 8080
        path: /
  - host: www.example.co.uk
    http:
      paths:
        - backend:
            serviceName: svc-myservice-web
            servicePort: 8080
          path: /

Answer 1

在阅读了有关 cert-manager 工作方式的各个不同方面，阅读了其他人在其他帖子上的类似问题，并更好地了解了我的网络是如何设置和从外部看到的，我在下面介绍我学到了关于我的设置的知识，以及之后我为了让cert-manager 在其中的 k8s 集群中为我的域服务工作而做了什么。

设置：

• kubernetes 集群，后端服务由 nginx 入口控制器和 NodePort 服务提供，分别为 http 和 https 公开端口 25080 和 25443。
• kubernetes 集群在 ISP 的公共 IP 后面的专用网络中。

解决方案：

• 配置了一个本地http proxy在k8s集群外的80端口上运行，它将请求转发到nginx controller的NodePort IP和25080端口。

• 在我的网络上配置 bind9 以将 www 指向运行本地 http proxy 的主机。

• 配置k8s集群的CoreDNS指向bind9主机（而不是8.8.4.4等）

• 将我的专用网络的入口点路由器配置为将任何地址端口 80 发送到 nginx controller 的 NodePort IP 和端口 25080。

• 将我的专用网络的入口点路由器配置为将任何地址端口 443 发送到 nginx controller 的 NodePort IP 和端口 25443。

此解决方案的主要原因是我的 ISP 不允许我的专用网络中的主机通过网络的公共 IP 地址呼叫和返回网络。 （我相信这对于 ISP 来说很常见，它被称为 Harpining 或 NAT Loopback，并且一些路由器具有打开它的功能。

因此，为了让 cert-manager 的 http solver pod（在 k8s 集群中运行）能够完成挑战，它必须能够通过强制网络路由到达 nginx controller通过本地托管的http proxy 访问 www，而不是访问万维网再返回（我的 ISP 不允许这样做）。

有了这个解决方案，http solver pod 能够完成挑战，然后cert-manager 能够成功颁发证书。

我确信（并且我希望）有更好、更清洁的解决方案来解决这种情况，但我自己还没有遇到过，所以这是我目前拥有的解决方案。