Невозможно общаться между модулями, работающими на разных узлах в Kubernetes

Question

Я создавал приложение для распределенного нагрузочного тестирования с использованием Kubernetes и Locust ( аналогично этому ).

В настоящее время у меня есть многоузловой кластер, работающий на голом железе (работающий на сервере Ubuntu 18.04, настроенный с использованием Kubeadm и с Flannel в качестве моего сетевого модуля расширения pod).

Архитектура моего кластера выглядит следующим образом:

• У меня есть «главный экземпляр» приложения Locust, запущенный на моем главном узле.
• У меня есть «ведомые экземпляры» приложения Locust, работающие на всех моих других узлах. Эти ведомые экземпляры должны иметь возможность привязки к порту (по умолчанию 5558) главного экземпляра.

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

Является ли это проблемой с моими текущими сетевыми или развертываниями настроек (я следовал за связанными руководствами в значительной степени дословно)? С чего мне начать отладку этой проблемы?

Answer 1

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

С точки зрения сети, есть требования, упомянутые в документации Kubernetes :

• все контейнеры могут связываться со всеми другими контейнерами без NAT
• все узлы могут связываться со всеми контейнерами (и наоборот) без NAT
• IP-адрес, который контейнер видит сам как тот же IP-адрес, который другие видят как

С точки зрения брандмауэра, вы должны убедиться, что трафик кластера может проходить через брандмауэр на узлах.

Вот список портов, которые вы должны были открыть на узлах , предоставленных веб-сайтом CoreOS:

Master node inbound: TCP: 443  from Worker Nodes, API Requests, and End-Users
                     UDP: 8285,8472 from Master & Worker Nodes


Worker node inbound: TCP: 10250 from Master Nodes
                     TCP: 10255 from Heapster
                     TCP: 30000-32767 from External Application Consumers
                     TCP: 1-32767 from Master & Worker Nodes
                     TCP: 179 from Worker Nodes
                     UDP: 8472 from Master & Worker Nodes
                     UPD: 179 from Worker Nodes

Etcd node inbound:  TCP: 2379-2380 from Master & Worker Nodes

Answer 2

см. IP-переадресация включена на всех узлах.

# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

если не включите его вот так и протестируйте.

echo 1 > /proc/sys/net/ipv4/ip_forward

Answer 3

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