Moving from physical to virtual networks using software-defined networks (SDNs) and virtual interfaces involves a slight learning curve. The principles remain the same despite the differences in specifications and best practices. Understanding how Kubernetes networking works is helpful when dealing with containers and the cloud.

There are a few general rules to keep in mind when using the Kubernetes Network Model:

• Every pod’s IP address is unique, so There should be no need to create links between pods or map container ports to host ports.
• It is not necessary to use NAT: Pods on a node should be able to communicate with Pods on all nodes without using NAT.
• Agents (system daemons, Kubelets) can contact Pods in a node.
• Containers within a pod share an IP address and MAC address, allowing them to communicate using the loopback address.

In Kubernetes, networking ensures communication between different entity types. Separation is built into the infrastructure by design. A highly structured communication plan is necessary to keep namespaces, containers, and pods distinct.

Understanding Container Networking Models

There are various container networking models, each offering distinct advantages and use cases. Let’s explore two popular models:

1. Bridge Networking: The bridge networking model creates a virtual network bridge that connects containers running on the same host. Containers within the same bridge network can communicate directly with each other, whereas containers in different bridge networks require additional configuration for communication.

2. Overlay Networking: The overlay networking model allows containers running on different hosts to communicate seamlessly. It achieves this by encapsulating network packets within existing network protocols, effectively creating a virtual network overlay across multiple hosts.

Kubernetes Networking

Kubernetes users generally do not create pods directly. Instead, they make a high-level workload, such as a deployment, which organizes pods according to some intended specifications. In the case of deployment, users specify a template for pods and how many pods (often called replicas) they want to exist.

Several additional ways to manage workloads exist, such as ReplicaSets and StatefulSets. Remember that pods are temporary, so they are suggested to be deleted and replaced with new versions.

How Kubernetes Network Namespace Works:

Kubernetes Network Namespace leverages the underlying Linux kernel’s network namespace feature to create separate network environments for each pod. When a pod is created, Kubernetes assigns a unique network namespace, isolating the pod’s network stack from other pods in the cluster.

Each pod has network interfaces, IP addresses, routing tables, and firewall rules within a network namespace. This isolation allows each pod to operate as if it were running on its virtual network, even though it shares the same underlying physical network infrastructure.

Administrators can define network policies at the namespace level, controlling traffic flow between pods within the same namespace and across different namespaces. These policies enable fine-grained control over network traffic, enhancing security and allowing for the implementation of complex networking scenarios.

Docker Default Networking 101 & Linux Namespaces

Six namespaces are implemented in the Linux kernel, enabling the core of container-based virtualization. The following diagram displays per-process isolation: IPC, MNT, NET, PID, USER, and UTS. The number on the right in the square brackets is each namespace’s unique proc inode number.

A structure called nsproxy was added to implement namespaces in the Linux kernel. As the name suggests, it’s a namespace proxy. We have several userspace packages to support namespaces: util-linux, iproute2, ethtool, and wireless iw. This hands-on series will focus on the iproute2 userspace, which allows network namespace (NET) management with the IP NETNS and IP LINK commands.

Docker networking, essentially a namespacing tool, can isolate processes into small containers. Containers differ from VMs that emulate a hardware layer on the operating system. Instead, they use operating system features like namespaces to provide similar isolation without emulating the hardware layer.

Each namespace has an individual and isolated view, allowing sharing of the same host but with separate routing tables and interfaces.

Users may create namespaces, assign ports, and connect for external connectivity. A virtual interface type known as a virtual Ethernet (veth) interface is set to namespaces. They act as pairs and resemble an isolated tube—what comes in one end must go back out the other.

The pairing enables namespace connectivity. Users may also connect namespaces using Open vSwitch. The following screenshot displays the creation of a namespace called NAMESPACE, a veth pair, and adding a veth interface to the newly created namespace. As discussed, the IP NET and IP LINK commands enable interaction with the network namespace. 

The following screenshot displays IP-specific parameters for the previously created namespace. The routing table will only show specific namespace parameters, not information from other namespaces. For example, the following ip route list command does not display the 192.168.1.1/24 interface assigned to the NAMESPACE-A.

This is because the ip route list command looks into the global namespace, not the routing table assigned to the new namespace. Instead, the command will show different route table entries, including different default gateways for each namespace. 

Kubernetes Network Namespace & Docker Networking

Installing Docker creates three networks that can be viewed by issuing the docker network ls command: bridge, host, and null. Running containers with a specific –net flag highlights the network in which you want to run the container. The “none” flag puts the container in no network, so it’s completely isolated. The “host” flag puts the container in the host’s network.

Leaving the defaults places the container into the bridge default network. The default docker bridge is what you will probably use most of the time. Any containers connected to the default bridge, like a flat VLAN, can communicate freely. The following displays the networks created and any containers attached. Currently, no containers are attached.

The image below displays the initiation of the default Ubuntu image pulled from the Docker public registry. There are plenty of images up there that are free to pull down. As you can see, Docker automatically creates a subnet and a gateway. The docker run command starts the container in the default network.

With this setup, it will stop running if you don’t use crtl+p + ctrl +q to exit the container. Running containers are viewed with the docker ps command, and users can connect to a container with the Docker attach command. \

IPTables

IPtables operate by examining network packets as they traverse through the network stack. Each packet is analyzed against a series of rules defined by the administrator. These rules can be based on parameters such as source/destination IP addresses, protocols, port numbers, etc. When a packet matches a rule, the specified action, such as accepting or dropping the packet, is carried out.

Communication between containers can be restricted with IPTables. The Linux kernel uses different IPtables according to the protocol in use:

•  IPtables for IPv4 – net/ipv4/netfliter/ip_tables.c
•  IP6table for IPv6 -net/ipv6/netfliter/ip6_tables.c
•  arptables for ARP -net/ipv4/netfliter/arp_tables.c
•  ebtables for Ethernet – net/bridge/netfilter/ebtables.c

Docker Security Options

They are essentially a Linux firewall before the Netfilter, providing a management layer for adding and deleting Netfilter rules and displaying statistics. The Netfilter performs various operations on packets traversing the network stack. Check the FORWARD chain; it has a default policy of ACCEPT or DROP.

All packets reach this hook point after a lookup in the routing system. The following screenshot shows the permit for all sources of the container. If you want to narrow this down, restrict only source IP 8.8.8.8 access to the containers with the following command – iptables -I DOCKER -i ext_if! -s 8.8.8.8 -j DROP

In addition to the default networks created during Docker installation, users may create user-defined networks. User-defined networks come in two forms – Bridge and Overlay networks. Bridge networks support single-host connectivity, and containers connected to an overlay network may reside on multiple hosts.

The user-defined bridge network is similar to the docker0 bridge. An overlay network allows containers to span multiple hosts, enabling a multi-host connectivity model. However, it has some prerequisites, such as a valid data store.