Overlay Network w Docker – komunikacja między kontenerami na wielu hostach
Jednym z największych ograniczeń klasycznego Dockera jest to, że standardowa sieć działa głównie w obrębie jednego hosta.
Przykład:
id="4w7m2r"
Serwer A
Container A
|
docker bridge
oraz:
id="b6r7px"
Serwer B
Container B
|
docker bridge
Kontenery na dwóch różnych maszynach nie widzą się bez dodatkowej konfiguracji.
Rozwiązaniem jest Overlay Network – wirtualna sieć, która pozwala połączyć kontenery działające na wielu hostach tak, jakby znajdowały się w jednej lokalnej sieci.
Czym jest Overlay Network?
Overlay Network to logiczna sieć tworzona ponad istniejącą infrastrukturą fizyczną.
Działa podobnie jak tunel:
id="m2gq5d"
Host A Host B
Container A Container B
| |
Docker Network Docker Network
| |
└──────── Overlay Network ───┘
|
Fizyczna sieć IP
Kontenery komunikują się przez prywatną sieć, mimo że znajdują się na różnych serwerach.
Dlaczego powstała Overlay Network?
W środowisku produkcyjnym aplikacje często są rozproszone:
Przykład:
id="1g2a9p"
Serwer 1
Nginx
Serwer 2
API
Serwer 3
Database
Bez overlay:
id="v6w7bk"
Container A
X
Container B
Z overlay:
id="7e3c1z"
Container A
↓
Overlay Network
↓
Container B
Overlay Network a Docker Swarm
Najczęściej Overlay Network kojarzy się z:
Docker Swarm
Swarm posiada wbudowany mechanizm:
- zarządzania klastrem,
- discovery usług,
- szyfrowania komunikacji,
- tworzenia overlay networks.
Przykład:
id="7s0m1p"
docker network create \
--driver overlay \
app-network
Sprawdzenie:
id="9q7l4d"
docker network ls
Wynik:
id="3a9v5q"
NETWORK ID DRIVER
abc123 overlay
Jak działa Overlay Network od środka?
Docker wykorzystuje kilka mechanizmów Linux.
Najważniejsze:
- VXLAN,
- namespaces,
- virtual ethernet pairs,
- bridge networking,
- routing mesh.
Schemat:
id="2m3j9v"
Container namespace
|
veth
|
Docker bridge
|
VXLAN
|
Network
|
Other Docker host
VXLAN – fundament Overlay Network
VXLAN (Virtual Extensible LAN) pozwala tworzyć wirtualne sieci Layer 2 ponad Layer 3.
Normalna sieć:
id="w8f5h2"
Host A
10.0.0.10
Host B
10.0.0.20
VXLAN:
id="h9f1m7"
Virtual Network
192.168.100.x
↓
Physical Network
10.0.0.x
Pakiet kontenera jest enkapsulowany:
id="6bq3v0"
Original packet
↓
VXLAN header
↓
UDP packet
↓
Physical network
Docker Overlay Network – przykład
Tworzymy sieć:
id="w7j4ad"
docker network create \
--driver overlay \
secure-net
Uruchamiamy usługę:
id="p8x2vn"
docker service create \
--network secure-net \
nginx
Teraz usługa może działać na wielu hostach.
Service Discovery
Overlay Network współpracuje z DNS Dockera.
Przykład:
Usługa:
id="t2q9fj"
database
Aplikacja:
id="v5r8nh"
api container
Nie musi znać IP.
Łączy się:
id="z3h9x1"
database:5432
Docker tłumaczy:
database
↓
IP kontenera
Overlay Network w Docker Compose
Compose standardowo działa na jednym hoście.
Przykład:
id="6v4qfz"
networks:
backend:
driver: overlay
Ale pełne overlay wymaga:
- Swarm Mode,
- klastra Docker.
Aktywacja:
id="r6c8j2"
docker swarm init
Szyfrowanie Overlay Network
Docker Swarm umożliwia szyfrowanie ruchu między hostami.
Tworzenie sieci:
id="8k3xqz"
docker network create \
--driver overlay \
--opt encrypted \
secure-net
Schemat:
id="q0y5nd"
Container
↓
Encrypted VXLAN
↓
Host Network
↓
Other Host
Overlay Network i bezpieczeństwo
Sama sieć overlay nie oznacza automatycznie bezpieczeństwa.
Administrator musi kontrolować:
- kto może komunikować się z kim,
- jakie porty są dostępne,
- czy ruch jest szyfrowany.
Segmentacja sieci
Zła architektura:
id="8r5t2x"
Frontend
API
Database
Monitoring
↓
jedna sieć
Jeżeli frontend zostanie przejęty:
atakujący może próbować dostać się wszędzie.

Lepsze:
id="4m8y0z"
Internet
|
Frontend Network
|
API
|
Backend Network
|
Database
Overlay Network i Zero Trust
W nowoczesnym podejściu:
Nie zakładamy:
„Jeżeli coś jest w naszej sieci, jest bezpieczne.”
Każda komunikacja powinna być kontrolowana.
Przykład:
id="1v7m8k"
API
↓
Database
ALLOW 5432
API
↓
SSH
DENY
Overlay Network vs Bridge Network
| Cecha | Bridge | Overlay |
|---|---|---|
| Jeden host | Tak | Tak |
| Wiele hostów | Nie | Tak |
| VXLAN | Nie | Tak |
| Swarm | Nie | Tak |
| Prostota | Wysoka | Wyższa złożoność |
| Produkcja | Małe wdrożenia | Klastry |
Overlay Network vs Kubernetes Network
Kubernetes używa podobnej koncepcji.
Model:
id="r5n1px"
Pod
↓
CNI Plugin
↓
Overlay Network
↓
Node
Popularne rozwiązania:
- Calico,
- Flannel,
- Cilium,
- Weave.
Diagnostyka Overlay Network
Lista sieci:
id="x4n6vp"
docker network ls
Informacje:
id="m8k3ds"
docker network inspect network_name
Sprawdzenie kontenera:
id="q2c7vz"
docker inspect container
Procesy sieciowe:
id="j7r9np"
ip link
Szukamy:
vxlan
Najczęstsze błędy administratorów
1. Otwarta komunikacja między wszystkimi usługami
Problem:
id="8v5z1c"
Container A
↓
Container B
↓
Container C
↓
Container D
Rozwiązanie:
segmentacja sieci.
2. Brak szyfrowania między hostami
Wrażliwe dane:
- tokeny,
- hasła,
- dane użytkowników.
Rozwiązanie:
encrypted overlay
3. Używanie overlay tam, gdzie wystarczy bridge
Overlay dodaje:
- narzut,
- większą złożoność.
Dla jednego serwera:
często wystarczy bridge.
Overlay Network w środowisku produkcyjnym
Przykład architektury:
id="k9f2mw"
Load Balancer
|
Frontend Network
|
Web Tier
|
Backend Overlay
/ | \
API Worker Cache
|
Database Network
Overlay Network i bezpieczeństwo kontenerów
Najlepsze praktyki:
✅ segmentuj sieci
✅ szyfruj ruch między hostami
✅ ogranicz dostęp usług
✅ nie wystawiaj baz danych publicznie
✅ monitoruj komunikację
✅ stosuj firewall hosta
✅ używaj polityk dostępu
Podsumowanie
Overlay Network jest jednym z fundamentów rozproszonych środowisk kontenerowych.
Pozwala:
- łączyć kontenery na wielu hostach,
- tworzyć logiczne sieci niezależne od infrastruktury,
- budować klastry Docker,
- izolować komunikację usług.
W połączeniu z:
- Namespaces – izolacja procesów,
- cgroups v2 – limity zasobów,
- OverlayFS – warstwy systemu plików,
- Seccomp – ograniczenie syscalli,
- AppArmor/SELinux – kontrola dostępu,
- nftables – filtracja ruchu,
tworzy podstawę bezpiecznej architektury kontenerowej.
Dobrze zaprojektowana Overlay Network nie jest tylko sposobem na komunikację. Jest elementem architektury bezpieczeństwa, gdzie każda usługa otrzymuje dostęp wyłącznie do tych zasobów, których faktycznie potrzebuje.






