2017-02-09 26 views
1

Я успешно создал марафонные приложения для хоста и моста без проблем и использовал l4lb и marathon-lb для их размещения. Все это работает без проблем.Виртуальная сеть DC/OS не работает со всеми агентами

Теперь я пытаюсь использовать сеть в режиме USER, используя стандартную сеть «dcos» 9.0.0.0/8. В этом режиме мои приложения могут разговаривать только с другими контейнерами на одном и том же агенте. ОС хоста может разговаривать только с контейнерами, размещенными на себе. Похоже, что узлы не могут маршрутизировать трафик между собой в виртуальной сети.

Для тестирования я использую контейнер-докер «nginx: alpine» с двумя экземплярами на разных хостах. Их IP-адреса - 9.0.6.130 и 9.0.3.130. Нет конфигурации L4LB или Marathon-LB, нет конечных точек обслуживания, нет портов, открытых в сети хоста. В основном:

"container": { 
    "docker": { 
     "image": "nginx:alpine", 
     "forcePullImage": false, 
     "privileged": false, 
     "network": "USER" 
    } 
    }, 
    "labels": null, 
    "ipAddress": { 
    "networkName": "dcos" 
    }, 
} 

в оболочке в одном из них, у меня есть:

/ # ip addr list | grep 'inet 9' 
inet 9.0.6.130/25 scope global eth0 

/# nc -vz 9.0.6.130:80 
9.0.6.130:80 (9.0.6.130:80) open 

/# nc -vz 9.0.3.130:80 
nc: 9.0.3.130:80 (9.0.3.130:80): Operation timed out 

/# traceroute to 9.0.3.130 (9.0.3.130), 30 hops max, 46 byte packets 
traceroute to 9.0.3.130 (9.0.3.130), 30 hops max, 46 byte packets 
1 9.0.6.129 (9.0.6.129) 0.006 ms 0.002 ms 0.001 ms 
2 44.128.0.4 (44.128.0.4) 0.287 ms 0.272 ms 0.100 ms 
3 * * * 
4 * * * 

С другой стороны:

/ # ip addr list | grep 'inet 9' 
inet 9.0.3.130/25 scope global eth0 
/# nc -vz 9.0.3.130:80 
9.0.3.130:80 (9.0.3.130:80) open 
/# nc -vz 9.0.6.130:80 
/# traceroute 9.0.6.130 
traceroute to 9.0.6.130 (9.0.6.130), 30 hops max, 46 byte packets 
1 9.0.3.129 (9.0.3.129) 0.005 ms 0.003 ms 0.001 ms 
2 44.128.0.7 (44.128.0.7) 0.299 ms 0.241 ms 0.098 ms 
3 * * * 
4 * * * 

Интересно, что я могу свистеть, что я думаю, что должно быть следующий (виртуальный) прыжок и все промежуточные прыжки, несмотря на то, что traceroute не показывает его. Единственное, что не выполняет ping, это виртуальный IP-адрес конечного контейнера. (Они взяты из одного из контейнеров)

64 bytes from 44.128.0.7: seq=0 ttl=63 time=0.269 ms 
64 bytes from 44.128.0.4: seq=0 ttl=64 time=0.094 ms 
64 bytes from 9.0.3.129: seq=0 ttl=64 time=0.072 ms 
64 bytes from 9.0.6.129: seq=0 ttl=63 time=0.399 ms 
PING 9.0.6.130 (9.0.6.130): 56 data bytes (no response) 

Любые идеи?

ответ

0

Выяснено это с помощью списка рассылки сообщества DC/OS.

RHEL7 устанавливает firewalld по умолчанию, который DC/OS должен быть отключен. Я сделал это, но это все еще оставляет политику FORWARD как DROP до тех пор, пока узел не перезагрузится. Работа с брандмауэром DC/OS изменяет правила, а не политику по умолчанию.

Это фиксирует это:

iptables -P FORWARD ACCEPT 

Это по умолчанию при перезагрузке в любом случае, если не указано где-то (как firewalld), поэтому она должна сохраняться после перезагрузки без каких-либо дальнейших действий.

 Смежные вопросы

  • Нет связанных вопросов^_^