Докер-сервис застрял в Новом государстве (Рой) - PullRequest
0 голосов
/ 28 июня 2018

Я столкнулся со странной проблемой с моим Docker Swarm (кластер из 3 менеджеров и 5 рабочих). У меня сейчас много запущенных сервисов, и когда я подхожу к 100 сервисам (и с репликациями более 110 сервисов), новые сервисы, которые я хочу запустить, не запускаются.

Когда я перечисляю услугу, у меня есть это:

ID            NAME            IMAGE       NODE  DESIRED STATE  CURRENT STATE     ERROR  PORTS
alam7whfn1xe  service_name.1  some_image        Running        New 22 hours ago

Вы можете увидеть CURRENT STATE == New 22 hours ago. Если я попытаюсь проверить журналы, они пусты. Проверка службы тоже не поможет (ничего не значит).

Если я остановлю некоторые из моих служб, служба, отмеченная состоянием New, может запуститься сама после первой попытки. Кажется, я каким-то образом достиг предела.

Я проследил за некоторыми документами в Интернете, и по этому вопросу ничего не ясно. Будем рады, если вы укажете мне несколько ссылок.

Сегодня, на мой взгляд, я подозреваю, что сети, которые я создал в Swarm (--driver=overlay), имеют недостаточный диапазон IP-адресов и не могут предоставить достаточно IP-адресов контейнерам. Эти сети являются /24 подсетями. Есть ли способ «сбросить» IP-резервирование для повторной инициализации сетей без воссоздания сетей Docker?

После расследования есть два типа служб, которые могут достичь этого состояния New, и они находятся в 2 одинаковых сетях.

Результат docker network inspect:

[
    {
        "Name": "network_name",
        "Id": "okbrl5twyheq32ht3zw5l00gs",
        "Created": "0001-01-01T00:00:00Z", <- this is the real date, strange isn't it?
        "Scope": "swarm",
        "Driver": "overlay",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.16.2.0/24",
                    "Gateway": "172.16.2.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": true,
         "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": null,
        "Options": {
            "com.docker.network.driver.overlay.vxlanid_list": "4097"
        },
        "Labels": null
    }
]

Кроме того, это результат docker version:

Client:
 Version:      17.06.2-ce
 API version:  1.30
 Go version:   go1.8.3
 Git commit:   cec0b72
 Built:        Tue Sep  5 20:00:06 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.06.2-ce
 API version:  1.30 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   cec0b72
 Built:        Tue Sep  5 19:58:57 2017
 OS/Arch:      linux/amd64
 Experimental: false

N.B.: Я не хочу обновлять Docker в данный момент.

РЕДАКТИРОВАТЬ 1:

Я снова прочитал документацию Docker о сетях , и они упоминают об открытой проблеме Moby's Github Project Swarm Mode в Scale # 30820 .

Наложение сетевых ограничений

Вам следует создавать оверлейные сети с блоками / 24 (по умолчанию), что ограничивает вас 256 IP-адресами, когда вы создаете сети с использованием режима конечной точки на основе VIP по умолчанию. В этой рекомендации рассматриваются ограничения в режиме роя . Если вам нужно более 256 IP-адресов, не увеличивайте размер блока IP. Вы можете использовать режим конечной точки dnsrr с внешним балансировщиком нагрузки или использовать несколько меньших оверлейных сетей. См. Настройка обнаружения службы для получения дополнительной информации о различных режимах конечной точки.

- https://docs.docker.com/engine/reference/commandline/network_create/#overlay-network-limitations

РЕДАКТИРОВАТЬ 2:

На основании Flavio 'fcrisciani' Crisciani по вопросу Swarm Mode в масштабе № 30820 , я попытаюсь добавить опцию --endpoint-mode=dnsrr в моих сервисах.

Ответы [ 2 ]

0 голосов
/ 28 сентября 2018

Кажется, что ограничение ресурсов IP-адреса оверлея равнозначно этим задачам. Вы можете создать сеть Docker с большим диапазоном подсетей, например 10.10.0.0/16. Затем используйте его в вашем файле для создания сервиса. Я думаю, что это может решить эту проблему.

0 голосов
/ 04 июля 2018

Опция --endpoint-mode=dnsrr в каждой службе, кажется, решает эту проблему.

...