Как поток трафика внутри кластера Kubernetes? - PullRequest
Новая
       10

Как поток трафика внутри кластера Kubernetes?

0 голосов
/ 09 сентября 2018

(Изучая Kubernetes, я действительно не нашел хороших ресурсов, объясняющих это)

Сценарий:
У меня есть mywebsite1.com и mywebsite2.com, и я хочу разместить их в кластере Kubernetes.

Я развернул универсальный облачный входной контроллер в соответствии со следующим веб-сайтом с помощью команд 2
kubectl apply -f . (обязательный. yaml и общий ingress.yaml)
https://kubernetes.github.io/ingress-nginx/deploy/

Итак, вопрос в том, как выглядит эта архитектура? и как данные поступают в кластер?

1 Ответ

0 голосов
/ 09 сентября 2018

Я конвертирую 2 сертификата в 2 .key и 2 .crt файла
Я использую эти файлы для создания 2 секретов TLS (по 1 для каждого веб-сайта, чтобы у них был включен HTTPS)

Я создаю 2 Ingress Objects:

  • тот, который сообщает website1.com/, указывает на сервис под названием website1fe и ссылается на секретный сертификат сертификата website1 HTTPS / TLS.
    (Служба website1fe прослушивает только порт 80 и перенаправляет трафик на модули, созданные при развертывании website1fe)

  • другой говорит, что website2.com/, указывает на сервис под названием website2fe и ссылается на секретный сертификат сертификата website2 HTTPS / TLS.
    (Служба website2fe прослушивает только порт 80 и перенаправляет трафик на модули, созданные при развертывании website2fe)

У меня есть 3-х узловый кластер Kubernetes, который существует в частной подсети.
У них есть IP 

 10.1.1.10     10.1.1.11     10.1.1.12

Когда я побежал 2
kubectl применяют команды -f
Сгенерированные команды:

  • Развертывание Ingress Controller
  • Служба L7 Nginx LB типа ClusterIP, которая прослушивает порт 80 и порт 443
  • L7 развертывание Nginx LB, которое прослушивает порт 80 и порт 443
    (модули в этом развертывании управляются / конфигурируются модулем входного контроллера, который настраивает модули в желаемое состояние, заданное объектами входа)
  • Служба L7 Nginx LB типа NodePort (случайным образом выбирается из диапазона 30000 - 32767, но для ясности я скажу, что служба NodePort прослушивает порты 30080 и 30443)
  • L4 LB VM с публичным IP-адресом.

kubectl get svc --all-namespaces
Предоставляет IPv4 IP-адрес L4 LB (скажем, это 1.2.3.4)

Поскольку я владею обоими доменами: я настраиваю интернет-DNS так, чтобы website1.com и website2.com оба указывали на 1.2.3.4

Примечание. Входной контроллер известен поставщику облачных услуг, поэтому он автоматически выполнил следующую конфигурацию обратного прокси-сервера / балансировки нагрузки: 

L4LB 1.2.3.4:80 --(LB between)--> 10.1.1.10:30080, 10.1.1.11:30080, 10.1.1.12:30080
L4LB 1.2.3.4:443 --(LB between)--> 10.1.1.10:30443, 10.1.1.11:30443, 10.1.1.12:30443

KubeProxy делает так, чтобы запросы на любом порту узла 30080 или 30443 направлялись внутри кластера в LB Nginx LB Service типа ClusterIP, который затем перенаправляет трафик в L7 Nginx LB Pod.
Модули L7 Nginx LB завершают HTTPS-соединение и перенаправляют трафик на сайты website1.com и website2.com, которые прослушивают незашифрованный порт 80.
(Это нормально, что он не зашифрован, потому что мы в кластере, где никто не будет нюхать трафик.)
(LB LB знает, какую службу переадресовать на основе адреса L7, на который поступает трафик)

Обратите внимание на ошибку, чтобы избежать: Допустим, website1.com хочет получить доступ к некоторым ресурсам, которые существуют на website2.com

Ну что же, website2.com имеет 2 IP-адреса и 2 DNS-имени.
website2fe.default.svc.cluster.local <- DNS-адрес, разрешаемый внутренним кластером <br> website2.com <- Внешнее разрешение DNS-адреса <br>
Вместо того чтобы иметь доступ к ресурсам website1 через website2.com Вы должны иметь доступ к ресурсам website1 через website2fe.default.svc.cluster.local (Это более эффективная маршрутизация)

...