DEV Community

Cover image for Kubernetes Networking [Level-0: Linux Networking Basics for Kubernetes]
ADITYA RAJ
ADITYA RAJ

Posted on

Kubernetes Networking [Level-0: Linux Networking Basics for Kubernetes]

#devops #kubernetes #networking #linux

If you've ever opened a Kubernetes networking doc and seen words like CNI, veth, network namespace, bridge, iptables, or eBPF and felt completely lost — you're not alone. The truth is, none of these concepts are Kubernetes-specific. They're all built directly on top of Linux networking primitives.

This guide is "Level 0" of a Kubernetes networking series. Before we touch a single Kubernetes manifest, we're going to build a rock-solid mental model of how Linux moves packets around — because once you understand that, Kubernetes networking stops feeling like magic and starts feeling like Lego blocks snapping together.

Table of Contents

  1. What Problem Does Networking Solve?
  2. IP Addresses: Identifying a Machine
  3. Ports: Identifying an Application
  4. Network Interfaces
  5. Loopback and localhost
  6. Network Namespaces
  7. Why Namespaces Matter
  8. veth Pairs: Virtual Network Cables
  9. Linux Bridges: Virtual Switches
  10. Routing Tables
  11. Default Gateway
  12. NAT: Network Address Translation
  13. The Full Packet Journey
  14. Essential Linux Networking Commands
  15. Putting It All Together: A Mental Model
  16. Level 0 Checkpoint
  17. What's Next: Pod Networking

What Problem Does Networking Solve?

At its core, networking answers one simple question: how does data get from one machine to another?

Imagine two computers on a network:

Computer A                         Computer B
10.0.0.10                          10.0.0.20

   Application  ─────────────────→  Application
Enter fullscreen mode Exit fullscreen mode

Application A wants to send data to Application B. Networking is the set of rules and mechanisms that make this possible — and everything in this article builds toward answering that question in increasingly precise ways.

IP Addresses: Identifying a Machine

An IP address identifies a network endpoint — think of it as a machine's postal address.

Person
  ↓
House address
  ↓
10.0.0.10
Enter fullscreen mode Exit fullscreen mode

If you want to send traffic to a specific machine, you address it using its IP:

Destination = 10.0.0.10
Enter fullscreen mode Exit fullscreen mode

Ports: Identifying an Application

A single machine usually runs many applications at once. So how does traffic know which application to reach? That's what ports are for.

10.0.0.10

22     → SSH
80     → HTTP
443    → HTTPS
8080   → Application
5432   → PostgreSQL
Enter fullscreen mode Exit fullscreen mode

In short:

  • IP = which machine?
  • Port = which application on that machine?

For example, 10.0.0.10:8080 means: send traffic to machine 10.0.0.10, on port 8080.

Network Interfaces

A computer needs a "door" through which network traffic enters and leaves. That door is called a network interface.

On Linux, you can list interfaces with:

ip addr
Enter fullscreen mode Exit fullscreen mode

You'll typically see names like lo, eth0, or on modern systems, ens5 or enp0s3. Don't worry about the naming conventions yet — just know that every interface is a gateway between an application and the outside network.

Application
     |
     ↓
Network stack
     |
     ↓
   eth0
     |
     ↓
   Network
Enter fullscreen mode Exit fullscreen mode

Loopback and localhost

You'll frequently encounter this address:

127.0.0.1
Enter fullscreen mode Exit fullscreen mode

This is the loopback address — it always means "this machine, talking to itself."

Application A
     |
     ↓
127.0.0.1
     |
     ↓
Same machine
Enter fullscreen mode Exit fullscreen mode

For example:

curl http://127.0.0.1:8080
Enter fullscreen mode Exit fullscreen mode

This tells your machine: connect to port 8080 on myself. The hostname localhost typically resolves to this same address.

Network Namespaces

Now we reach a concept that is critical for understanding Kubernetes: network namespaces.

Linux lets you create fully isolated networking environments on a single machine. Each one can have its own interfaces, IP addresses, routing table, and firewall rules.

Linux Machine

┌──────────────────────────────┐
│ Network Namespace A          │
│ IP: 10.0.0.10                │
└──────────────────────────────┘
Enter fullscreen mode Exit fullscreen mode

You can spin up another, completely isolated from the first:

Linux Machine

┌──────────────────────────────┐
│ Namespace A                  │
│ IP: 10.0.0.10                │
│                              │
│ Namespace B                  │
│ IP: 10.0.0.20                │
└──────────────────────────────┘
Enter fullscreen mode Exit fullscreen mode

This concept becomes essential once we talk about Kubernetes Pods — each Pod gets its own network namespace.

Why Namespaces Matter

Imagine two applications that both want to bind to port 8080 on the same machine:

Machine

Application A → :8080
Application B → :8080   ❌
Enter fullscreen mode Exit fullscreen mode

Without isolation, this fails — two processes can't bind the same host IP/port combination.

But give each application its own network namespace, and the conflict disappears:

Namespace A → 10.0.0.10:8080
Namespace B → 10.0.0.20:8080
Enter fullscreen mode Exit fullscreen mode

Both can happily use port 8080 because they live in separate network environments. This is the foundational idea behind containers — and by extension, Kubernetes Pods.

veth Pairs: Virtual Network Cables

Isolated namespaces are only useful if we can also connect them. Linux provides a mechanism called a veth pair for exactly this purpose.

Think of a veth pair as a virtual network cable with two ends — anything that goes in one end comes out the other.

Namespace A                    Host

   eth0
    |
  veth-A  ═══════════════  veth-B
                              |
                           Host network
Enter fullscreen mode Exit fullscreen mode

One end lives inside a namespace; the other end lives on the host (or in another namespace). This is exactly how a container's network interface gets connected to the outside world.

Linux Bridges: Virtual Switches

Once you have multiple namespaces, you need a way to connect all of them together — not just in pairs. That's where a Linux bridge comes in.

             Linux Bridge
           ┌──────────────┐
           │    bridge    │
           └─┬────┬────┬──┘
             │    │    │
             ↓    ↓    ↓
            A     B    C
Enter fullscreen mode Exit fullscreen mode

A helpful mental model: a bridge is essentially a virtual Layer-2 switch. Each namespace connects to the bridge via its own veth pair, and the bridge forwards traffic between them just like a physical switch would.

Routing Tables

Now suppose you have two separate networks:

Network A: 10.0.1.0/24
Network B: 10.0.2.0/24
Enter fullscreen mode Exit fullscreen mode

A machine on Network A wants to reach 10.0.2.10. How does Linux decide where to send that packet? It consults its routing table.

You can inspect it with:

ip route
Enter fullscreen mode Exit fullscreen mode

Example output:

10.0.1.0/24 dev eth0
10.0.2.0/24 via 10.0.1.1
default via 10.0.1.1
Enter fullscreen mode Exit fullscreen mode

Read each line as: for this destination network, send traffic here.

Default Gateway

What if your machine wants to reach an address it has no specific route for — like 8.8.8.8? It falls back to the default route, also known as the default gateway.

default via 10.0.0.1
Enter fullscreen mode Exit fullscreen mode

This simply means: "If I don't know where else to send this traffic, send it to 10.0.0.1."

Your machine (10.0.0.10)
     |
     ↓
Gateway (10.0.0.1)
     |
     ↓
Internet
Enter fullscreen mode Exit fullscreen mode

NAT: Network Address Translation

Here's another crucial concept. Suppose your private network is 10.0.0.0/24, and your machine is 10.0.0.10. The public internet has no idea how to route traffic back to a private address like that directly.

To solve this, a router performs NAT (Network Address Translation) — rewriting private addresses into a public one (and remembering the mapping so return traffic gets routed correctly).

Private network
10.0.0.10
     |
     | NAT
     ↓
Public IP
     |
     ↓
Internet
Enter fullscreen mode Exit fullscreen mode

For example:

10.0.0.10:50000  →  203.x.x.x:40000
Enter fullscreen mode Exit fullscreen mode

NAT will come up again and again once we start discussing Kubernetes traffic flows like Pod → Internet, Node → Internet, and Service → Pod.

The Full Packet Journey

Let's connect all the dots. Suppose Application A (10.0.0.10) wants to talk to Application B (10.0.0.20). The simplified journey looks like this:

Application A
      ↓
Socket
      ↓
TCP/IP stack
      ↓
Routing decision
      ↓
Network interface
      ↓
Network
      ↓
Network interface
      ↓
TCP/IP stack
      ↓
Application B
Enter fullscreen mode Exit fullscreen mode

This flow — socket, stack, routing decision, interface, network, and back again — is the foundation for everything else you'll learn about Kubernetes networking.

Essential Linux Networking Commands

You don't need to memorize hundreds of commands. These few will get you very far:

# See interfaces and IP addresses
ip addr        # or: ip a

# See the routing table
ip route

# See interfaces briefly
ip link

# Test basic connectivity
ping <IP>

# Test an application/service
curl http://<IP>:<PORT>

# See listening ports
ss -lntp
Enter fullscreen mode Exit fullscreen mode

These commands will become your go-to Kubernetes networking debugging toolkit later on — get comfortable with them now.

Putting It All Together: A Mental Model

Keep this picture in your head as your baseline model of a single Linux machine:

                 Linux Machine
┌────────────────────────────────────────┐
│ Application                            │
│      ↓                                 │
│ Socket                                 │
│      ↓                                 │
│ Network Stack                          │
│      ↓                                 │
│ Routing Table                          │
│      ↓                                 │
│ Network Interface                      │
└──────┼─────────────────────────────────┘
       ↓
     Network
       ↓
   Other machine
Enter fullscreen mode Exit fullscreen mode

Now layer in network namespaces:

Linux Machine
│
├── Network Namespace A → eth0
├── Network Namespace B → eth0
└── Host Network Namespace → eth0
Enter fullscreen mode Exit fullscreen mode

Connect them with veth pairs:

Namespace A
    |
   eth0
    |
  veth
    ║
  veth
    |
  Host
Enter fullscreen mode Exit fullscreen mode

And tie them together with a bridge:

   Namespace A       Namespace B
        |                 |
        └───────┬─────────┘
             ┌───────┐
             │Bridge │
             └───────┘
                 |
              Network
Enter fullscreen mode Exit fullscreen mode

This exact combination — namespace + veth + bridge + routing — is what Kubernetes uses under the hood to give every Pod its own network identity.

Level 0 Checkpoint

Before moving on to Pod networking, make sure you can explain each of these in plain, simple language:

  • IP address
  • Port
  • Network interface
  • Loopback
  • Network namespace
  • veth pair
  • Linux bridge
  • Routing table
  • Default gateway
  • NAT

And most importantly, internalize this relationship:

Network Namespace + veth + bridge + routing → Network connectivity
Enter fullscreen mode Exit fullscreen mode

If that equation makes sense to you, you're ready for the next level.

What's Next: Pod Networking

In the next part of this series (Level 1), we'll take everything covered here and answer the first real Kubernetes networking question:

When Kubernetes creates a Pod, where does the Pod's network actually come from?

We'll trace the full path:

kubectl run nginx
       ↓
Kubernetes creates Pod
       ↓
Network namespace
       ↓
veth pair
       ↓
Pod eth0
       ↓
Pod IP
       ↓
Node network
Enter fullscreen mode Exit fullscreen mode

That's the exact point where Linux networking transforms into Kubernetes networking.

Conclusion

Kubernetes networking can feel intimidating, but it's really just a clever composition of well-known Linux primitives: IP addresses, ports, network namespaces, veth pairs, bridges, routing tables, and NAT. Once these concepts click, terms like CNI, iptables, and eBPF stop being buzzwords and start being tools you understand at a mechanical level.

Take the time to run the commands in this article on your own Linux machine (or a cheap VM) — ip addr, ip route, ss -lntp — and get a feel for what your own system's networking actually looks like. That hands-on intuition is what makes the next level, Pod networking, click into place effortlessly.

Enjoyed this breakdown? If you're following along with this Kubernetes networking series, drop a comment, follow for Level 1 on Pod Networking, and share this with a teammate who's still afraid of iptables. Let's demystify Kubernetes networking together, one Linux primitive at a time. 🚀

Top comments (0)