Embed Size (px)
Citation preview
Docker и сеть
Мой случай: Tarantool облако
Требование1:Маршрутизируемый IP
Требование2:Связь между контейнерами
Зачем нужен внешний IP
• Внешние системы без service discovery
• Маленький downtime при "переезде"
• Можно обойтись без оркестрации
Так в чем проблема?
Так в чем проблема?
Так в чем проблема?
Docker сам настраивает Bridge
Опция 1: port forwarding
Опция 2: load balancer
Все еще не то
• Балансировщик нужно настраивать
• Есть одна точка отказа
• Сложно управлять
Как это работает
Обычная конфигурация
veth$ ip link add veth0 type veth peer name veth1
network namespace$ ip link set veth1 netns ns1
И собственный TCP/IP стек
Port Forwarding
Решение 1: NAT
Добавим еще один IP на хост$ ip addr add <IP2> dev eth0
Форвардим порты контейнера на IP2$ docker run -p <IP2>:80:80
Опционально: SNAT
Pros
• Работает "из коробки"
• Просто в обслуживании
Cons
• Не работает через Docker API
Решение 2: pipework
Решение 2: bridgesВручную или через pipework
Pipework$ docker run -name web1 -d apache
$ pipework mybridge web1 <IP>
Pipework$ docker run -name web1 -d apache
$ pipework mybridge web1 <IP>
Pros
• Гибко
• Просто
• Можно сделать еще много интересного
Cons
• Не делается через Docker API
• Сложно встраивать в init/systemd
Решение 3: macvlan
macvlanвиртуальный интерфейс без "пары"
macvlanможно "отдать" в контейнер
Pros
• Работает очень быстро
• Поддерживается pipework
• Поддерживается в docker-experimental
Cons
• Контейнеры не видны с хоста (без хаков)
• Требует пересборки докера
• (Или недоступно через API)
Решение 4: overlay net(или vxlan)
vxlan
vxlan в докере
+ хостовый интерфейс
Pros
• Хорошая изоляция
• Работает из коробки
• Работает с Docker Swarm
Cons
• Требует внешнего KV хранилища
• Сложно "пустить" трафик снаружи
• Требует отдельного контейнера для роутинга
Решение 5: weave
weave
• Использует vxlan "под капотом"
• Может работать поверх "неудобных" топологий
• Имеет свой service discovery
• ... и load balancing
Pros
• Работает как плагин к libnetwork
• Можно использовать через Docker API
• Можно попасть в overlay с хоста (expose)
Cons
• Много компонентов
• Нужен Docker API Proxy
• Имеет свой собственный gossip/kv хранилище
Решение 6: bridge
libnetwork
Вопросы:
• Как докер создает бридж?
• Как он его конфигурирует?
bridgeAlreadyExists := bridgeIface.exists() if !bridgeAlreadyExists { bridgeSetup.queueStep(setupDevice) }
// Even if a bridge exists try to setup IPv4. bridgeSetup.queueStep(setupBridgeIPv4)
Выводы
• Можно модифицировать бридж "извне"
• Но не IPv4 настройки: их "заменит"
В заключение
• Стандартные бриджи медленнее openvswitch
• Если нужна скорость - macvlan
• В другом случае - лучше бриджи (это просто)
• Overlay - с осторожностью
Чего ждать?
• libnetwork + hashicorp memberlist
• openvswitch портируют на DPDK
