Проблема Kubernetes NGINX Ingress TLS

Я развернул кластер k8s в облаке (VMVare vSphere) - 3 мастера и 1 рабочий узел. Затем с установленным helm nginx-ingress:

helm install stable/nginx-ingress

Развернуто несколько модулей простых http-svc

Изменил тип службы nginx-controller с LoadBalancer на NodePort и добавил externalIPs (IP-адрес моих главных узлов), чтобы он выглядел так:

NAME                                TYPE        CLUSTER-IP      EXTERNAL-IP                              PORT(S)                       AGE
ing-nginx-ingress-controller        NodePort    10.233.15.202   172.16.40.21,172.16.40.22,172.16.40.23   80:31045/TCP,443:31427/TCP    1d
http-svc                            ClusterIP   10.233.13.55                                             80/TCP                        1d

Создан сертификат и секрет

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /tmp/tls.key -out /tmp/tls.crt -subj "/CN=<FQDN_HERE>"
kubectl create secret tls secret --key /tmp/tls.key --cert /tmp/tls.crt

И создал вход:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: some-ingress
  namespace: default
spec:
  tls:
  - hosts:
    - <FQDN_HERE>
    secretName: secret
  rules:
  - host: <FQDN_HERE>
    http:
      paths:
      - backend:
          serviceName: http-svc
          servicePort: 80
        path: /

Если я использую облачный DNAT

external_ip:8443 -> master01_ip:443 (e.g. 172.16.40.21:443)

Тогда у меня есть ответ:

curl --resolve <FQDN>:8443:<external_ip> https://<FQDN>:8443 -v -k
* Added <FQDN>:8443:<external_ip> to DNS cache
* Rebuilt URL to: https://<FQDN>:8443/
* Hostname <FQDN> was found in DNS cache
*   Trying <external_ip>...
* TCP_NODELAY set
* Connected to <FQDN> (<external_ip>) port 8443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=<FQDN>
*  start date: Feb 22 10:37:00 2018 GMT
*  expire date: Feb 22 10:37:00 2019 GMT
*  issuer: CN=<FQDN>
*  SSL certificate verify result: self signed certificate (18), continuing anyway.
> GET / HTTP/1.1
> Host: <FQDN>:8443
> User-Agent: curl/7.58.0

Но если я использую функцию балансировки нагрузки (vEdge Gateway):

                -> 172.16.40.21:443
external_ip:443 -> 172.16.40.22:443
                -> 172.16.40.23:443

Существует проблема:

curl --resolve <FQDN>:443:<external_ip> https://<FQDN> -vvvv -k
* Added <FQDN>:443:<external_ip> to DNS cache
* Rebuilt URL to: https://<FQDN>/
* Hostname <FQDN> was found in DNS cache
*   Trying <external_ip>...
* TCP_NODELAY set
* Connected to <FQDN> (<external_ip>) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to <FQDN>:443
* Closing connection 0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to <FQDN>:443

Пробовал две автономные виртуальные машины с nginx и самозаверяющим сертификатом - работало, как ожидалось. Облачный провайдер говорит, что LB работает и проблема с входом k8s.

Спасибо!


person Andrey Okhotnikov    schedule 27.02.2018    source источник
comment
LB должен быть настроен в режиме TCP, а не в режиме HTTP. Поддерживает ли это vEdge Gateway?   -  person nickgryg    schedule 27.02.2018
comment
@Nickolay спасибо за ваш ответ. Да, vEdge Gateway поддерживает балансировку нагрузки TCP, и я ее настроил. И это сработало! Но есть оговорки по поводу порта. Я не могу использовать 443 для внешнего IP (ошибка vEdge или неправильная конфигурация). Мне нужно время, чтобы задать вопросы по этому поводу и протестировать.   -  person Andrey Okhotnikov    schedule 27.02.2018


Ответы (1)


Как сказал @Nickolay, я должен был настроить балансировщик нагрузки vEdge Gateway в режиме HTTPS в режиме TCP. Но vEdge Gateway не позволяет этого, потому что порт 443 строго привязан к HTTPS. Я решил свою проблему с настройкой проверки работоспособности (!) На TCP вместо SSL, и теперь все работает.

person Andrey Okhotnikov    schedule 28.02.2018