Kubernetes Networking Fundamentals

The Kubernetes Network Model

Kubernetes networking follows three fundamental rules:

1. Every pod gets its own IP address — No NAT between pods.
2. All pods can communicate with all other pods — Without NAT, across any node.
3. Agents on a node can communicate with all pods on that node — kubelet, kube-proxy, etc.

This flat network model means every pod can reach every other pod using its IP address, regardless of which node it runs on.

Pod Networking

Each pod gets a unique IP from the cluster's pod CIDR range (e.g., 10.244.0.0/16). Containers within the same pod share the network namespace and communicate via localhost:

apiVersion: v1
kind: Pod
metadata:
  name: multi-container
spec:
  containers:
  - name: web
    image: nginx
    ports:
    - containerPort: 80
  - name: sidecar
    image: fluentd
    # Can reach web at localhost:80

A Container Network Interface (CNI) plugin implements the actual networking. Popular CNI plugins include Calico, Cilium, Flannel, and Weave Net.

Services: Stable Endpoints

Pods are ephemeral — they get new IPs when recreated. Services provide stable endpoints:

ClusterIP (Default)

apiVersion: v1
kind: Service
metadata:
  name: api-service
spec:
  selector:
    app: api
  ports:
  - port: 80
    targetPort: 8000
  type: ClusterIP

ClusterIP creates a virtual IP accessible only within the cluster. kube-proxy routes traffic to healthy pod backends. Other pods reach the service via api-service.default.svc.cluster.local or simply api-service within the same namespace.

NodePort

spec:
  type: NodePort
  ports:
  - port: 80
    targetPort: 8000
    nodePort: 30080   # Accessible on every node's IP:30080

NodePort exposes the service on a static port (30000-32767) on every node. External clients reach the service via <any-node-ip>:30080.

LoadBalancer

spec:
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 8000

LoadBalancer provisions an external load balancer (on cloud providers like AWS, GCP, Azure). It creates an external IP that routes to the service.

Ingress: HTTP Routing

Ingress provides HTTP/HTTPS routing to Services based on hostname and path:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80
  - host: web.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80

An Ingress Controller (Nginx Ingress, Traefik, or HAProxy) must be installed to process Ingress resources.

Network Policies

By default, all pods can communicate with all other pods. NetworkPolicies restrict traffic:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-policy
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: web
    ports:
    - port: 8000
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database
    ports:
    - port: 5432

This policy allows the api pods to receive traffic only from web pods on port 8000 and send traffic only to database pods on port 5432. All other traffic is denied.

DNS in Kubernetes

CoreDNS provides service discovery within the cluster:

<service>.<namespace>.svc.cluster.local
api-service.default.svc.cluster.local    → ClusterIP
api-service.production.svc.cluster.local → ClusterIP in production namespace

Pods can use short names within the same namespace (api-service) or fully qualified names across namespaces.