Сбой настройки kubernetes с помощью Let’s Encrypt и Ingress — Gnutls_handshake(): получен неожиданный пакет TLS

#kubernetes #nginx-ingress #cert-manager

#kubernetes #nginx-ingress #cert-manager

Вопрос:

Я использую стандартную процедуру для включения завершения HTTPS для моего приложения, которое запущено в Kubernetes, используя: — Ingress nginx — AWS ELB classic — Менеджер сертификатов для Let’s encrypt

Я использовал процедуру, описанную здесь: https://www.digitalocean.com/community/tutorials/how-to-set-up-an-nginx-ingress-with-cert-manager-on-digitalocean-kubernetes

Раньше мне удавалось заставить Ingress работать с HTTP, но у меня проблема с HTTPS, где я получаю следующую ошибку при попытке скручивания URL приложения:

 $ curl -iv https://<SERVER>
* Rebuilt URL to: <SERVER>
*   Trying <IP_ADDR>...
* Connected to <SERVER> (<IP_ADDR>) port 443 (#0)
* found 148 certificates in /etc/ssl/certs/ca-certificates.crt
* found 592 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* gnutls_handshake() failed: An unexpected TLS packet was received.
* Closing connection 0
curl: (35) gnutls_handshake() failed: An unexpected TLS packet was received.
  

Это то, что у меня есть в настоящее время:

Менеджер сертификатов, запущенный в пространстве имен kube-system:

 $ kubectl get pods -n kube-system
    NAME                                     READY   STATUS      RESTARTS   AGE
    cert-manager-5f8db6f6c4-c4t4k            1/1     Running     0          2d1h
    cert-manager-webhook-85dd96d87-rxc7p     1/1     Running     0          2d1h
    cert-manager-webhook-ca-sync-pgq6b       0/1     Completed   2          2d1h
  

Настройка входа в пространство имен ingress-nginx:

 $ kubectl get all -n ingress-nginx
NAME                                            READY   STATUS    RESTARTS   AGE
pod/default-http-backend-587b7d64b5-ftws2       1/1     Running   0          2d1h
pod/nginx-ingress-controller-68bb4bfd98-zsz8d   1/1     Running   0          12h

NAME                           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
service/default-http-backend   ClusterIP   <IP_ADDR_1>   <none>        80/TCP                       2d1h
service/ingress-nginx          NodePort    <IP_ADDR_2>   <none>        80:32327/TCP,443:30313/TCP   2d1h

NAME                                       DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/default-http-backend       1         1         1            1           2d1h
deployment.apps/nginx-ingress-controller   1         1         1            1           12h
  

Приложение и вход в пространство имен приложений:

 $ kubectl get all -n app
NAME              READY   STATUS    RESTARTS   AGE
pod/appserver-0   1/1     Running   0          2d1h

NAME                TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)         AGE
service/appserver   ClusterIP   <IP_ADDR>   <none>        22/TCP,80/TCP   2d1h

NAME                         DESIRED   CURRENT   AGE
statefulset.apps/appserver   1         1         2d1h

$ kubectl describe ingress -n app
Name:             appserver
Namespace:        app
Address:
Default backend:  default-http-backend:80 (<none>)
TLS:
  letsencrypt-prod terminates <SERVER>
Rules:
  Host                      Path  Backends
  ----                      ----  --------
  <SERVER>
                            /   appserver:80 (<none>)
Annotations:
  certmanager.k8s.io/cluster-issuer:  letsencrypt-prod
  kubernetes.io/ingress.class:        nginx
Events:                               <none>
  

Вот как выглядит входной ресурс:

 apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    certmanager.k8s.io/cluster-issuer: letsencrypt-prod
  name: appserver
  namespace: app
spec:
  tls:
  - hosts:
    - <SERVER>
    secretName: letsencrypt-prod
  rules:
  - host: <SERVER>
    http:
      paths:
      - backend:
          serviceName: appserver
          servicePort: 80
        path: /
  

Дополнительные проверки, которые я выполнил:

Проверено, что сертификаты были сгенерированы правильно:

 $ kubectl describe cert -n app
Name:         letsencrypt-prod
...
Status:
  Conditions:
    Last Transition Time:  2019-03-20T14:23:07Z
    Message:               Certificate is up to date and has not expired
    Reason:                Ready
    Status:                True
    Type:                  Ready
  

Проверил журналы из cert-manager:

 $ kubectl logs -f cert-manager-5f8db6f6c4-c4t4k -n kube-system
...
I0320 14:23:08.368872       1 sync.go:177] Certificate "letsencrypt-prod" for ingress "appserver" already exists
I0320 14:23:08.368889       1 sync.go:180] Certificate "letsencrypt-prod" for ingress "appserver" is up to date
I0320 14:23:08.368894       1 controller.go:179] ingress-shim controller: Finished processing work item "app/appserver"
I0320 14:23:12.548963       1 controller.go:183] orders controller: syncing item 'app/letsencrypt-prod-1237734172'
I0320 14:23:12.549608       1 controller.go:189] orders controller: Finished processing work item "app/letsencrypt-prod-1237734172"
  

На данный момент не совсем уверен, что еще может стоить проверить?

Ответ №1:

Похоже, что вы используете устаревшие версии nginx-ingress с cert-manager, что может быть причиной вашей ошибки.

Я предлагаю вам попробовать развернуть nginx-ingress с помощью Helm, используя последнюю версию (убедитесь, что тег изображения равен v0.23.0 для nginx-ingress-controller). Также убедитесь, что вы развертываете свой cert-manager с последней версией (—version v0.7.0) во время развертывания helm. По умолчанию вы должны увидеть три модуля: cert-manager, cert-manager-cainjector и cert-manager-webhook.

Мне пришлось отключить webhook, потому что он препятствовал выдаче сертификата, несмотря на предоставление ему правильных параметров, поэтому вам, возможно, придется сделать то же самое.

Надеюсь, это поможет!

Комментарии:

1. Это тоже был случай. Я использовал nginx-ingress-controller версии 0.24.1 и менеджер сертификатов версии 0.6.x через helm. После обновления CM до 0.7.0 все работает должным образом.

Ответ №2:

В конце концов, похоже, что проблема была связана с тем, как я выполнил настройку слушателей в ELB classic на AWS.

Я выполнил следующее:

 HTTP 80 -> HTTP <INGRESS_SVC_NODE_PORT_1>
HTTP 443 -> HTTP <INGRESS_SVC_NODE_PORT_2>
  

Первая ошибка заключалась в том, что я использовал HTTP вместо HTTPS для порта 443. Когда я попытался использовать HTTPS, мне пришлось вводить SSL-сертификаты, что для меня не имело смысла, поскольку я выполняю завершение SSL на уровне входа с помощью Let’s encrypt.

Следовательно, следующая конфигурация прослушивателя сработала:

 TCP 80 -> TCP <INGRESS_SVC_NODE_PORT_1>
TCP 443 -> TCP <INGRESS_SVC_NODE_PORT_2>