Не удается подключиться к сети по умолчанию из контейнеров докеров

Я пытаюсь развернуть приложение на вычислении Google, но столкнулся с сетевой проблемой, приложение состоит из внешнего интерфейса (работающего внутри контейнеров докеров, развернутых с использованием контроллера репликации) и внутреннего интерфейса узлов Aerospike.

Узлы aerospike не являются частью кластера контейнеров, но они находятся в одном проекте, и кластер контейнеров, и узлы aerospike работают в сети по умолчанию.

Узлы Aerospike, работающие с конфигурациями по умолчанию

изнутри контейнеров докеров я пытаюсь это сделать

var client = aerospike.connect(internal-ip-of-aerospike-node, 3000)

но соединение не проходит, что я делаю не так?


google-compute-engine aerospike
person Alloys    schedule 29.12.2014    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Я немного схематично представляю, как докер-контейнеры запускаются в GCE (или как именно вы это делаете), но IIRC создает оверлейную сеть, чтобы к контейнерам можно было обращаться в их собственном адресном пространстве. Обычно это делается путем создания пары виртуальных сетевых интерфейсов между хостом и контейнером. Чтобы выйти из оверлейной сети, используйте такое правило маскировки (из https://docs.docker.com/articles/networking/#binding-container-ports-to-the-host) добавляется в хост-систему:

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  172.17.0.0/16       !172.17.0.0/16

Предполагается, что оверлейная сеть выбрана так, чтобы не конфликтовать с хост-сетью, но если эта оверлейная сеть перекрывается с внутренней сетью GCE, подключения из контейнеров к оверлейной сети не будут работать.

Я не могу ответить на вопрос, почему это не работает, но я могу предложить, что попробовать:

  • Дайте внешний адрес узлу aerospike и попробуйте подключиться к нему. Если это работает, это предполагает, что проблема в сети контейнера.
  • Запустите несвязанную тестовую виртуальную машину и попытайтесь подключиться к узлу aerospike из
  • Существуют ли какие-либо брандмауэры в сети GCE по умолчанию, которые могут помешать? Попробуйте добавить явное правило, разрешающее трафик.

Обычный способ отладки этих проблем — запустить что-то, что создает поток (неудачных) запросов, а затем попытаться увидеть поток пакетов на каждом этапе:

while :; do nc -w1 -n -v -z <aerospike-ip> 3000; sleep 1; done"

Затем tcpdump, чтобы увидеть, есть ли попытки подключения и как выглядят пакеты:

  • ip link show и/или ip addr show (чтобы найти интерфейс)
  • tcpdump -n -v -c 10 -i ‹интерфейс› TCP-порт 3000

И сделать это в:

  • в контейнере (должен быть eth0)
  • на хосте докера, на виртуальном интерфейсе контейнера (veth‹что-то›)
  • на хосте докера, на сетевом интерфейсе хоста (eth0)
  • на хосте aerospike (eth0)

Это поможет определить, где возникает проблема, а дампы пакетов могут также показать, почему возникает проблема.

person siimphh    schedule 07.01.2015
comment
Я думаю, что проблема в kubernetes, пинг с другой виртуальной машины или из контейнера докеров, который я создал сам, работает. - person Alloys; 11.01.2015