Chapter 25 of 47 · Networking, part 2

Kubernetes networking

With the basics from chapter 24, Kubernetes networking becomes four simple questions: how do containers in a Pod talk, how do Pods talk, how do Pods reach a Service, and how does the outside world get in. Each answer reuses an idea you already know.

The four kinds of traffic

Click each numbered path:

The three rules

Kubernetes itself does not wire up the network. It sets rules, and a CNI plugin (Calico, Cilium, Flannel, or your cloud's own) builds a network that follows them:

1. Every Pod gets its own IP address.
2. Every Pod can reach every other Pod by that IP, on any node, with no NAT: the address a Pod sees for itself is the address others use.
3. Nodes can reach every Pod, and Pods can reach nodes.

So the whole cluster feels like one big flat network. No port mapping between Pods, unlike docker run -p.

1 · Container to container: localhost

Covered in chapter 6: one Pod is one network namespace, so its containers share one IP and one localhost, and must use different ports.

sidecar → http://localhost:4000 → posts   (never leaves the Pod)

2 · Pod to Pod: a flat network

Each node gets a slice of the Pod range for its Pods. Step through a request from posts on node 1 to comments on node 2:

3 · Pod to Service: a virtual IP

A ClusterIP like 10.96.31.40 is not on any machine. No network card has it. It exists only as rules on every node, written by kube-proxy, saying "traffic to 10.96.31.40:4001 → pick one of these Pod IPs". That is NAT plus load balancing.

DNS inside the cluster

The cluster runs its own DNS server, CoreDNS, itself a Deployment with a Service. Every Pod's /etc/resolv.conf points to it and lists search domains: suffixes tried automatically after a short name. That is why plain posts-srv works. Try names and namespaces:

$ kubectl run tmp --rm -it --image=busybox:1.36 -- nslookup posts-srv
Name:      posts-srv.default.svc.cluster.local
Address:   10.96.20.14

4 · Outside to inside

Pod and Service IPs are private to the cluster. To let a browser in, use one of these (chapter 11 for the first two):

For the blog app from chapter 17, one Ingress replaces four LoadBalancers:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: blog
spec:
  ingressClassName: nginx
  rules:
    - host: blog.example.com
      http:
        paths:
          - path: /posts
            pathType: Prefix
            backend: { service: { name: posts-srv, port: { number: 4000 } } }
          - path: /comments
            pathType: Prefix
            backend: { service: { name: comments-srv, port: { number: 4001 } } }
          - path: /
            pathType: Prefix
            backend: { service: { name: client-srv, port: { number: 3000 } } }

An Ingress is only a set of rules. Something must run them: an ingress controller (e.g. Traefik), installed once per cluster. The newer Gateway API does the same job with more features. Chapter 27 covers both in depth.

NetworkPolicy: who may talk to whom

Rule 2 above means: by default every Pod can reach every Pod, in every namespace. A NetworkPolicy is a firewall rule for Pods, chosen by labels. Example: only the event bus may call moderation:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: moderation-only-from-bus
spec:
  podSelector:
    matchLabels: { app: moderation }      # protect these Pods
  policyTypes: [Ingress]
  ingress:
    - from:
        - podSelector:
            matchLabels: { app: event-bus }   # only from these
      ports:
        - port: 4003

• Once a policy selects a Pod, everything not explicitly allowed is dropped, which shows up as a timeout, not "refused" (chapter 24, #9).
• It only works if your CNI supports it (Calico and Cilium do; plain Flannel does not).
• Chapter 28 goes deeper: default deny, namespaces, egress and common traps.

Debugging checklist

"posts cannot reach comments-srv". Go down the list; each step uses an idea from chapter 24:

1. 1 · Does the name resolve? (DNS)

   $ kubectl exec deployment/posts-depl -- nslookup comments-srv

   Fails → typo, wrong namespace, or the Service does not exist (kubectl get svc -A).

2. 2 · Does the Service have endpoints? (labels)

   $ kubectl get endpointslices -l kubernetes.io/service-name=comments-srv

   Empty → selector does not match Pod labels, or no Pod is ready.

3. 3 · Does the Pod answer directly? (IP + port)

   $ kubectl get pods -o wide            # find the comments Pod IP
   $ kubectl exec deployment/posts-depl -- wget -qO- http://10.244.2.7:4001/

   Refused → app not listening on that port, or listening on 127.0.0.1. Check targetPort = the app's port.

4. 4 · Does the Service answer? (kube-proxy)

   $ kubectl exec deployment/posts-depl -- wget -qO- http://comments-srv:4001/

   Pod works but Service does not → check the Service port/targetPort.

5. 5 · Timeouts? (policy)

   $ kubectl get networkpolicy -A

   A policy silently dropping traffic is the usual cause of timeouts inside a cluster.

Recap

Quick check