Сертификаты Cert-Manager не найдены и проблемы не созданы

Я подписался на https://docs.cert-manager.io/en/venafi/tutorials/quick-start/index.html от начала до конца, и, похоже, все работает, за исключением того, что я не получаю внешний IP-адрес для моего входа.

NAME                     HOSTS                                  ADDRESS   PORTS     AGE
staging-site-ingress   staging.site.io,staging.admin.site.io,             80, 443   1h

Хотя я могу использовать внешний IP-адрес контроллера входящего трафика nginx и использовать DNS для доступа к сайтам. Когда я перехожу к URL-адресам, меня перенаправляют на https, поэтому я предполагаю, что все работает нормально.

Он перенаправляет на https, но по-прежнему говорит «не защищен», поэтому он не получает выданный сертификат.

При отладке я получаю следующую информацию:

Вход:

Events:
  Type    Reason             Age                From                      Message
  ----    ------             ----               ----                      -------
  Normal  CreateCertificate  54m                cert-manager              Successfully created Certificate "tls-secret-staging"
  Normal  UPDATE             35m (x3 over 1h)   nginx-ingress-controller  Ingress staging/staging-site-ingress
  Normal  CreateCertificate  23m (x2 over 35m)  cert-manager              Successfully created Certificate "letsencrypt-staging-tls"

Сертификат:

Status:
  Conditions:
    Last Transition Time:  2019-02-27T14:02:29Z
    Message:               Certificate does not exist
    Reason:                NotFound
    Status:                False
    Type:                  Ready
Events:
  Type    Reason        Age               From          Message
  ----    ------        ----              ----          -------
  Normal  OrderCreated  3m (x2 over 14m)  cert-manager  Created Order resource "letsencrypt-staging-tls-593754378"

Секрет:

Name:         letsencrypt-staging-tls
Namespace:    staging
Labels:       certmanager.k8s.io/certificate-name=staging-site-io
Annotations:  <none>

Type:  kubernetes.io/tls

Data
====
ca.crt:   0 bytes
tls.crt:  0 bytes
tls.key:  1679 bytes

Порядок:

Status:
  Certificate:   <nil>
  Finalize URL:  
  Reason:        
  State:         
  URL:           
Events:          <none>

Так что вроде что-то идет не так по порядку и никаких проблем не возникает.

Вот мои ingress.yaml и Issueer.yaml:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: staging-site-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"    
    certmanager.k8s.io/issuer: "letsencrypt-staging"
    certmanager.k8s.io/acme-challenge-type: http01
spec:
  tls:
  - hosts:
    - staging.site.io
    - staging.admin.site.io
    - staging.api.site.io
    secretName: letsencrypt-staging-tls
  rules:
    - host: staging.site.io
      http:
        paths:
          - backend:
              serviceName: frontend-service
              servicePort: 80
            path: /
    - host: staging.admin.site.io
      http:
        paths:
          - backend:
              serviceName: frontend-service
              servicePort: 80
            path: /
    - host: staging.api.site.io
      http:
        paths:
          - backend:
              serviceName: gateway-service
              servicePort: 9000
            path: /
apiVersion: certmanager.k8s.io/v1alpha1
kind: Issuer
metadata:
  name: letsencrypt-staging
  namespace: staging
spec:
  acme:
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    email: [email protected]
    privateKeySecretRef:
      name: letsencrypt-staging-tls
    http01: {}

Кто-нибудь знает, что я могу сделать, чтобы исправить это или что пошло не так? Certmanager установлен правильно на 100%, я просто не уверен насчет ingress и что пошло не так в порядке.

Заранее спасибо!

РЕДАКТИРОВАТЬ: я нашел это в контроллере nginx-ingress:

W0227 14:51:02.740081       8 controller.go:1078] Error getting SSL certificate "staging/letsencrypt-staging-tls": local SSL certificate staging/letsencrypt-staging-tls was not found. Using default certificate

Он рассылается спамом, загрузка ЦП всегда на уровне 0,003, а график ЦП заполнен (другие службы почти ничего не значат)


person JC97    schedule 27.02.2019    source источник
comment
При использовании Nginx в качестве контроллера Ingress вы получаете доступ ко всем своим маршрутам Ingress через внешний IP-адрес службы Nginx. Так что отсутствие внешнего ip для моего входа - обычное дело. Чего вам не хватает, так это создания записи DNS на *.site.io для перенаправления на внешний IP-адрес Nginx. Конечно, вам нужно владеть сайтом site.io.   -  person Seboudry    schedule 27.02.2019
comment
На самом деле это не проблема, потому что у nginx-ingress-controller есть внешний IP-адрес, и когда я создаю записи DNS с этим IP-адресом, я могу отлично получить доступ к URL-адресам даже с https, но на https я получаю сообщение о том, что соединение небезопасно . Сайт - это просто заполнитель, потому что я не хочу публиковать здесь настоящий URL :)   -  person JC97    schedule 27.02.2019
comment
Хорошо;) Просто вижу, что вы не можете использовать letsencrypt-staging-tls в качестве секрета TLS в ваших правилах входа. Это тот, который используется эмитентом Let's Encrypt. Вы также можете просмотреть журналы модулей задач или диспетчера сертификатов, чтобы получить некоторые подсказки.   -  person Seboudry    schedule 27.02.2019
comment
Просто видите, что вы не можете использовать letsencrypt-staging-tls в качестве секрета TLS в ваших правилах входа. Вы можете объяснить, что вы имеете в виду? И капсул испытаний по какой-то причине нет   -  person JC97    schedule 27.02.2019
comment
Если вы будете уделять внимание файлам быстрого запуска, вы заметите разницу по сравнению с вашими. Особенно Ingress.   -  person Seboudry    schedule 01.03.2019
comment
Я думаю, что это может произойти разными способами - у меня была эта проблема, и она заключалась в том, что секрет был в неправильном пространстве имен, когда я обновлялся с 0.5 до 0.6. Нашел в журналах диспетчера сертификатов: kubectl logs certmanager-12345 -n cert-manager.   -  person mikebridge    schedule 08.03.2019


Ответы (1)


Однажды я наткнулся на ту же проблему, следуя точно такому же официальному руководству. Как упоминал @mikebridge, проблема заключается в несоответствии пространства имен Issuer / Secret.

Для меня лучше всего было переключиться с Issuer на ClusterIssuer, область действия которого не ограничена одним пространством имен.

person Nepomucen    schedule 11.03.2019
comment
Да, для меня clusterissuer тоже было решением, но мне также пришлось создать руководство по сертификатам. Как только я «заставил» cert-manager создать сертификат, он тоже смог перейти к автоматически созданным сертификатам. - person JC97; 11.03.2019