Question

具有一个服务的nginx入口的kubernetes集群，我正在尝试使用cert-manager和ACME ClusterIssuer通过https访问来设置该服务。

我对cert-manager遵循的步骤感到满意，但目前我处于挑战ch-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求解器pod的k8s节点的ip。端口31344是http求解器容器的nodeIp服务的内部端口。

我试图弄清楚为什么挑战本身超时而不返回200。

我已经通过4g（而不是wifi）从手机测试了HTTP求解器的url，这样我就获得了200 OK，因此，这告诉我可以从外部通过防火墙并通过nginx进入http求解器。服务和吊舱对不对？因此，如果是这种情况，那么“让我们加密”无法从同一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后面的专用网络中。

解决方案：

在k8s集群外部的端口80上配置了本地http proxy，该本地nginx controller将请求转发到NodePort的{{1}} IP和端口25080。
在我的网络上将bind9配置为将www指向运行本地http proxy的主机。
将k8s集群的CoreDNS配置为指向bind9主机（而不是8.8.4.4等）
将我的专用网络的入口点路由器配置为将任何地址端口80发送到nginx controller的{{1}} IP和端口25080。
将我的专用网络的入口点路由器配置为将任何地址端口443发送到NodePort的{{1}} IP和端口25443。

此解决方案的主要原因是我的ISP不允许我的私有网络中的主机通过网络的公共IP地址呼出并重新进入网络。（我相信这对于ISP来说是很常见的，但我不知道用于描述这些类型的网络路由限制的术语是什么。

因此，为了使nginx controller的{{1}}窗格（在k8s集群中运行）能够完成挑战，必须使其能够到达{{1} }强制通过本地托管的NodePort进行www的网络路由，而不是出入万维网并再次进入（我的ISP不允许）。

采用此解决方案后，cert-manager吊舱可以完成挑战，然后http solver可以成功颁发证书。

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

cert-manager-Acme Http解算器返回404

1 个答案: