☰

Kubernetes Nginx Ingress и cert-manager Ожидание распространения вызова HTTP-01: неверный код статуса «401», ожидалось «200»

tag-icon • tag-icon nginx ssl-certificate kubernetes cert-manager
Kubernetes Nginx Ingress и cert-manager Ожидание распространения вызова HTTP-01: неверный код статуса «401», ожидалось «200»

У меня возникли проблемы с реализацией kubernetes на rapberry pi

Проблема:

У меня есть ожидание вызова ACME cert-manager letsencrypt из-за кода ошибки 401 при установке Kubernetes на «голое железо».

Настраивать

Платформа: Raspberry Pi 4

ОС: Ubuntu Server 20.04.3 LTS 64 бит

Входящий трафик: Nginx

Балансировщик нагрузки: Metallb

Нетворкинг: Calico

Я установил metallb и nginx через helm, используя:

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>

и

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

Мой letsencrypt выглядит так:

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

Моя настройка Ingress nginx выглядит следующим образом:

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

Отладка

Когда я смотрю логи контроллера Ingress (другое пространство имен), я вижу:

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

Но конечная точка, похоже, существует, когда я выполняю kubectl get endpoints -A

Мой сертификат существует как:

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

Следуя рекомендуемым отладочным шагам от менеджера по сертификации, я отследил проблему до проблем, в результате которых я получаю:

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

Я немного застрял. Я гуглил, как мог, но, похоже, об этом не так уж много информации. Думаю, я запутался в настройке, но в основном следовал документации на соответствующих страницах. Буду очень признателен за любые указания :). Если вам нужна дополнительная информация, дайте мне знать, в настоящее время это довольно длинное сообщение, поэтому я попытался включить то, что, по моему мнению, было проблемными моментами.

решение1

В моем случае clusterissuer указывал на неправильный класс Ingress

kubectl edit clusterissuer XXXX

solvers:
- http01:
    ingress:
      class: nginternal

Убедитесь, что класс указывает на то же, что и ingress.

решение2

Решением этого вопроса было то, что мой маршрутизатор не мог выполнять NAT loopback.

Получение маршрутизатора с такой функциональностью решило мою проблему. Надеюсь, это поможет всем, у кого есть такие проблемы.

Связанный контент