K8s Network Digest — Issue #47

// DIAGRAM 01

Pod-to-Pod Networking

In Kubernetes, every Pod gets its own unique IP address. Pods communicate directly without NAT — whether on the same node or across nodes — via the cluster's overlay or underlay network.

FIG 1.0 — KUBERNETES POD NETWORK MODEL (MULTI-NODE)

◈ NODE 1 | 192.168.1.10

pod-frontend10.244.1.2

pod-api10.244.1.3

pod-cache10.244.1.4

veth pairs

cbr0 / bridge (10.244.1.0/24)

eth0 (tunnel / overlay)

◈ NODE 2 | 192.168.1.11

pod-db10.244.2.2

pod-worker10.244.2.3

pod-monitor10.244.2.4

veth pairs

cbr0 / bridge (10.244.2.0/24)

eth0 (tunnel / overlay)

▶ CLUSTER CIDR: 10.244.0.0/16 | No NAT between pods | Direct L3 routing

      K8s Networking Rule #1: Every Pod can communicate with every other Pod in the cluster without NAT. This is the fundamental contract that all CNI plugins must fulfill.
    

veth paircbr0overlay IPAMno NATL3 routing

// DIAGRAM 02

Kubernetes Service Types

Services provide stable virtual IPs for a set of Pods. kube-proxy programs iptables/IPVS rules to load-balance traffic across healthy Pod endpoints.

FIG 2.0 — SERVICE TYPES COMPARISON

ClusterIP

Internal Client

↓

ClusterIP
10.96.0.100:80

↓ iptables/IPVS

Pod :8080

🔒 Internal only
No external access

NodePort

External Client

↓

NodeIP:30080
(30000–32767)

↓

ClusterIP:80

↓

Pod :8080

⚡ Static high port
All nodes exposed

LoadBalancer

Internet

↓

Cloud LB
203.0.113.10:80

↓

NodePort

↓

ClusterIP

↓

Pod :8080

// DIAGRAM 03

Ingress & Ingress Controllers

Ingress exposes HTTP/HTTPS routes from outside the cluster to Services. An Ingress Controller (e.g. NGINX, Traefik, HAProxy) watches Ingress resources and configures the reverse proxy accordingly.

FIG 3.0 — INGRESS TRAFFIC FLOW & ROUTING RULES

🌐
INTERNET
External Traffic

→

🔒 TLS TERMINATION
Port 443 / 80

→

NGINX INGRESS
CONTROLLER
Ingress Resource

→

svc/frontend
ClusterIP:80

svc/api
ClusterIP:8080

host: app.example.com path: / → svc/frontend:80

host: app.example.com path: /api → svc/api:8080

host: admin.example.com path: / → svc/dashboard:3000

host: *.example.com path: /* → svc/default:80

// DIAGRAM 04

CNI Plugin Landscape

The Container Network Interface (CNI) is a spec for configuring Linux network interfaces for containers. Choosing the right CNI plugin dramatically affects performance, policy enforcement, and operational complexity.

FIG 4.0 — POPULAR CNI PLUGINS COMPARISON

⚡ Calico BGP POLICY BGP-based routing, no overlay. Full NetworkPolicy support + Calico policies. Best for on-prem.

🔷 Cilium eBPF L7 AWARE eBPF-based, high performance, L7 visibility, HTTP/gRPC policy enforcement & service mesh.

🌐 Flannel OVERLAY VXLAN Simple VXLAN overlay. Easy to set up. No NetworkPolicy support natively. Good for dev/test.

🕸️ Weave Net MESH ENCRYPT Full-mesh overlay with optional encryption. NetworkPolicy supported. Multi-cloud friendly.

// DIAGRAM 05

NetworkPolicy: Firewall for Pods

NetworkPolicy resources let you control which Pods can communicate with each other and with external endpoints. By default, all traffic is allowed — adding a NetworkPolicy enables default-deny behavior for matched Pods.

FIG 5.0 — NETWORKPOLICY INGRESS / EGRESS ENFORCEMENT

NAMESPACE: frontend

pod-web ✓
10.244.1.5

pod-mobile ✓
10.244.1.6

✓ ALLOWED

INGRESS

———→

NetworkPolicy
app: api-server

←———

EGRESS

port: 8080/TCP
selector: app=api

NAMESPACE: default

pod-unknown ✗
10.244.3.2

pod-test ✗
10.244.3.3

✗ BLOCKED

      Security Best Practice: Always apply a default-deny NetworkPolicy to every namespace, then explicitly allow only required traffic paths. Treat Pod networking like a zero-trust firewall.
    

// DIAGRAM 06

CoreDNS & Service Discovery

CoreDNS is the default DNS server in Kubernetes. It resolves Service names to ClusterIPs and handles DNS queries from all Pods through the kube-dns ClusterIP (typically 10.96.0.10).

FIG 6.0 — DNS RESOLUTION FLOW IN KUBERNETES

1

Pod queries: my-service.my-namespace.svc.cluster.local → Pod's /etc/resolv.conf points to 10.96.0.10 (kube-dns)

2

Request arrives at CoreDNS Pod (kube-system namespace) → CoreDNS checks Kubernetes API for matching Service

3

CoreDNS returns A record: 10.96.45.123 (ClusterIP) → For Headless Services, returns Pod IPs directly (no ClusterIP)

4

Pod connects to 10.96.45.123:80 → kube-proxy iptables rule load-balances to a backend Pod

CoreDNS Pluggable DNS server. Runs as Deployment in kube-system. Extensible via Corefile plugins.

ndots:5 Default search domain behaviour. Queries expand through 5 suffixes before going upstream.

Headless Svc ClusterIP: None. Returns Pod IPs via DNS. Used for StatefulSets and direct Pod addressing.

// THIS WEEK IN K8S NETWORKING

Featured Articles

Curated deep-dives from the community and official docs.

Deep Dive

eBPF vs iptables: The Performance Gap in 2026

Cilium's eBPF dataplane shows 40% lower latency at 100k RPS compared to kube-proxy iptables mode in latest benchmarks.

Tutorial

Dual-Stack IPv4/IPv6 Clusters in Production

Step-by-step guide to enabling IPv4/IPv6 dual-stack on EKS, GKE, and bare-metal kubeadm clusters.

Security

FQDN-based Egress NetworkPolicy with Cilium

How to restrict Pod egress to specific hostnames using Cilium's CiliumNetworkPolicy CRD beyond standard K8s NetworkPolicy.

Architecture

Gateway API: The Future of Kubernetes Ingress

Gateway API v1.0 is GA. How it replaces Ingress with role-oriented resources: GatewayClass, Gateway, HTTPRoute, and TCPRoute.

// PRO TIPS

3 Commands This Week

01

Debug Pod DNS

kubectl run dns-test \ --image=busybox \ --restart=Never \ --rm -it -- \ nslookup kubernetes

02

Inspect iptables Rules

iptables-save | \ grep KUBE | \ grep "dport 80" | \ head -20

03

Trace Network Policy

kubectl get netpol \ -A -o wide # Cilium policy trace: cilium policy trace \ --src-k8s-pod \ default:pod-a