Skip to content

Networking you can't see

Every network in this course so far has had physical referents. An interface corresponded to a NIC, an address to a machine, a switch to a box in a rack. You could point at the thing that was routing your packet.

Containers and cloud networks keep all of the same protocols and throw away all of the physical referents. A container's eth0 is a kernel object created three seconds ago and destroyed when the process exits. A cloud "subnet" is a routing policy in a hypervisor. The 10.96.0.1 that a Kubernetes Service answers on belongs to no interface anywhere in the cluster — no machine has it, nothing responds to ARP for it, and traffic still arrives.

None of that changes the protocols. Every packet in a Kubernetes cluster is still an IP packet with a TCP or UDP header, still subject to routing tables, MTU limits, and NAT. What changes is where those tables live and who writes them, and debugging becomes hard the moment you stop being able to say which layer of virtualisation you're looking at.

What this module is for

DevOps work is mostly this. A junior engineer will spend more time on why a container can't reach a database than on subnetting arithmetic, and the interview questions follow: what does -p 8080:80 actually do? Why can one pod reach another but not a Service? What's the difference between a security group and a network ACL? Each of those has a precise, mechanical answer, and each answer is built entirely out of things this course has already covered — NAT, bridges, DNS, routing, stateful filtering.

The order runs from the smallest unit outward:

  1. Docker's bridge network — one host, virtual interfaces, and the NAT rule that -p creates. This is where the mechanics are visible enough to actually watch.
  2. Docker's other network modes — host, none, and overlay, and the container-to-container DNS that only works on some of them.
  3. Kubernetes Services — how a virtual IP with no interface behind it routes traffic to pods that keep being replaced.
  4. Cluster DNS and network policy — how a pod finds a Service by name, and how you stop everything from being able to reach everything.
  5. Cloud VPCs — subnets, route tables, and the two filtering mechanisms cloud providers give you that behave differently in a way that catches almost everyone once.

The one idea underneath all of it

Linux can give a process its own private copy of the entire network stack — its own interfaces, its own routing table, its own firewall rules, its own port numbers. That feature is called a network namespace, and it's the foundation everything in this module is built on.

A container is a process in its own network namespace. Two containers can both bind port 80 without conflict, because those are two different port-80s in two different stacks. A pod is a group of containers sharing one namespace, which is exactly why containers in the same pod reach each other over localhost and containers in different pods can't.

You can see the namespaces directly:

sudo lsns --type net

        NS TYPE NPROCS   PID USER   NETNSID NSFS                           COMMAND
4026531840 net     183     1 root unassigned                               /sbin/init
4026532563 net       1  8842 root         0 /run/docker/netns/1f4c9a2b7e3d nginx: master process

Two namespaces: the host's, with 183 processes, and one belonging to an nginx container. Different numbers on your machine, same structure. The container's namespace is a real, inspectable kernel object — not an abstraction you have to take on faith — and the rest of this module is about what gets wired into it.

What you'll need

A Linux host with Docker installed for the first half, and a single-node Kubernetes cluster — kind, minikube, or k3s — for the second. Nothing here needs a cloud account; the VPC article explains the model and its failure modes without asking you to spend money, though a free-tier account makes the last exercise more concrete.

Assume every command runs as a user in the docker group or with sudo, and note that membership in the docker group is equivalent to root on the host — worth knowing before you add yourself to it on a shared machine.

Sources