Chapter 24 of 47 · Networking, part 1

Networking basics you need first

Most Kubernetes networking confusion is really about a few plain networking ideas. This chapter explains them with everyday comparisons and no Kubernetes at all. The next chapter shows where each one appears inside a cluster.

1 · IP address: the building's street address

Every machine (or container, or Pod) on a network has an IP address, four numbers from 0 to 255: 10.244.1.15. It says which machine to deliver to.

2 · Port: the flat number in the building

One machine runs many programs. The port (0–65535) says which program gets the message. Address + port together: 10.244.1.15:4000.

Only one program per port per address. A second one gets EADDRINUSE (you saw this in chapter 6).

3 · localhost and 0.0.0.0: who may knock

When a server starts, it chooses which of its addresses to listen on. This one setting causes a huge number of "works on my machine, not in the container" bugs. Switch between the two:

// Express defaults to all addresses, so this is fine:
app.listen(4000);
// This breaks in Kubernetes:
app.listen(4000, '127.0.0.1');

4 · IP ranges (CIDR): a whole street at once

Networks are described as ranges, written like 10.244.0.0/16. The number after the slash says how much of the address is fixed. The rest can vary. Bigger number after the slash = smaller range.

Check some addresses yourself:

Why you care: a cluster gives Pods one range, Services another, and each node a slice of the Pod range. Seeing 10.244.2.7 you can tell at a glance "that is a Pod on node 2".

5 · DNS: the phone book

People remember names, networks need numbers. DNS turns a name into an IP address, before any connection is made.

• Which DNS server to ask is written in /etc/resolv.conf.
• "Could not resolve host" / ENOTFOUND = the phone book has no such name. The network itself may be fine.
• Try it: nslookup api.github.com

6 · Routing and the gateway: the post office

If the destination is on my own network (inside my range), I deliver it directly. If not, I hand it to the gateway (a router), which knows where to forward it next. A routing table is the list of "for this range, go via there" rules.

$ ip route
default via 192.168.1.1 dev eth0          # everything else → the gateway
192.168.1.0/24 dev eth0                   # my own network → deliver directly
10.244.2.0/24 via 192.168.1.12            # Pods of node 2 → send to node 2

That last line is exactly how many clusters reach Pods on other nodes.

7 · NAT: one front desk for many rooms

Network Address Translation rewrites addresses on the way through. Two everyday forms:

8 · Load balancer and reverse proxy: the receptionist

• Load balancer: one address in front of several copies; spreads the requests. Can work on raw connections (layer 4: IP + port).
• Reverse proxy: reads the HTTP request (layer 7) and chooses by host name or path: /posts → posts, /comments → comments. Nginx is the classic one. Often it load-balances too.

In Kubernetes: a Service is a layer-4 load balancer; an Ingress is a layer-7 reverse proxy.

9 · Refused, timeout, not found: three different problems

The error message tells you where it broke. Learn these three and debugging gets much faster:

10 · Network namespaces: a private network kit per container

Linux can give a process its own network namespace: its own IP, its own ports, its own localhost, its own routing table (Docker chapter 7). A veth pair is a virtual cable connecting that namespace to the host; a bridge is a virtual switch joining many cables (Docker chapter 10).

A Pod is exactly one network namespace. Keep this picture; the next chapter builds on it.

Recap