Jetstack cert-manager и частный кластер GKE (не удалось проверить учетную запись ACME) - PullRequest
Новая
       28

Jetstack cert-manager и частный кластер GKE (не удалось проверить учетную запись ACME)

0 голосов
/ 01 ноября 2019

Я установил сертификат-менеджер Jetstack в своем частном кластере GKE. Все прошло хорошо, но я не могу получить сертификат. Я получаю ошибку: 

E1101 03:45:15.754642       1 sync.go:184] cert-manager/controller/challenges "msg"="propagation check failed" "error"="wrong status code '404', expected '200'" "dnsName"="[snip]" "resource_kind"="Challenge" "resource_name"="[snip]-certificate-2096248848-189663135-2951658629" "resource_namespace"="default" "type"="http-01" 
I1101 03:45:15.755017       1 controller.go:135] cert-manager/controller/challenges "level"=0 "msg"="finished processing work item" "key"="default/[snip]-certificate-2096248848-189663135-2951658629" 
I1101 03:45:25.755400       1 controller.go:129] cert-manager/controller/challenges "level"=0 "msg"="syncing item" "key"="default/[snip]-certificate-2096248848-189663135-2951658629" 
I1101 03:45:25.755810       1 pod.go:58] cert-manager/controller/challenges/http01/selfCheck/http01/ensurePod "level"=0 "msg"="found one existing HTTP01 solver pod" "dnsName"="[snip]" "related_resource_kind"="Pod" "related_resource_name"="cm-acme-http-solver-b6k59" "related_resource_namespace"="default" "resource_kind"="Challenge" "resource_name"="[snip]-certificate-2096248848-189663135-2951658629" "resource_namespace"="default" "type"="http-01" 
I1101 03:45:25.755897       1 service.go:43] cert-manager/controller/challenges/http01/selfCheck/http01/ensureService "level"=0 "msg"="found one existing HTTP01 solver Service for challenge resource" "dnsName"="[snip]" "related_resource_kind"="Service" "related_resource_name"="cm-acme-http-solver-qsvbv" "related_resource_namespace"="default" "resource_kind"="Challenge" "resource_name"="[snip]-certificate-2096248848-189663135-2951658629" "resource_namespace"="default" "type"="http-01" 
I1101 03:45:25.755960       1 ingress.go:91] cert-manager/controller/challenges/http01/selfCheck/http01/ensureIngress "level"=0 "msg"="found one existing HTTP01 solver ingress" "dnsName"="[snip]" "related_resource_kind"="Ingress" "related_resource_name"="cm-acme-http-solver-br7d2" "related_resource_namespace"="default" "resource_kind"="Challenge" "resource_name"="[snip]-certificate-2096248848-189663135-2951658629" "resource_namespace"="default" "type"="http-01"

Это соответствует событию ошибки в развернутом мною ClusterIssuer:

Предупреждение ErrVerifyACMEAccount 27 м (x4 свыше 28 м) cert-manager Не удалось проверить учетную запись ACME: Получить https://acme -v02.api.letsencrypt.org / directory : dial tcp: Тайм-аут ввода-вывода

Из-за этого мой CertificateRequest и Certificate ресурсы постоянно остаются в состоянии ожидания.

Это происходит во время первоначального создания кластера. Моя конфигурация для диспетчера сертификатов и входа выглядит следующим образом: 

apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
  name: letsencrypt-uat
spec:
  acme:
    email: cert-manager+uat@[snip]
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: letsencrypt-uat-private-key
    solvers:
    - http01:
        ingress:
          class: nginx

apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
  name: [snip]-uat-certificate
spec:
  secretName: [snip]-uat-tls-cert
  duration: 2160h
  renewBefore: 360h
  commonName: [snip]
  dnsNames:
  - [snip]
  issuerRef:
    name: letsencrypt-uat
    kind: ClusterIssuer

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: [snip]-uat-tls-ingress
  namespace: default
  annotations:
    kubernetes.io/ingress.class: "nginx"
    cert-manager.io/cluster-issuer: letsencrypt-uat
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
    nginx.ingress.kubernetes.io/affinity: "cookie"
spec:
  rules:
  - host: [snip]
    http:
      paths:
      - backend:
          serviceName: [snip]-uat-webapp-service
          servicePort: 80
  tls:
  - hosts:
    - [snip]
    secretName: [snip]-uat-tls-cert

Я нахожусь в частном кластере GKE и поэтому также не смог запустить компонент webhook. Документация, кажется, подразумевает, что это нормально, но не рекомендуется, чтобы работать таким образом.

Кроме того, я отмечаю, что в документации упоминается необходимость добавить правило брандмауэра, чтобы веб-крючок работал. И мне интересно, уместно ли это здесь? Представленная выше ошибка, похоже, указывает на какую-то проблему, связанную с сетью (брандмауэром?).

Сведения об окружении: : GKE (1.14.7-gke.10) Kubernetes (v1.16.2) (Я думаю) cert-manager (0.11.0)

Установлен с kubectl

Нужно ли настраивать правило брандмауэра, возможно?

Большое спасибо, Бен

Редактировать 1:

"dial tcp: i / o timeout" - красная сельдь. Эта ошибка сохраняется только до тех пор, пока DNS инициализируется с моим кластером. Я также подхожу ближе к выводу, что ошибка распространения - это просто LetsEncrypt DNS, который не видит мой домен, связанный с моим IP-адресом (пока).

Правильно ли использовать здесь запись A? Я сделал обновление DNS около часа назад - есть ли способ увидеть то, что видит DNS LetsEncrypt?

1 Ответ

0 голосов
/ 03 ноября 2019

Хорошо, спасибо вам обоим за помощь. Оказывается, это не имеет ничего общего с cert-менеджером. У меня здесь были две проблемы:

  1. В то время, когда я делал это из-за проблем с сетями, была проблема с GCP (это только вызвало путаницу);
  2. Мое приложение былонеправильно отвечает на запрос HTTP.

Однако, в конце концов, по другим причинам, я решил использовать DNS-решатель. Это сработало просто отлично.

Еще раз спасибо!

...