Last Updated on February 17, 2024 by KnownSense
Networking is vast, and it’s complex and generally horrific. But the actual day‑to‑day stuff with container networking is actually super cool. It’s slick and simple. We’ll dive straight in with the different types of networks Docker supports and then we’ll do network services.
Network Types
Containers need to talk to each other. Sometimes they even need to talk to VMs and physicals and even the internet and as part of that deal, those VMs and physicals on the internet, they need to talk back to the containers as well. To help with all of that, We’ve got a bunch of options. We will discuss all the options one by one
Bridge networking
Sometimes we call this single host networking. It’s the oldest and it’s the default. When Docker runs on a host, it typically operates with a default built-in network known as bridge, or NAT in the case of Windows. When people refer to ‘docker0,’ they’re usually discussing this default bridge network. However, apart from the default bridge, you also have the option to create your own networks. However, each one’s an island. So, we plum containers into it, and each container gets its own IP on that bridge network. While containers within the same network can communicate, bridging across separate networks or hosts poses challenges due to this isolation. So, these are isolated layer 2 networks, even if they’re on the same host. The only way to get in or out is to map ports. Straight IP address to IP address communication at layer 2 or even over layer 3 is negative and the same for connecting in or out to the outside world. Communication demands port mappings. This method functions but isn’t optimal, relying heavily on port mappings for internal and external connectivity, which can be cumbersome and less efficient.
Overlay networks
These are also called multihosts networks, and they’re commodity these days. So instead of isolated bridges scoped to a single host, an overlay is a single layer 2 network spanning multiple hosts, and it doesn’t even care if the hosts are all on different underlying networks. The best part is despite the fact that they’re an absolute networking tech fest under the hood, from a user perspective, they are so easy to build. A single simple command to create one and then you just attach containers. docker network create -d overlay
In the above scenario, All three containers can communicate with each other seamlessly. Also, encryption comes effortlessly. The control plane is encrypted by default. Additionally, enabling encryption for in-flight traffic is as simple as using a command line flag.docker network create -d overlay -o encrypted
However, overlays come with a limitation—they facilitate communication solely between containers. If your containers require interaction with VMs or physical systems on existing VLANs, an alternative solution becomes necessary.
MACVLAN
Sometimes termed as ‘transparent’ on Windows, assigns each container a distinct MAC and IP within the external VLAN. This setup grants containers full visibility and integration into these networks without relying on bridges or port mappings. Essentially, each container operates directly on the network. However, there’s a significant catch—it necessitates the host NIC to operate in promiscuous mode. This poses a challenge, especially in cloud environments, as most cloud providers strictly prohibit enabling this mode.
Network Services
2 built‑in network services are service discovery and load balancing. Service discovery is all about being able to locate services on a swarm, and then load balancing lets us access these services from any node in the swarm, even nodes that are not hosting the services. And you know what? It does a bunch of load balancing across the replicas as well. Let’s discuss service discovery first.
Service Discovery
Here’s the basic idea: Each new service within this setup receives a designated name. This name is then logged into the built-in DNS of the swarm. Consequently, every Docker container in the swarm gains access to a DNS resolver that forwards queries to this Swarm-based DNS service. Simply put, containers within the same network of a swarm can communicate or ping each other using their names. Docker primarily operates with containers, but in a swarm, these containers are encapsulated within a construct known as a service, offering more advanced functionalities. For instance, managing a microservices app’s scalability and updates becomes simpler by wrapping individual containers into these services. By naming and registering services with the Swarm DNS, containers within the same network can easily connect. However, it’s important to note that this connectivity is limited to the network scope; services on different overlays can’t discover each other through this method.
Load balancing
Load balancing within Swarm involves a couple of key elements. To start, there’s ingress load balancing, enabling external clients to reach a Swarm service through any node within the swarm, even if that node isn’t actively hosting a service replica. For instance, in a swarm comprising 10 nodes with a service having two replicas, external clients can access the service via any of the 10 nodes. Another aspect of load balancing entails distributing requests among various replicas within a service.
Conclusion
Docker simplifies container networking with various built-in drivers. The bridge driver suits basic cases but needs port mapping for external access. Overlay enables seamless communication across Swarm nodes, but it’s limited to containers. MACVLAN allows integration with external networks but faces restrictions, especially in public clouds. Docker’s services aid in service discovery and external access via load balancing.