IP-адрес источника пакета службы балансировки нагрузки Kubernetes - PullRequest
Новая
       35

IP-адрес источника пакета службы балансировки нагрузки Kubernetes

0 голосов
/ 21 апреля 2019

У меня есть кластер версии kubernetes 1.13 (один узел в данный момент), настроенный на голое железо с помощью kubeadm.Узел имеет 2 сетевых интерфейса, подключенных к нему для целей тестирования.В идеале в будущем один интерфейс должен быть обращен к интрасети, а другой - к общедоступной сети.К тому времени количество узлов также будет больше единицы.

Для входа в интранет я использую настройку HAMroxy (https://github.com/helm/charts/tree/master/incubator/haproxy-ingress) с этой конфигурацией: 

rbac:
  create: true
serviceAccount:
  create: true
controller:
  ingressClass: "intranet-ingress"
  metrics:
    enabled: true
  stats:
    enabled: true
    service:
      type: LoadBalancer
      externalIPs:
        - 10.X.X.X # IP of one of the network interfaces
  service:
    externalIPs:
      - 10.X.X.X # IP of the same interface

Трафик затем достигает haproxy следующим образом: 

1. Client's browser, workstation has an IP from 172.26.X.X range 
   --local network, no NAT --> 
2. Kubernetes server, port 443 of HAProxy's load balancer service
   --magic done by kube-proxy, possibly NAT(which shoudn't have been here)-->
3. HAProxy's ingress controller pod

Журналы доступа HAProxy показывают IP-адрес источника 10.32.0.1.Это IP с сетевого уровня kubernete.Кубернетес под CIDR является 10.32.0.0/12.Однако мне нужен журнал доступа, чтобы показать фактический IP-адрес источника соединения.

Я попытался вручную отредактировать службу loadbalancer, созданную HAProxy, и установить externalTrafficPolicy: Local.Это не помогло.

Как я могу получить исходный IP-адрес клиента в этой конфигурации?

1 Ответ

0 голосов
/ 21 мая 2019

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

Во-первых, я не упомянул, какой у меня сетевой провайдер. Я использую weave-net, и получается, что, хотя в документации kubernetes говорится, что для сохранения исходного IP-адреса достаточно добавить externalTrafficPolicy: Local в службу балансировки нагрузки, она не будет работать с weave-net, если вы не включите ее специально. Итак, в версии weave-net, которую я использую (2.5.1), вы должны добавить следующую переменную окружения в weave-net DeamonSet NO_MASQ_LOCAL=1. Для получения более подробной информации обратитесь к их документации .

Честно говоря, после этого моя память немного размыта, но я думаю, что на этом этапе вы получаете кластер, в котором:

  • Служба NodePort : не поддерживает сохранение исходного IP-адреса. Каким-то образом это работает на AWS, но не поддерживается на голом металле самим kubernetes, weave-net не виноват.
  • Служба LoadBalancer на узле с IP X, привязанным к IP другого узла Y: не поддерживает сохранение исходного IP, поскольку трафик должен маршрутизироваться внутри сети kubernetes.
  • Служба LoadBalancer на узле с IP-адресом X, связанным с тем же IP-адресом X: Я не помню четко, но я думаю, что это работает.

Во-вторых, дело в том, что kubernetes из коробки не поддерживает настоящие сервисы LoadBalancer. Если вы решите придерживаться «стандартной» установки без каких-либо дополнительных действий, вам придется ограничить работу своих модулей только на узлах кластера, которым назначены LB-IP-адреса. Это делает управление кластером болью в заднице, поскольку вы становитесь очень зависимыми от конкретного расположения компонентов на узлах. Вы также теряете избыточность.

Чтобы решить вторую проблему, вам нужно настроить поставщика реализации балансировщика нагрузки для установки без изменений. Я лично использовал MetalLB . С его настройкой вы предоставляете службе балансировки нагрузки список виртуальных IP-адресов в том смысле, что они не привязаны к конкретному узлу. Каждый раз, когда kubernetes запускает модуль, который принимает трафик от службы LB; он присоединяет один из виртуальных IP-адресов к тому же узлу. Таким образом, IP-адрес LB всегда перемещается вместе с модулем, и вам никогда не придется направлять внешний трафик через сеть kubernetes. В результате вы получаете 100% сохранение исходного IP-адреса.

...