Estoy tratando de volver a implementar de GKE a Digital Ocean. Tengo un problema con el desafío de letsencrypt. Creo que K8s me dice que no se puede encontrar la ruta. Los dos nombres de host/dominios que letsencrypt intenta hacer el desafío y falla son CNAMES utilizados por SendGrid. No estoy muy seguro de por dónde empezar a solucionar problemas, mi google-fu me está fallando.
Namespace: default Labels: <none> Annotations: <none> API Version: acme.cert-manager.io/v1alpha2 Kind: Challenge Metadata: Creation Timestamp: 2020-03-19T20:34:04Z Finalizers: finalizer.acme.cert-manager.io Generation: 1 Owner References: API Version: acme.cert-manager.io/v1alpha2 Block Owner Deletion: true Controller: true Kind: Order Name: letsencrypt-certs-80407504-346698183 UID: 84ab9399-3a61-462e-a1c5-0831bd451a36 Resource Version: 37060 Self Link: /apis/acme.cert-manager.io/v1alpha2/namespaces/default/challenges/letsencrypt-certs-80407504-346698183-813483524 UID: ca14d996-3ecf-4dd8-8c53-057af7ae2b27 Spec: Authz URL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/3449670327 Dns Name: 7502121.secodify.com Issuer Ref: Group: cert-manager.io Kind: ClusterIssuer Name: letsencrypt-prod Key: LiAawBR0bFRQfb2oXrvvNhph3ehQ-35lXJKkpjqgqb0.uWH4RnJfcABYba9T5b-QjoYnIw53rRtVhzsRIHIh39Y Solver: http01: Ingress: Class: nginx Token: LiAawBR0bFRQfb2oXrvvNhph3ehQ-35lXJKkpjqgqb0 Type: http-01 URL: https://acme-v02.api.letsencrypt.org/acme/chall-v3/3449670327/JGayWw Wildcard: false Status: Presented: true Processing: true Reason: Waiting for http-01 challenge propagation: wrong status code '404', expected '200' State: pending Events: <none>mi mapa de configuración se parece a:
--- apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: nginx.conf: | events { worker_connections 1024; } http { server { access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log; listen 8080; server_name localhost; location ^~ /.well-known/acme-challenge/ { default_type "text/plain"; rewrite /.well-known/acme-challenge/(.*) /$1 break; } location /static/ { autoindex on; alias /code/core/static/; include /etc/nginx/mime.types; } location = /favicon.ico { access_log off; log_not_found off; } location / { proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_pass http://127.0.0.1:8080/; } } } ---```Agregue la anotación certmanager.k8s.io/cluster-issuer a su archivo de configuración de Ingress. Problema similar: certmanager .
Además, tiene un error de sintaxis en la definición de ubicación del servidor en ConfigMap:
location ^~ /.well-known/acme-challenge/Recuerde agregar también anotaciones de clase rewrite y nginx a su archivo de configuración de Ingress.
Resulta que los CNAMES no se usaron. Después de eliminarlos de la configuración, volvería a hacer un kubectl get challenges , pero estaba en blanco. Esto se debe a que los desafíos ya fueron procesados, supongo, y por lo tanto no había ninguno pendiente.
También tuve otro problema en el que olvidé establecer la relación entre el servicio de kubernetes y los pods de implementación.
Entre los dos temas, me confundí.
Tuve el mismo error en K3S con Traefik. La razón de esto fue el DNS y el reenvío de puertos. Certmanager se prueba a sí mismo antes de comunicarse con Letsencrypt. Obtendría el mismo error si usara Nginx como enrutador.
Tengo:
Configuré varios registros A en el servidor DNS del proveedor de mis dominios:
El administrador de certificados llama a mi enrutador para probar su funcionalidad Letsencrypt en lugar de sí mismo en la Raspberry Pi.
El problema se resuelve agregando registros DNS al servidor DNS de mi enrutador para los dominios para que apunten directamente a la dirección IP interna de la Raspberry Pi.
Por supuesto: