☰

Kubernetes Nginx Ingress y cert-manager Esperando la propagación del desafío HTTP-01: código de estado incorrecto '401', esperado '200'

tag-icon • tag-icon nginx ssl-certificate kubernetes cert-manager
Kubernetes Nginx Ingress y cert-manager Esperando la propagación del desafío HTTP-01: código de estado incorrecto '401', esperado '200'

Tengo problemas con la implementación de mi rapberry pi kubernetes

Problema:

Tengo el desafío ACME letsencrypt de cert-manager esperando debido a un código de error 401 en la instalación básica de Kubernetes.

Configuración

Plataforma: Frambuesa Pi 4

SO: Servidor Ubuntu 20.04.3 LTS de 64 bits

Ingreso: Nginx

Balanceador de carga: Metallb

Redes: Calicó

Instalé metallb y nginx mediante helm usando:

helm install metallb metallb/metallb --namespace kube-system\
    --set configInline.address-pools[0].name=default\
    --set configInline.address-pools[0].protocol=layer2\
    --set configInline.address-pools[0].addresses[0]=<ip-range>

y

helm install ingress-nginx ingress-nginx/ingress-nginx --namespace kube-system

Mi letsencrypt se ve así:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
  namespace: cert-manager
spec:
  acme:
    email: <email redacted>
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
    - http01:
        ingress:
          class: nginx

Mi configuración de ingreso de nginx se ve así:

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: "nextcloud" # Same namespace as the deployment
  name: "nextcloud-ingress" # Name of the ingress (see kubectl get ingress -A)
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
    cert-manager.io/cluster-issuer: "letsencrypt-prod" # Encrypt using the ClusterIssuer deployed while setting up Cert-Manager
    nginx.ingress.kubernetes.io/proxy-body-size:  "125m" # Increase the size of the maximum allowed size of the client request body
spec:
  tls:
  - hosts:
    - "nextcloud.<domain redacted>" # Host to access nextcloud
    secretName: "nextcloud-prod-tls" # Name of the certificate (see kubectl get certificate -A)
  rules:
  - host: "nextcloud.<domain redacted>" # Host to access nextcloud
    http:
      paths:
        - path: /  # We will access NextCloud via the URL https://nextcloud.<domain.com>/
          pathType: Prefix
          backend:
            service: 
              name: "nextcloud-server" # Mapping to the service (see kubectl get services -n nextcloud)
              port: 
                number: 80 # Mapping to the port (see kubectl get services -n nextcloud)
---

Depuración

Cuando miro los registros del controlador de entrada (espacio de nombres diferente), veo:

Service "nextcloud/cm-acme-http-solver-9tccf" does not have any active Endpoint.

Pero el punto final parece existir cuando kubectl obtiene puntos finales -A

Mi certificado existe como:

kubectl get certificate -n nextcloud
NAME                 READY   SECRET               AGE
nextcloud-prod-tls   False   nextcloud-prod-tls   3h58m

Siguiendo los pasos de depuración recomendados por el administrador de certificados, rastreé el problema hasta los desafíos por los que obtengo:

Status:
  Presented:   true
  Processing:  true
  Reason:      Waiting for HTTP-01 challenge propagation: wrong status code '401', expected '200'
  State:       pending
Events:        <none>

Estoy un poco estancado. He estado buscando en Google pero no parece haber mucho sobre esto. Supongo que me he llenado de configuración, pero principalmente he estado siguiendo la documentación en las páginas relevantes. Cualquier consejo sería muy apreciado :). Si necesita información adicional, hágamelo saber. Actualmente, esto es bastante largo, así que intenté incluir lo que pensé que eran puntos problemáticos.

Respuesta1

En mi caso, clusterissuer apuntaba a una clase de ingreso incorrecta

kubectl editar clusterissuer XXXX

solvers:
- http01:
    ingress:
      class: nginternal

Asegúrese de que la clase apunte al mismo lugar que el ingreso.

Respuesta2

La solución a esta pregunta fue que el enrutador que tenía no era capaz de realizar un bucle NAT.

Obtener un enrutador que tuviera esta funcionalidad resolvió mi problema. Con suerte, eso ayudará a cualquiera que tenga problemas como este.

información relacionada