Kubernetes nginx маршрутизация на основе входящего пути HTTPS в AWS - PullRequest
Новая
       14

Kubernetes nginx маршрутизация на основе входящего пути HTTPS в AWS

0 голосов
/ 31 октября 2019

Вопрос: Как в Kubernetes настроить вход nginx для обработки трафика из эластичного балансировщика нагрузки как HTTPS, когда он определен как TCP?

Я работаю с кластером Kubernetes всреда AWS. Я хочу использовать вход nginx для маршрутизации трафика HTTPS на основе путей;однако я не хочу выполнить SSL-завершение или повторное шифрование на балансировщике эластичной нагрузки AWS.

Требуемая настройка:

клиент -> балансировщик эластичной нагрузки ->Вход nginx -> pod

Требования:
1. Трафик должен быть зашифрован сквозным.
2. Необходимо использовать AWS ELB (трафик не может поступать напрямую в Kubernetes извнеМир).

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

Насколько я могу судить, я могу настроить TCP-транзит через ConfigMap , но это всего лишь другоепройти через;он не позволяет мне выполнять маршрутизацию на основе путей в nginx.

Я ищу способ определить ELB как TCP (для сквозного прохождения), при этом входящий тракт обрабатывает трафик как HTTPS.

Я могу определить ELB как HTTPS, но затем есть второй, ненужный шаг согласования / прерывания / повторного шифрования в процессе, который я хочу избежать, если это вообще возможно.

1 Ответ

1 голос
/ 01 ноября 2019

Для ясности я начну с модель OSI , которая говорит нам, что TCP - это протокол уровня 4 и HTTP / HTTPSпротокол уровня 7 . Так что, откровенно говоря, HTTP/HTTP данные - это инкапсулированные данные в TCP перед выполнением инкапсуляции остальных уровней для передачи пакета на другое сетевое устройство.

Если вы настроили Classic (TCP)LoadBalancer останавливает чтение пакетных данных после чтения TCP-части, чего достаточно, чтобы решить (в соответствии с конфигурацией LB), на какой IP address и на IP port этот пакет данных должен быть доставлен. После этого LB берет данные полезной нагрузки TCP, оборачивает их данными другого уровня TCP и отправляет их в точку назначения (что, в свою очередь, вызывает применение всех остальных уровней OSI).

Чтобы ваша конфигурация работала должным образом,необходимо выставить nginx-ingress-controller Pod, используя NodePort service . Затем Classic ELB можно настроить для доставки трафика на любой узел кластера на порт, выбранный для этой службы NodePort. Обычно это между 30000 и 32767. Итак, ваш пул LB будет выглядеть следующим образом:

Давайте представим, что узлы кластера имеют IP-адреса 10.132.10.1...10, а порт NodePort равен 30276. 

ELB Endpoint 1:  10.132.10.1:30276
ELB Endpoint 2:  10.132.10.2:30276
...
ELB Endpoint 10: 10.132.10.10:30276

Примечание. В случае AWS ELB, я полагаю, имена узлов должны использоваться вместо IP-адресов.

Таким образом, это должно вызвать следующую последовательность распределения трафика от клиента к модулю приложения Kubernetes:

  1. Клиент отправляет пакет TCP с HTTP / HTTPS-запросом в полезной нагрузке на ELB_IP:ELB_port (a.b.c.d:80).
  2. ELB получает IP-пакет, анализирует его данные TCP, находит подходящую конечную точку из внутреннего пула (весь список узлов кластера Kubernetes) и создает другой пакет TCP с тем жеДанные HTTP / HTTPS внутри, а также заменяет IP-адрес назначения и TCP-порт назначения на кластерный IP-адрес узла и Сервисный NodePort TCP-порт (l.m.n.k:30xxx) и затем отправляет его в выбранное место назначения.
  3. Узел Kubernetes получает пакет TCP и, используя правила iptables, снова меняет IP-адрес назначения и порт назначения пакета TCP, а затем пересылает пакет (в соответствии с конфигурацией службы Nodeport) в модуль назначения. В этом случае это будет модуль nginx-ingress-controller.
  4. Модуль Nginx-ingress-controller получает пакет TCP, и, в соответствии с данными TCP, он должен доставляться локально, извлекает из него данные HTTP / HTTP и отправляет данные (запрос HTTP / HTTPS) в Nginx. процесс внутри контейнера Nginx в модуле Pod
  5. процесс Nginx в контейнере получает запрос HTTP / HTTPS, расшифровывает его (в случае HTTPS) и анализирует все заголовки HTTP.
  6. В соответствии с настройками nginx.conf процесс Nginx изменяет HTTP-запрос и доставляет его в службу кластера, заданную для настроенного пути к хосту и URL-адресу.
  7. Процесс Nginx отправляет измененный HTTP-запрос на серверную часть. application.
  8. Затем в HTTP-запрос добавляется заголовок TCP и отправляется в бэкэнд-службу IP_address:TCP_port.
  9. Правила iptables, определенные для бэкэнда, доставляют пакет в одну из конечных точек сервиса. (прикладные модули).

Примечание : чтобы завершить SSL на входном контроллере, необходимо создать сертификаты SSL, которые включают ELB IP и ELB FQDN в разделе SAN.

Примечание : Если вы хотите завершить SSL в модуле приложения, чтобы иметь сквозное шифрование SSL, вы можете настроить nginx для обхода трафика SSL.

Итог: ELB, настроенный для доставки TCP-трафика в кластер Kubernetes, прекрасно работает с контроллером nginx-ingress, если вы настроите его правильно.

В GKE (Google Kubernetes Engine), если вы создаете Сервис с типом: LoadBalancer, он создает вам именно TCP LB, который перенаправляет трафик на Service NodePort, а затем Kubernetes отвечает за его доставку в Pod. EKS (Elastic Kubernetes Service) от AWS работает примерно так же.

...