Demystifying Networking : Tracing The Packets Journey

This article aims to illustrate a simplified path of packets across a network. We will trace the path of packets resulting from two ping commands — one directed at localhost and the other at google.com. Additionally, we’ll delve into the pathway a packet follows within a Kubernetes cluster.

$ ping localhost

When the above ping command is executed, it initiates the running of the C program named “ping.c”. Located under folder /usr/bin/ when in a Linux context. This program directs a packet to the loopback interface, achieving this by utilizing kernel APIs like socket() and sendto(). These APIs help in creating a socket and transmitting a packet through it.

The loopback interface is a special network interface in a computer system that allows processes within the same device to communicate with each other without involving external networks or physical network hardware.

A socket acts as an endpoint for communication between processes within the same machine.

The loopback interface promptly responds via the newly created socket. Our ping program runs a while(1) infinite loop to actively monitor for a reply. When received, it displays the ping information.

$ ping google.com

A note: For simplicity’s sake, let us assume that the ip address of google.com is locally cached and known in advance.

As before, the program “ping.c” is executed, initiating a socket connection. But this time the kernel encounters a challenge: it doesn’t know where google.com is.

To better describe the problem: the IP address of google.com is not listed in the internal routing table of our PC. So the kernel does not have a direct destination to send the packet.

The command “ip route show” in Linux systems shows all possible routes through which network packets are directed.

A local PC is aware only of devices within its local network, not external servers like those of Google. So the kernel must route the packet to a fallback address — the local internet router. After which our packet enters the network of our Internet Service Provider (ISP).

This cycle repeats from one router to the next until the packet reaches Google’s servers.

Let us now consider a possible trajectory of a packet traversing a Kubernetes cluster.

Similarly to the previous scenarios, the packet, following its network path, arrives at a Kubernetes cluster’s load balancer. Acting as a Kubernetes Service, the load balancer forwards the packet to a Kubernetes Node.

A load balancer is a software components on the cloud infrastructure, designed to efficiently distribute incoming network traffic across multiple servers,

In Kubernetes, a Service is an abstraction that defines a logical set of Pods and a policy by which to access them.

A Node represents a single worker machine in the Kubernetes cluster.

Upon arrival at the Node, the packet’s target IP address is rewritten. This alteration is necessary because the packet’s destination, a pod, frequently changes its IP address. The previously mentioned service ensures a consistent IP, irrespective of pod replacements.

This rewriting is accomplished by kernel firewall rules on the node. Which have been preconfigured by kube-proxy.

A Pod is a deployable unit with an often dynamically changing IP address.

kube-proxy runs on each node and managing network connectivity to Kubernetes Services.

Our packet is now at the root network namespace of the Node. It needs to reach the network namespace of the target pod. It does so using veth pairs, established by the Container Network Interface (CNI).

A network namespace is a feature in Linux that provides isolation and separation of network resources,

A “veth pair” refers to a pair of virtual Ethernet interfaces that are interconnected. They act as a communication bridge, enabling data transmission between different network namespaces .

The Container Network Interface (CNI) is a standard interface used in Kubernetes to manage networking for containerized applications.

Ultimately, the packet reaches the Pod’s namespace. A virtual interface then routes it to the designated container intended to receive the packet. This elaborate journey demonstrates the complexities involved in navigating a Kubernetes environment to reach its intended destination.