moby / moby/swarmkit

Docker swarm DNS periodically fails

Open
#2,276 13 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Go
Stars
3.7k
Forks
676
Avg merge
4d 9h
Merged PRs (30d)
6

Description

I'm cross posting this here from a moby issue because I believe that nothing is going to happen with the issue in that project. The original issue is here:

https://github.com/moby/moby/issues/33721

In a 3-master swarm every few days one of the nodes will fail to have the internal swarm DNS resolve services by name. The swarm will operate fine for several days then DNS just stops working. I don't yet know if there is some specific change that we are making that causes the issue - our system does automated deploys and we haven't yet correlated an aspect of those automated deploys to when the issue is triggered.

Steps to reproduce the issue:

  1. Run a 3-master docker swarm in EC2 for several days
  2. Sometimes after 2-4 days one of the nodes can't resolve DNS names for services not running on it locally but running in the swarm.
  3. There is no step 3.

Describe the results you received:
We run nginx inside our swarm as a reverse http proxy to our various services. We know that the DNS isn't working because we have disabled nginx DNS caching and suddenly it will stop resolving the IP of the service where our application is running. When I execute nslookup inside the containers running on the effected node they will fail to find any of the services running on other nodes in the swarm, but they will find services running on the same node.

Describe the results you expected:
For name resolution to continue working.

Additional information you deem important (e.g. issue happens only occasionally):
The issue only happens occasionally. It is resolved if I restart the docker daemon on the node that can no longer resolve DNS

Output of docker version:

Client:
 Version:      17.05.0-ce
 API version:  1.29
 Go version:   go1.7.5
 Git commit:   89658be
 Built:        Thu May  4 22:10:54 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.05.0-ce
 API version:  1.29 (minimum version 1.12)
 Go version:   go1.7.5
 Git commit:   89658be
 Built:        Thu May  4 22:10:54 2017
 OS/Arch:      linux/amd64
 Experimental: false

Output of docker info:

Containers: 19
 Running: 12
 Paused: 0
 Stopped: 7
Images: 24
Server Version: 17.05.0-ce
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 195
 Dirperm1 Supported: true
Logging Driver: json-file
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
Swarm: active
 NodeID: 6mugebxyus7dgoip9i165mj64
 Is Manager: true
 ClusterID: mn6l9qnshdxzzxfoxwpsa18xe
 Managers: 3
 Nodes: 3
 Orchestration:
  Task History Retention Limit: 5
 Raft:
  Snapshot Interval: 10000
  Number of Old Snapshots to Retain: 0
  Heartbeat Tick: 1
  Election Tick: 3
 Dispatcher:
  Heartbeat Period: 5 seconds
 CA Configuration:
  Expiry Duration: 3 months
 Node Address: 10.0.46.77
 Manager Addresses:
  10.0.101.134:2377
  10.0.109.151:2377
  10.0.46.77:2377
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 9048e5e50717ea4497b757314bad98ea3763c145
runc version: 9c2d8d184e5da67c95d601382adf14862e4f2228
init version: 949e6fa
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.4.0-57-generic
Operating System: Ubuntu 16.04.1 LTS
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 3.674GiB
Name: ip-10-0-46-77
ID: XMND:RWXY:RGVB:F4BK:TDA3:LQ3W:URQH:T6ES:HLQE:74A7:FQG4:RIYY
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Username: authentiseautomation
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

WARNING: No swap limit support

Additional environment details (AWS, VirtualBox, physical, etc.):
AWS EC2 instances

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the linked Moby issue and the swarmkit issue history, then reproduce the failure using a three-manager Docker swarm in AWS EC2. Use nslookup inside containers to compare services on local and remote nodes, and review the supplied docker version and docker info output. Done means identifying and fixing the intermittent cross-node service-DNS failure without requiring a daemon restart.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
distributed-systems, networking
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.