Добавление TSL в Kubernetes LoadBalancer при одновременной поддержке пересылки долгоживущего TCP-соединения в контейнер - PullRequest
Новая
       2

Добавление TSL в Kubernetes LoadBalancer при одновременной поддержке пересылки долгоживущего TCP-соединения в контейнер

0 голосов
/ 07 февраля 2020

Мне нужно развернуть бэкэнд-сервис в GKE. Эта внутренняя служба состоит из REST API и TCP-сервера, который будет использоваться несколькими устройствами IoT. Следуя инструкциям в документации по Google Kubernetes Engine, я смог развернуть следующую службу, которая достигает этого: 

apiVersion: v1
kind: Service
    metadata:
      name: my-service
    spec:
      type: LoadBalancer
      selector:
        app: my-backend-app
      ports:
      - name: http
        protocol: TCP
        port: 80
        targetPort: 8080
      - name: https
        protocol: TCP
        port: 443
        targetPort: 8080
      - name: my-tcp-service
        protocol: TCP
        port: 2222
        targetPort: 2222

Проблема с вышеуказанной конфигурацией заключается в том, что я не могу настроить TSL для моего REST API , Все ресурсы, которые я найду для настройки TSL в Kubernetes, указывают мне на Ingress, и, попробовав это, я обнаружил, что Ingress не будет работать с моим TCP-сервером, поскольку Ingress является (насколько я понимаю) своего рода HTTP-прокси.

Можно ли каким-либо образом настроить TSL (HTTPS) непосредственно на LoadBalancer без необходимости входа (предпочтителен сертификат Google, управляемый)? Должен ли я использовать Ingress для REST API и что-то еще для TCP-сервера?

1 Ответ

2 голосов
/ 07 февраля 2020

Тип сервиса LoadBalancer является строго сервисом уровня 4, поэтому на LB невозможно реализовать терминирование SSL. Traffi c будет перенаправлен на ваши модули, и там должно произойти завершение SSL. Либо это, либо вам понадобится, чтобы прокси-сервер получил трафик c и завершил TLS, прежде чем пересылать трафик c в ваше приложение.

Вход в настоящее время является единственным вариантом, который можно использовать для сертификатов, управляемых Google. Вы правы, что он использует HTTP-прокси для завершения запросов. Если вы можете сделать так, чтобы все запросы приходили с использованием разных URL-адресов, вы могли бы использовать один вход, даже для службы TCP (внешний интерфейс все равно будет 443, но вы можете перенаправлять запросы на порт 2222).

Однако наилучшим вариантом будет использование Ingress с управляемыми сертификатами для служб HTTP (S) и использование службы LoadBalancer для службы TCP.

...