Задания службы Docker застряли в состоянии подготовки после перезагрузки на Windows - PullRequest
Новая
       68

Задания службы Docker застряли в состоянии подготовки после перезагрузки на Windows

0 голосов
/ 27 сентября 2019

Перезапуск сервера Windows, который является рабочим роя, приводит к застреванию контейнеров Windows в состоянии «Подготовка» на неопределенное время после того, как демон сервера и докера снова подключен.

Образ задач / контейнеров, застрявших в процессе подготовкисостояние:

https://user -images.githubusercontent.com / 4528753 / 65180353-4e5d6e80-da22-11e9-8060-451150865177.png

Действия по воспроизведению проблемы:

  1. Создание роя (в моем случае у меня есть менеджеры CentOS7 и несколько работников Windows Server 1903)
  2. Создание «глобальной» докерской службы, которая работает только на машинах с Windows,Первоначально они должны нормально запускаться и работать нормально.
  3. Удалите один или несколько узлов Windows, на которых выполняется контейнер (ы) Windows, начиная с шага 2 (обновление узла докера --availability = сливное имя узла)
  4. Перезапустите один или несколько узловкоторые были удалены на шаге 3, подождите, пока они не вернутся
  5. Верните узлы Windows обратно в активное состояние (обновление узла докера --availability = имя активного узла)
  6. На этом этапепросто обратите внимание, что служба docker, созданная на шаге 2, будет «подготавливать» контейнеры для запуска на этих узлах, и там она останется (служба docker ps servicename --no-trunc) - вы можете наблюдать это и запускать этиКоманды из любого главного узла 
memberlist: Refuting a suspect message (from: c9347e85405d)
memberlist: Failed to send ping: write udp 10.60.3.40:7946->10.60.3.110:7946: wsasendto: The requested address is not valid in its
          context.
grpc: addrConn.createTransport failed to connect to {10.60.3.110:2377 0  <nil>}. Err :connection error: desc = "transport: Error while
          dialing dial tcp 10.60.3.110:2377: connectex: A socket operation was attempted to an unreachable host.". Reconnecting... [module=grpc]
memberlist: Failed to send ping: write udp 10.60.3.40:7946->10.60.3.186:7946: wsasendto: The requested address is not valid in its
          context.
grpc: addrConn.createTransport failed to connect to {10.60.3.110:2377 0  <nil>}. Err :connection error: desc = "transport: Error while
          dialing dial tcp 10.60.3.110:2377: connectex: A socket operation was attempted to an unreachable host.". Reconnecting... [module=grpc]
agent: session failed [node.id=wuhifvg9li3v5zuq2xu7c6hxa module=node/agent error=rpc error: code = Unavailable desc = all SubConns are
          in TransientFailure, latest connection error: connection error: desc = "transport: Error while dialing dial tcp 10.60.3.69:2377:
          connectex: A socket operation was attempted to an unreachable host." backoff=6.3s]
Failed to send gossip to 10.60.3.110: write udp 10.60.3.40:7946->10.60.3.110:7946: wsasendto: The requested address is not valid in its
          context.
Failed to send gossip to 10.60.3.69: write udp 10.60.3.40:7946->10.60.3.69:7946: wsasendto: The requested address is not valid in its
          context.
Failed to send gossip to 10.60.3.105: write udp 10.60.3.40:7946->10.60.3.105:7946: wsasendto: The requested address is not valid in its
          context.
Failed to send gossip to 10.60.3.69: write udp 10.60.3.40:7946->10.60.3.69:7946: wsasendto: The requested address is not valid in its
          context.
Failed to send gossip to 10.60.3.186: write udp 10.60.3.40:7946->10.60.3.186:7946: wsasendto: The requested address is not valid in its
          context.
Failed to send gossip to 10.60.3.105: write udp 10.60.3.40:7946->10.60.3.105:7946: wsasendto: The requested address is not valid in its
          context.
Failed to send gossip to 10.60.3.186: write udp 10.60.3.40:7946->10.60.3.186:7946: wsasendto: The requested address is not valid in its
          context.
Failed to send gossip to 10.60.3.69: write udp 10.60.3.40:7946->10.60.3.69:7946: wsasendto: The requested address is not valid in its
          context.
Failed to send gossip to 10.60.3.105: write udp 10.60.3.40:7946->10.60.3.105:7946: wsasendto: The requested address is not valid in its
          context.
Failed to send gossip to 10.60.3.109: write udp 10.60.3.40:7946->10.60.3.109:7946: wsasendto: The requested address is not valid in its
          context.
Failed to send gossip to 10.60.3.69: write udp 10.60.3.40:7946->10.60.3.69:7946: wsasendto: The requested address is not valid in its
          context.
Failed to send gossip to 10.60.3.110: write udp 10.60.3.40:7946->10.60.3.110:7946: wsasendto: The requested address is not valid in its
          context.
memberlist: Failed to send gossip to 10.60.3.105:7946: write udp 10.60.3.40:7946->10.60.3.105:7946: wsasendto: The requested address is
          not valid in its context.
memberlist: Failed to send gossip to 10.60.3.186:7946: write udp 10.60.3.40:7946->10.60.3.186:7946: wsasendto: The requested address is
          not valid in its context.

Многие из этих ошибок являются странными, например ... 7946 полностью открыт между узлами кластера, телнеты подтверждают это.

Я ожидаючтобы сервисные контейнеры Docker запускались быстро и не застревали в состоянии Подготовка.Образ докера уже извлечен, он должен быть быстрым.

вывод версии докера 

Client: Docker Engine - Enterprise
 Version:           19.03.2
 API version:       1.40
 Go version:        go1.12.8
 Git commit:        c92ab06ed9
 Built:             09/03/2019 16:38:11
 OS/Arch:           windows/amd64
 Experimental:      false

Server: Docker Engine - Enterprise
 Engine:
  Version:          19.03.2
  API version:      1.40 (minimum version 1.24)
  Go version:       go1.12.8
  Git commit:       c92ab06ed9
  Built:            09/03/2019 16:35:47
  OS/Arch:          windows/amd64
  Experimental:     false

вывод информации о докере 

Client:
 Debug Mode: false
 Plugins:
  cluster: Manage Docker clusters (Docker Inc., v1.1.0-8c33de7)

Server:
 Containers: 4
  Running: 0
  Paused: 0
  Stopped: 4
 Images: 4
 Server Version: 19.03.2
 Storage Driver: windowsfilter
  Windows:
 Logging Driver: json-file
 Plugins:
  Volume: local
  Network: ics l2bridge l2tunnel nat null overlay transparent
  Log: awslogs etwlogs fluentd gcplogs gelf json-file local logentries splunk syslog
 Swarm: active
  NodeID: wuhifvg9li3v5zuq2xu7c6hxa
  Is Manager: false
  Node Address: 10.60.3.40
  Manager Addresses:
   10.60.3.110:2377
   10.60.3.186:2377
   10.60.3.69:2377
 Default Isolation: process
 Kernel Version: 10.0 18362 (18362.1.amd64fre.19h1_release.190318-1202)
 Operating System: Windows Server Datacenter Version 1903 (OS Build 18362.356)
 OSType: windows
 Architecture: x86_64
 CPUs: 4
 Total Memory: 8GiB
 Name: SWARMWORKER1
 ID: V2WJ:OEUM:7TUQ:WPIO:UOK4:IAHA:KWMN:RQFF:CAUO:LUB6:DJIJ:OVBX
 Docker Root Dir: E:\docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false
 Product License: this node is not a swarm manager - check license status on a manager node

Дополнительные сведения

  • Эти узлы не используют Docker Desktop для Windows.Я настраиваю Docker на коробке, в основном на основе инструкций PowerShell: https://docs.docker.com/install/windows/docker-ee/
  • Брандмауэр Windows отключен
  • iptables / firewalld отключен
  • Связь полностью открыта междуузлы кластера
  • Полная информация о накопительных обновлениях

Я публиковал сообщения о проблемах мобильного репо, но никогда не слышал писк: https://github.com/moby/moby/issues/39955

Единственный способ, который я нашел для временного исправления проблемы, состоит в том, чтобы удалить узел из роя, удалить файлы Docker, переустановить функцию «Контейнеры» Windows, а затем снова присоединиться к рою.Но это происходит снова при перезагрузке.

Что интересно, когда я вижу задачу роя в состоянии «Подготовка» на рабочем столе Windows, сервер, кажется, вообще ничего не делает, это похоже наменеджер думает, что работник готовит контейнер, но это не так ...

У кого-нибудь есть предложения ??

...