Каждому контейнеру - по IP

Konstantin Nazarov [@racktear]

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

Спасибо!

Konstantin Nazarov [@racktear]