Docker — Container Network Basics

Container networking basics

Containerization has revolutionized software deployment. While the idea of isolating applications in their environment isn’t new, the way containers achieve this is particularly efficient. One of the essential aspects of containerization is networking. In a K8s cluster, understanding the basics of container networking is crucial for effective orchestration.

Why is Container Networking Important?

Containers, by design, are transient. They can be created, destroyed, and recreated rapidly. This dynamic nature means that their networking must be equally flexible. Unlike traditional VMs, which have a more static network interface and IP, containers can come and go, implying their network configurations can change rapidly.

Isolation and Security

Containers are all about isolation, allowing multiple applications to run on a single OS without interfering with each other. Networking is a crucial part of this isolation. It ensures that:

• Containers can communicate with each other securely and efficiently.
• Traffic to and from containers can be appropriately routed, filtered, and load-balanced.
• Intruders are kept out, and sensitive data is kept in.

Inter-container Communication

In microservices architectures, an application might be split into dozens (or even hundreds) of individual services, each running in its own container. Efficient and reliable container-to-container communication is essential for:

• Maintaining application responsiveness.
• Ensuring data consistency.
• Implementing complex workflows and transaction sequences.

Service Discovery

As mentioned, containers can come and go, and hardcoding IPs is impractical. Thus, an effective networking solution must offer:

• Dynamic service registration and discovery.
• Load balancing to distribute traffic evenly among multiple instances of a service.

Cross-Host Communication

In distributed platforms like K8s, containers can reside on different hosts. Networking plays a crucial role in ensuring:

• Seamless communication across containers, irrespective of where they are running.
• Efficient routing and low latency, especially when container instances span across data centers or cloud regions.

Container Networking Modes

• None: No networking. This disables networking for the container. You use this mode. For example:

$ docker run -it --net=none busybox ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever

• Bridge Network: The default Docker networking mode. Containers get IPs from a private subnet and communicate with external entities through NAT. For example:

$ docker run -it busybox ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
28: eth0@if29: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue
    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
       valid_lft forever preferred_lft forever

• Host Network: Containers share the host’s network stack. They can directly use the host’s IP but might face port conflicts. Processes running inside the container have the same network capabilities as services running directly on the host. For example:

$ docker run -it --net=host busybox ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq qlen 1000
    link/ether 12:4e:e2:6d:77:d5 brd ff:ff:ff:ff:ff:ff
    inet 172.31.84.183/20 brd 172.31.95.255 scope global dynamic eth0
       valid_lft 2754sec preferred_lft 2754sec
    inet6 fe80::104e:e2ff:fe6d:77d5/64 scope link
       valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
    link/ether 02:42:97:77:c5:dc brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:97ff:fe77:c5dc/64 scope link
       valid_lft forever preferred_lft forever

• Macvlan/Ipvlan Network: This lets you assign a MAC/IP address to a container, making it appear as a physical network device on your LAN.

$ docker network create -d macvlan   --subnet=192.168.1.0/24   --gateway=192.168.1.1   -o parent=eth0 my_macvlan_net
2a03ac6926675427015f37186433e8308d0d9f207382b24af8b3569965ecd5ce

$ docker run -it --net=my_macvlan_net busybox ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
36: eth0@if2: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 9001 qdisc noqueue
    link/ether 02:42:c0:a8:01:02 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.2/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever

• Overlay Network: Useful for multi-host networking, especially in a distributed system like K8s. It allows containers across different hosts to communicate as if they’re on the same logical network.

Container Network Interface

The Container Network Interface (CNI) is a specification and a set of tools for configuring container networking. It’s a standard that defines how network plugins should be created and interact with container runtimes (like containerd or runc). The idea is to have a consistent and straightforward interface between container runtimes and network plugins, so different systems and tools can work seamlessly together.

CNI has spawned a variety of open-source projects that offer different networking solutions for containers. These CNI plugins are designed to be used with container runtimes that adhere to the CNI specification, such as K8s, Mesos, and more. Below are some popular open-source CNI projects:

Flannel

• Repository: coreos/flannel
• Description: Flannel is a simple and easy-to-setup overlay network that satisfies the Kubernetes CNI. It can utilize various backend technologies to route container traffic.

Calico

• Repository: projectcalico/cni-plugin
• Description: Calico provides networking and network policy for containers, virtual machines, and native host-based workloads. It uses a pure IP networking fabric to deliver high-performance networking.

Cilium

• Repository: cilium/cilium
• Description: Cilium uses eBPF (extended Berkeley Packet Filter) to provide API-aware network security, load balancing, and routing.

Weave

• Repository: weaveworks/weave
• Description: Weave creates a virtual network that connects containers across multiple hosts and enables their automatic discovery.