☰

Kubernetes Nginx Ingress und Cert-Manager Warten auf HTTP-01-Challenge-Propagation: falscher Statuscode „401“, erwartet „200“

tag-icon • tag-icon nginx ssl-certificate kubernetes cert-manager
Kubernetes Nginx Ingress und Cert-Manager Warten auf HTTP-01-Challenge-Propagation: falscher Statuscode „401“, erwartet „200“

Ich habe Probleme mit meiner Rapberry Pi Kubernetes-Implementierung

Problem:

Aufgrund eines 401-Fehlercodes bei der Bare-Metal-Kubernetes-Installation wartet bei mir eine Cert-Manager-Letsencrypt-ACME-Challenge.

Aufstellen

Plattform: Raspberry Pi 4

Betriebssystem: Ubuntu Server 20.04.3 LTS 64 Bit

Eingang: Nginx

Loadbalancer: Metallb

Vernetzung: Calico

Ich habe Metallb und Nginx über Helm installiert mit:

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>

Und

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

Mein Letsencrypt sieht folgendermaßen aus:

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

Mein Nginx-Ingress-Setup sieht folgendermaßen aus:

---
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)
---

Debuggen

Wenn ich mir die Ingress-Controller-Protokolle (anderer Namespace) ansehe, sehe ich:

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

Aber der Endpunkt scheint zu existieren, wenn ich kubectl get endpoints -A mache

Mein Zertifikat liegt vor als:

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

Ich habe die empfohlenen Debugschritte des Zertifikatsmanagers befolgt und das Problem bis zu den Herausforderungen verfolgt, wobei ich Folgendes erhalte:

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

Ich stecke irgendwie fest. Ich habe so viel gegoogelt, wie ich konnte, aber es scheint nicht viel darüber zu geben. Ich schätze, ich habe es bei der Einrichtung vermasselt, aber ich bin hauptsächlich der Dokumentation auf den entsprechenden Seiten gefolgt. Ich wäre für jeden Hinweis sehr dankbar :). Wenn Sie weitere Informationen benötigen, lassen Sie es mich wissen. Dies ist derzeit ziemlich lang, also habe ich versucht, die Punkte aufzunehmen, die ich für problematisch hielt.

Antwort1

In meinem Fall zeigte der Clusterissuer auf die falsche Ingress-Klasse

kubectl bearbeitet Cluster-Aussteller XXXX

solvers:
- http01:
    ingress:
      class: nginternal

Stellen Sie sicher, dass die Klasse auf dasselbe wie der Eingang verweist.

Antwort2

Die Lösung für diese Frage bestand darin, dass mein Router kein NAT-Loopback durchführen konnte.

Mein Problem wurde durch den Kauf eines Routers mit dieser Funktion gelöst. Hoffentlich hilft das jedem, der solche Probleme hat.

verwandte Informationen