Добавление общедоступного IP-адреса в контроллер входящего трафика Nginx с помощью MetalLB

У меня есть три узла в моем кластере, которые находятся за брандмауэром, который я не контролирую. К этому брандмауэру подключен общедоступный IP-адрес, и он может пересылать трафик на мой узел Kubernetes. У него есть порты 80 и 443, открытые для моего узла.

Изначально я использовал публичный IP в конфиге MetalLB вот так:

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: default
      protocol: layer2
      addresses:
      - 186.xx.xx.xx-186.xx.xx.xx

Но после прочтения ответа на другой вопрос я предполагаю он недействителен, поскольку IP-адрес, используемый MetalLB, должен находиться в той же подсети, что и узлы? И все они используют частные IP-адреса.

Когда я локально протестировал HTTP-сервер, прослушивающий порт 80, и запустил его на фактическом узле (а не в кластере), я смог получить ответ по общедоступному IP-адресу из-за пределов сети.

Итак, мой вопрос: Как заставить контроллер входящего трафика MetalLB или Nginx прослушивать порты 80 и 443 для входящего запроса?

При использовании curl 186.xx.xx.xx:80 одного из узлов в кластере я получаю ответ от входящего контроллера nginx. Но не тогда, когда это делается вне узла.


kubernetes kubernetes-ingress nginx-ingress metallb
person TryingMyBest    schedule 16.02.2021    source источник
comment
Предполагая, что вы можете переадресовывать трафик с вашего брандмауэра, вы пробовали это? 1. Сообщите metallb об единственном внутреннем IP-адресе, который он может назначить. 2. Измените nginx-ingress-controller Service манифест, добавив аннотацию, которая назначит этот внутренний IP-адрес Service. 3. Используйте переадресацию портов (порт 80 443) на вашем брандмауэре на этот недавно назначенный IP-адрес nginx-ingress-controller. Запустите $ curl firewall-ip:80 и посмотрите, что ваш nginx-ingress-controller отвечает.   -  person Dawid Kruk    schedule 17.02.2021
comment
Это именно то, что я сделал! Мне удалось это решить. Основная проблема заключалась в том, что глобальный IP-адрес не находился в подсети, как другие узлы.   -  person TryingMyBest    schedule 17.02.2021

Ответы (1)


arrow_upward
1
arrow_downward

Отвечая на вопрос:

Как я могу создать настройку с кластером Kubernetes и отдельным брандмауэром, чтобы пользователи могли подключаться к моему Nginx Ingress контроллеру, который предоставляет доступ к моему приложению.

Предполагая, что настройка основана на кластере Kubernetes, подготовленном во внутренней сети, и между кластером и Интернетом есть межсетевой экран, следует рассмотреть следующие моменты (могут быть некоторые производные, которые я рассмотрю):

  • Metallb подготовлено в кластере Kubernetes (при условии, что это самоуправляемое решение на чистом железе)
  • Nginx Ingress контроллер с модифицированным Service
  • Port-forwarding установлен на брандмауэре

Service типа Loadbalancer по большей части (есть некоторые исключения) - это ресурс, который требует, чтобы облачный провайдер назначил адрес External IP для вашего Service.

Примечание!

Дополнительную информацию можно найти здесь:

Для локальных решений есть инструмент metallb:

Kubernetes не предлагает реализацию балансировщиков сетевой нагрузки (службы типа LoadBalancer) для кластеров без операционной системы. Реализации Network LB, с которыми поставляется Kubernetes, представляют собой связующий код, который обращается к различным платформам IaaS (GCP, AWS, Azure…). Если вы не работаете на поддерживаемой платформе IaaS (GCP, AWS, Azure…), LoadBalancers будет оставаться в состоянии ожидания на неопределенный срок при создании.

Операторам «чистого металла» остаётся два менее значительных инструмента для доставки пользовательского трафика в свои кластеры: сервисы «NodePort» и «externalIPs». Оба этих варианта имеют существенные недостатки для производственного использования, что делает кластеры без операционной системы второстепенными в экосистеме Kubernetes.

MetalLB стремится исправить этот дисбаланс, предлагая реализацию Network LB, которая интегрируется со стандартным сетевым оборудованием, чтобы внешние сервисы на кластерах без оборудования также «просто работали» в максимально возможной степени.

Metallb.universe.tf

Следуя руководству по установке / настройке Metallb, появится конфигурация для один внутренний IP-адрес, на который брандмауэр будет отправлять трафик:

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: single-ip # <-- HERE
      protocol: layer2
      addresses:
      - 10.0.0.100/32 # <-- HERE

Этот IP-адрес будет связан с Service типа LoadBalancer контроллера Nginx Ingress.

Изменения, необходимые для Nginx Ingress манифеста (Service часть):

# Source: ingress-nginx/templates/controller-service.yaml
apiVersion: v1
kind: Service
metadata:
  annotations:
    metallb.universe.tf/address-pool: single-ip # <-- IMPORTANT
  labels:
    # <-- OMMITED --> 
  name: ingress-nginx-controller
  namespace: ingress-nginx
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  ports:
    - name: http
      port: 80
      protocol: TCP
      targetPort: http
    - name: https
      port: 443
      protocol: TCP
      targetPort: https
  selector:
    # <-- OMMITED -->

Вышеуказанные изменения в YAML манифесте гарантируют, что адрес, который был настроен в metallb ConfigMap, будет использоваться с Service.

Примечание!

Вы можете опустить metallb и использовать Service типа Nodeport, но это имеет некоторые недостатки.

Последняя часть - настроить переадресацию портов на брандмауэре. Правило должно быть следующим:

  • FIREWALL_IP:80 -> SINGLE_IP:80
  • FIREWALL_IP:443 -> SINGLE_IP:443

После этого вы сможете связываться со своим Nginx Ingress контроллером:

  • $ curl FIREWALL_IP:80

Дополнительные ресурсы:

person Dawid Kruk    schedule 21.02.2021