Kubernetes Service LoadBalancer EXTERNAL-IP остается ‹none› вместо того, чтобы использовать общедоступные IP-адреса рабочих узлов

У меня есть 5 VPS с публичным сетевым интерфейсом для каждого, для которых я настроил VPN.

  • 3 узла являются мастерами Kubernetes, для которых я установил флаг Kubelet --node-ip в качестве их частного IP-адреса.
  • На одном из трех узлов есть балансировщик нагрузки HAProxy для мастеров Kubernetes, прослушивающий частный IP-адрес, поэтому все узлы использовали частный IP-адрес балансировщика нагрузки для присоединения к кластеру.
  • 2 узла являются рабочими узлами Kubernetes, где я не устанавливал флаг Kubelet --node-ip, чтобы их IP-адрес узла был публичным адресом.

Кластер исправен, и я развернул свое приложение и его зависимости.

Теперь я хочу получить доступ к приложению из Интернета, поэтому я развернул пограничный маршрутизатор и создал службу Kubernetes с типом LoadBalancer.

Служба хорошо создана, но никогда не принимает общедоступные IP-адреса рабочих узлов как EXTERNAL-IP.

Назначение IP-адресов вручную работает, но, очевидно, нужно, чтобы это было автоматически.

Я читал о проекте MetalLb, но, похоже, он не подходит для моего случая, как предполагалось. иметь диапазон IP-адресов для распределения, а здесь у меня есть один общедоступный IP-адрес на узел, а не в том же диапазоне.

Итак, кто может настроить Kubernetes, чтобы моя служба типа LoadBalancer автоматически получала общедоступные IP-адреса как EXTERNAL-IP?


kubernetes kubernetes-networking vpn
person ZedTuX    schedule 12.12.2019    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Я, наконец, могу ответить себе в два раза.

Без внешнего балансировщика нагрузки

Во-первых, чтобы решить проблему из моего вопроса, я нашел единственный способ, который работал достаточно хорошо, — это установить externalIPs моей службы LoadBalancer с IP-адресами рабочих узлов Kubernetes.

На этих узлах работал Traefik, поэтому он прослушивал порты 80 и 443.

После этого я создал столько записей A DNS, сколько у меня есть рабочих узлов Kubernetes, указав каждый из них на общедоступный IP-адрес соответствующего рабочего узла Kubernetes. Эта настройка заставляет DNS-сервер возвращать список IP-адресов в случайном порядке, а затем веб-браузер позаботится о попытке первого IP-адреса, затем второго, если первый не работает, и так далее.

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

Итак, вот второй вариант: внешний балансировщик нагрузки.

С внешним балансировщиком нагрузки

Я взял другой VPS, на котором установил HAproxy и настроил сквозной SSL для порта API Kubernetes, чтобы он балансировал нагрузку на трафик на мастер-ноды, не прерывая его.

С помощью этого решения я удалил поле externalIPs из своего Service и установил MetalLB с одним IP-адресом, настроенным с помощью этого манифеста:

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: staging-public-ips
      protocol: layer2
      addresses:
      - 1.2.3.4/32

Когда создается LoadBalancer Service, MetalLB назначает этот IP-адрес и соответственно вызывает API-интерфейсы Kubernetes.

Это решило проблему с интеграцией моего кластера Kubernetes с Gitlab.

ВНИМАНИЕ: MetalLB назначит только один раз IP-адрес, поэтому, если у вас есть второй LoadBalancer Service, он останется в состоянии Pending навсегда, пока вы не дадите новый IP-адрес МеталлЛБ.

person ZedTuX    schedule 22.04.2021