✦ For everyone, free.

Practical knowledge for real and everyday life

Home

7.2.4.5 Overlay Cluster Network

A focused guide to Overlay Cluster Network, connecting core concepts with practical Docker and container operations.

An overlay cluster network is an overlay network scoped to and managed within a Docker Swarm cluster, providing the shared networking fabric that connects services and containers across every host that has joined the cluster.

Creating a Cluster-Wide Overlay Network

An overlay network created within an initialized Swarm becomes available across the entire cluster, not just the host where the creation command was run.

docker swarm init
docker network create --driver overlay cluster-net

This network is now usable by any service deployed anywhere in the cluster, regardless of which specific manager or worker node happens to schedule a given replica.

How New Nodes Joining the Cluster Gain Access

A node that joins the Swarm cluster after the overlay network was created automatically gains the ability to participate in that network once a service or container scheduled to it actually runs there.

docker swarm join --token <token> <manager-ip>:2377
docker service create --name api --network cluster-net myapi:1.0

If api happens to be scheduled on this newly joined node, that node automatically participates correctly in cluster-net.

Isolating Different Applications With Separate Cluster Networks

Multiple distinct overlay networks can coexist within the same cluster, each isolating a different application or group of related services from the others.

docker network create --driver overlay app-a-net
docker network create --driver overlay app-b-net

Services on app-a-net cannot communicate with services on app-b-net unless explicitly connected to both.

Why an Overlay Cluster Network Matters

A cluster-wide overlay network is the foundational networking layer that makes a Swarm cluster behave as a single, coherent platform for running distributed services, abstracting away the specific physical or virtual machines underlying the cluster from the perspective of the services running on it.