A swarm manager nodes handles cluster management tasks such as:

1) Maintaining cluster state

2) Scheduling services

3) Serving swarm mode HTTP API endpoints

You may execute any of the - docker swarm - docker node - docker service commands from any of the manager nodes

enter image description here

Applications are running on worker nodes, but they are not fault-tolerant. because worker node is not faul-tolerant.

This means, if a worker node goes down, then manager will launch another worker node.

Swarm cluster design is forcing the developer to design stateless applications running in worker node.

Fault-tolerance is maintained at manager level to know the state of a cluster.

Why fault-tolerance in manager node but not in worker node?


2 Answers 2


A single manager node is not fault tolerant. After all, it's just a single machine (virtual or physical). This is why you have multiple managers, which share the state. If one manager goes down the remaining ones will keep the cluster running.

Similarly, a single worker node is not fault tolerant. After all, it's just a single machine. So what happens if there's a hard disk failure? This means that any state on that machine will be lost. This is why you typically run multiple instances of your app across the swarm and either use a replicated state store (which is, effectively, what the manager nodes do) or maintain state outside of the swarm.

You might also want to look at "12 factor" application design, which takes these concepts even further.

  • Are you saying that state of an application(running in worker node) should be maintained in distributed state store maintained by managers? this looks weird..... Sep 9, 2019 at 18:22
  • No. The managers handle their own distributed state. Your application needs to manage its own distributed state or maintain state outside of the swarm. Sep 10, 2019 at 18:43
  • Then migrating from VM based applications to docker based application takes application re-design, just because of the change of platform Sep 10, 2019 at 18:44
  • VMs typically get data persistence using an external store (eg SAN or NAS) backing the server so if one node of your cluster fails the data is still available. The data is persisted outside of the cluster, you just don't see it at the VM level. You could use a NAS mounted onto every node of the docker cluster (at the same mount point) to get similar persistence and have that volume appear inside the container. Sep 10, 2019 at 19:11

Historically, they tried... There are web servers that run as clusters and you can run stateful applications on them. But from personal experience, these servers are very difficult to configure to work properly, and since the clustering is no transparent but at best translucent, the application code still has to be somewhat cluster-aware, so making applications that run correctly on these systems requires skilled programmers. There are also some restrictions (proximity of servers in the cluster, etc...).

The "Docker way" is more explicit but also simpler to explain to a programmer, and has fewer restrictions (programming language, physical location of all nodes, etc...)

  • Does kubernetes provide fault tolerance to state ful applications? in the name of PODs running on a node. Sep 9, 2019 at 18:20
  • Not AFAIK, and quite unlikely. Even though you can set up some client/pod affinity, there is no guarantee that it will always apply, so it is at best a performance helper. OTOH nothing prevents you from storing a session in the DB, which then becomes responsible for the fault-tolerance of the application (and also becomes a bit fat SPOF...).
    – xenoid
    Sep 9, 2019 at 22:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .