Skip to content

Portal | Level: L2: Operations | Topics: Kubernetes Networking, Linux Networking Tools | Domain: Kubernetes

Kubernetes Networking

Scope

This document explains Kubernetes networking from the practical internal view. It covers:

  • Pod networking
  • CNI
  • Services
  • kube-proxy modes
  • ClusterIP / NodePort / LoadBalancer
  • DNS
  • ingress concepts
  • common failure modes
  • relationship to plain Linux networking

Big picture

Kubernetes networking is mostly a coordination layer over Linux networking primitives plus a CNI implementation.

Core requirements

At a high level, Kubernetes expects:

  • every Pod gets an IP
  • Pods can communicate with other Pods without NAT in the cluster model
  • nodes can reach Pods
  • Services provide stable virtual access to changing Pod backends

How this is implemented depends heavily on the CNI plugin and platform.

flowchart TD
    subgraph Pod
        C1[Container] --> C2[Container]
    end
    Pod -->|veth pair| BR[Node Bridge / CNI]
    BR -->|pod-to-pod same node| Pod2[Pod B]
    BR -->|overlay / routed| Node2[Remote Node CNI]
    Node2 --> Pod3[Pod on Node 2]
    Pod -->|ClusterIP| KP[kube-proxy / iptables / IPVS]
    KP -->|endpoint selection| Backend[Backend Pod]
    Client[External Client] --> Ingress[Ingress Controller]
    Ingress --> SVC[Service]
    SVC --> KP
    Client --> LB[LoadBalancer]
    LB --> NP[NodePort]
    NP --> KP

Pod networking model

Each Pod gets its own network namespace and IP. Containers inside the same Pod share that namespace.

Typical single-node mental model

container in Pod
  -> veth
  -> host namespace
  -> bridge / routing / CNI rules
  -> other Pods / node / external network

Important consequence

Pods are not "inside Docker networks" conceptually in Kubernetes. The network is pod-centric, not container-centric.

CNI role

Kubernetes itself does not implement all data-plane networking. The Container Network Interface ecosystem provides plugins that configure connectivity.

CNI responsibilities often include:

  • interface creation
  • IPAM / IP allocation
  • route setup
  • bridge/overlay attachment
  • policy hook integration depending on plugin
  • cleanup on teardown

Why this matters

If Pod creation fails at networking time, the failure may be in:

  • CNI binary/plugin chain
  • IPAM exhaustion
  • route programming
  • host firewall/nftables rules
  • overlay tunnel setup
  • cloud network attachment logic

Pod-to-Pod traffic

Pod-to-Pod connectivity may be implemented via:

  • pure routed model
  • bridge + routing model
  • overlay encapsulation (VXLAN, Geneve, etc.)
  • cloud-native secondary attachment mechanisms

Overlay tradeoffs

Pros:

  • simpler flat cluster addressing across nodes
  • independence from underlay routing

Cons:

  • encapsulation overhead
  • MTU complexity
  • extra moving parts

Routed/underlay tradeoffs

Pros:

  • less encapsulation overhead
  • potentially cleaner performance

Cons:

  • underlay routing requirements
  • cloud/platform constraints

Services

Pods are ephemeral; Services provide stable discovery and access.

Service purpose

A Service gives a stable virtual endpoint for a set of backend Pods selected by labels.

Service types

  • ClusterIP
  • NodePort
  • LoadBalancer
  • ExternalName (different beast; name indirection, not real proxying)

ClusterIP

A ClusterIP Service exposes a virtual IP reachable inside the cluster.

Packets destined to that virtual IP are redirected to backend Pod endpoints by kube-proxy or equivalent data-plane mechanisms.

Important truth

The Service IP is not usually a real interface address with a process listening on it. It is a virtual abstraction implemented via rules/data plane programming.

kube-proxy

kube-proxy programs the node networking stack for Services.

Modes on Linux include:

  • iptables
  • ipvs
  • nftables in newer Kubernetes support paths

iptables mode

Historically common. Works by programming netfilter rules to steer Service traffic.

IPVS mode

Uses kernel IPVS plus supporting rules. Hash-table-based and often better at scale than giant iptables chains.

nftables mode

Newer direction on supported systems. Relevant because modern Linux networking is increasingly nftables-oriented.

Why kube-proxy matters

Many "Service is broken" incidents are really:

  • endpoint programming stale
  • kube-proxy unhealthy
  • rules not present
  • node-local path issue
  • CNI incompatibility or assumptions

Endpoints / EndpointSlices

A Service selects backends. Those backends are represented via endpoint objects.

Modern clusters use EndpointSlices for scalability.

Why this matters

The service path is:

Service selector
  -> endpoint objects
  -> kube-proxy / data plane rules
  -> actual Pod IPs

If selector or readiness is wrong, the Service can exist happily while routing to nothing.

NodePort

Exposes the Service on a port on each node.

Useful for:

  • simple external access
  • integration with external load balancers
  • lab setups

Operational downsides:

  • large exposed port surface
  • less elegant than true ingress/load balancer integration
  • node topology concerns

LoadBalancer Service

On supported platforms, requesting type: LoadBalancer asks infrastructure integration to provision an external load balancer and map traffic toward cluster backends.

What actually happens depends on environment:

  • cloud provider integration
  • MetalLB-like systems on bare metal
  • custom controllers

Ingress and HTTP routing

Ingress is about L7 HTTP/HTTPS routing via an ingress controller.

Important distinction:

  • Ingress resource is config
  • ingress controller is the actual implementation

Without a controller, an Ingress object is just decorative YAML.

DNS

Kubernetes DNS provides service discovery such as:

  • service names
  • namespace-qualified names
  • pod/service search domains

Typical path:

pod resolver config
  -> cluster DNS service
  -> CoreDNS / DNS backend
  -> cluster/internal answer or upstream resolution

Why DNS matters

Many "network" failures are actually DNS failures:

  • wrong search path expectations
  • DNS service unavailable
  • upstream recursion issue
  • large query load
  • NetworkPolicy blocking DNS

NetworkPolicy

NetworkPolicy expresses allowed traffic relationships at Pod level in supported CNI environments.

Important caveat

NetworkPolicy is only effective if the CNI/data plane supports and enforces it.

Having YAML is not the same as having enforcement.

Conceptual model

Policies generally define:

  • which Pods/namespaces may talk to which Pods
  • which ports/protocols are allowed
  • ingress and/or egress constraints

Once policies select a Pod, traffic not explicitly allowed is typically denied for the covered direction.

Common packet paths

Pod to Pod on same node

pod A
  -> veth
  -> host namespace bridge/routing
  -> pod B veth
  -> pod B

Pod to Pod on different nodes

pod A
  -> node A CNI path
  -> overlay or routed underlay
  -> node B CNI path
  -> pod B

Pod to ClusterIP Service

pod
  -> service virtual IP
  -> kube-proxy rules
  -> chosen endpoint Pod IP
  -> backend Pod

External client to LoadBalancer/Ingress

client
  -> external load balancer / ingress controller
  -> service / node backend
  -> target Pod

Failure modes

1. Pod can reach IPs but not service names

Likely DNS issue.

2. Service exists but no traffic reaches Pods

Possible causes:

  • selector mismatch
  • readiness false so endpoints absent
  • kube-proxy rules stale/missing
  • CNI/data-plane issue
  • NetworkPolicy block

3. Pod-to-Pod broken across nodes only

Likely:

  • overlay tunnel issue
  • routing between node CIDRs broken
  • MTU/encapsulation issue
  • firewall blocking CNI traffic
  • cloud route programming broken

4. NodePort works on one node but not another

Possible causes:

  • kube-proxy inconsistency
  • local firewall differences
  • endpoint-local traffic policy expectations
  • cloud/NLB health target mismatch

5. Ingress object created but nothing responds

Likely:

  • no controller
  • wrong ingress class
  • controller not healthy
  • backend service wrong
  • TLS/host rule mismatch

Practical debugging workflow

Step 1 - identify which path is broken

  • Pod -> Pod?
  • Pod -> Service?
  • Pod -> DNS?
  • External -> Service?
  • External -> Ingress?

Step 2 - inspect objects

  • Pod readiness
  • Service selector
  • EndpointSlice membership
  • NetworkPolicy presence
  • ingress controller status

Step 3 - inspect node data plane

  • kube-proxy mode/rules
  • CNI agent health
  • routes
  • interfaces
  • iptables/nftables/IPVS state

Step 4 - test at multiple layers

  • DNS resolution
  • direct Pod IP
  • Service IP
  • node-local path
  • external LB path

Relationship to plain Linux networking

Kubernetes networking is mostly:

  • network namespaces
  • veth pairs
  • bridges
  • routes
  • iptables/nftables/IPVS
  • overlay tunnels
  • conntrack
  • load balancing rules

The control plane automates the data plane, but it does not repeal Linux networking reality.

If you understand Linux packet flow, Kubernetes networking becomes much less spooky.

Interview angles

Questions commonly hidden here:

  • how Pods get IPs
  • what CNI does
  • what kube-proxy does
  • difference between Service types
  • why Service IP is virtual
  • difference between Ingress and Service
  • how readiness affects service routing
  • why NetworkPolicy may do nothing if CNI lacks enforcement
  • why DNS is central to Kubernetes connectivity

Strong answers connect Kubernetes abstractions back to Linux primitives.

Mental model to keep

Kubernetes networking is a two-layer system:

  1. control plane objects define intent
  2. CNI + kube-proxy + host Linux networking implement the packet path

When it breaks, ask:

  • is the control-plane intent wrong,
  • or is the node data plane failing to realize that intent?

References

Wiki Navigation

Prerequisites

Related Content