Demystifying Kubernetes Networking — Episode 1

In the episode 1 of demystifying Kubernetes networking, lets start from the foundation— The Linux network namespace

Kubernetes networking is an often misunderstood topic & the main reason contributing to this perception is lack of proper conceptual information which explains it from the grounds up & not just brushing on the surface.

This motivated me to make an attempt to explain this topic right from the fundamentals. Because of the vastness of this topic, I’m breaking it to multiple episodes where in each episode, I’ll make an attempt to explain a specific topic around this theme with an intention that someone finds this useful in one or the other way!

We will start our first episode on a topic which constitute the foundation of the Kubernetes networking — The Linux network namespace

Video edition of this article —

https://sanjimoh.medium.com/s1e01-kubernetes-networking-series-9d10840935f3

Linux namespace

It is one of the main Linux kernel technologies that got introduced around 2002 time frame. It was heavily influenced by Plan 9 from Bell labs & its value proposition was service isolation. In other words, on a Linux server where you are running many different services, isolating each service and its associated processes from other services brings huge benefits such as — smaller blast radius for changes, smaller footprint for security related concerns & many more..

The Linux kernel provides 6 types of namespaces:

1. Process ID namespace (aka pid) — A process inside a pid namespace only sees processes in the same namespace. The first process created in a new namespace has PID 1 and child processes are assigned subsequent PIDs.
2. Mount namespace (aka mnt) — With mnt namespace, it’s possible to attach a process to its own filesystem. It has an independent list of mount points seen by the processes in the namespace. This means that you can mount and unmount filesystems in a mount namespace without affecting the host filesystem.
3. Unix time sharing namespace (aka uts) — It allows a single system to appear to have host & domain names to different processes.
4. Inter process communication namespace (aka ipc) —IPC refers to the mechanisms an operating system provides to allow the processes to manage shared data. Typically, applications can use IPC, categorised as clients and servers, where the client requests data and the server responds to client requests. IPC namespace prevents processes in different IPC namespaces from establishing a range of shared memory between the two processes.
5. User namespace (aka user) — It has its own set of user IDs & group IDs for assignment to processes. In particular, this means that a process can have root privilege within its user namespace without having it in other user namespaces.
6. Network namespace (aka net) — This is the point of interest of this episode and we dig dive on it.

Linux Network namespace

The Network namespace provides a brand-new network stack for all the processes within the namespace. That includes — Network interfaces, Routing tables & iptables rules.

A sample network namespace

You can think of network namespaces as taking the physical network interface and slicing it into smaller independent parts. Each of this part can be configured separately and with its own networking rules & resources. Those can range from firewall rules, interfaces (virtual or physical), routes, and everything else networking-related.

One more analogy of understanding a network namespace is — think of a large apartment building. In this apartment there is a large network pipe from an ISP of that area & then each independent flats in the apartment have their own WiFi unit with their tiny network. So, the large network pipe is the root network namespace & each independent WiFi network in the flats are container network namespace.

In Linux, one can create and list such network namespaces. Below, we created a network namespace “netns2” using “ip netns” command and latter used the “ip netns show” command to view the available network namespace in the linux machine that listed two network namespaces netns1 & netns2.

Commands for creating & listing Linux namespace

Relevance to Kubernetes

With the introduction to Linux network namespace, lets now try to understand it’s relevance in context of Kubernetes.

When one create a pod in Kubernetes -

• First, the pod gets assigned to a node
• Next, just before the pod is deployed & container created, the Container runtime creates the network namespace. Instead of running ip netns & creating the network namespace manually, the container’s runtime does this automatically.
• Next, the CNI will assign an IP address to the pod & will attach the container(s) in the pod to rest of the network. If the pod contains multiple containers, both containers are put in the same namespace & assigned the pod ip. This exactly is the reason why containers inside a pod are able to communicate with each through loopback addresses.

In summary, its the Linux network namespace that gives Kubernetes pods (containers) the needed network isolations & at the same time enables the containers inside a pod to be able to talk with each other!

In the next episode of demystifying Kubernetes Networking series, we’ll learn about a critical container which is often hidden out of our sight but plays a very critical role in binding the Linux network namespace which we’ve discussed in this episode.

[Update] Link to Episode 2 — https://sanjimoh.medium.com/kubernetes-secret-recipe-8d03892b27ae