Skip to content

Networking

A Kubernetes cluster is fundamentally a networked system. You need to understand how packets move between your machines before you can understand how pods talk to each other.

Theory

IPv4 addressing. Every device on a network gets an IP address. Your homelab uses a single subnet:

192.168.1.0/24

The /24 means the first 24 bits are the network portion — so all addresses from 192.168.1.0 to 192.168.1.255 are on the same local network. That gives you 254 usable hosts (.1 through .254).

DHCP vs. static IPs. Your router runs a DHCP server that hands out IP addresses dynamically. The problem: if a node's IP changes after a reboot, your cluster breaks. Solutions:

  • DHCP reservation (what you did): the router always assigns the same IP to a specific MAC address. The node still uses DHCP, but gets a predictable result.
  • Static IP on the OS: configure the IP directly in /etc/network/interfaces. More portable (works without the router), but harder to manage at scale.

MAC addresses. A Media Access Control address is burned into every network interface card. It's a layer-2 (Ethernet) identifier. Format: 88:d7:f6:49:0d:46. Your router uses these to pin DHCP reservations.

DNS resolution and /etc/hosts. When a program resolves a hostname (e.g., k8s-cp-01), Linux checks /etc/hosts before querying DNS. By hardcoding node IPs in /etc/hosts, you guarantee name resolution even if the router's DNS is down. This is a resilience pattern.

Virtual IPs (VIP). A VIP is an IP address that isn't tied to a physical NIC — it "floats" between nodes. You reserved 192.168.1.50 for kube-vip, which will allow the Kubernetes API server to be reachable at a stable endpoint, even if the underlying control plane node changes.

Obstacles

  • IP conflicts. If two devices get the same IP, both lose connectivity. Always check your DHCP range doesn't overlap with your static/reserved range.
  • Subnet confusion. All cluster nodes must be on the same subnet (or have proper routing between them). If one node is on 192.168.1.x and another on 192.168.2.x, they can't communicate directly.
  • Router DHCP range vs. reserved IPs. Your router's DHCP range is .100–.200. Your reserved IPs are in the .50 block. This is correct — they don't overlap. A common mistake is reserving IPs inside the dynamic range.

Implementation

  • You adopted a .50 block scheme: VIP at .50, control plane at .51, worker at .52. This leaves room for future nodes (.53, .54, etc.).
  • architecture.md — Network Topology

Kubernetes Overlay Networks (CNI): When you bootstrap a cluster, the pods need their own IP addresses to communicate. A Container Network Interface (CNI) like Flannel creates an Overlay Network. In your setup, Flannel dynamically provisions a 10.244.0.0/16 subnet on top of your existing 192.168.1.0/24 physical network. When a pod on k8s-cp-01 talks to a pod on k8s-worker-01, Flannel intercepts the 10.244.x.x packet, encapsulates it inside a standard 192.168.1.x packet, sends it across your physical switch, and decapsulates it on the other side. This creates the illusion of a flat network for all pods, regardless of which physical node they run on. Mesh VPNs & Subnet Routers (Tailscale): While Flannel bridges pods internally, what happens when you want to securely access your 192.168.1.x cluster from a coffee shop without port-forwarding your home router? A Mesh VPN (like Tailscale/WireGuard) creates an encrypted point-to-point overlay network across the public internet. By installing Tailscale on a node (e.g., k8s-worker-02) and configuring it as a Subnet Router, that node acts as a secure gateway. It accepts encrypted traffic from your MacBook's Tailscale interface and routes it transparently into the 192.168.1.0/24 physical network, allowing you to ssh into nodes or hit the kube-vip endpoint as if you were physically sitting at home.

Resources