kubernetes-networking

Kubernetes Networking

Every networking problem in Kubernetes is a chain: client → DNS → Service → Endpoints → pod IP → container port. When something doesn't connect, the fix is to walk that chain in order instead of guessing at layer seven first. Most "the app is broken" tickets are actually a label selector typo two links up the chain.

Services are not load balancers in the traditional sense — they're a label query that produces a list of IPs, continuously recomputed. If a Service has no endpoints, nothing downstream matters yet.

For concrete NetworkPolicy manifests and Gateway API routing configurations, read references/network-policy-and-gateway-api.md.

1. Check endpoints before you check anything else

kubectl get endpoints <svc> (or endpointslices) tells you immediately whether the Service's selector is matching any Ready pods. An empty list is the single most common root cause of "connection refused" or 502s inside the cluster, and it's a one-command diagnosis.

kubectl get svc <name> -o yaml | grep -A3 selector
kubectl get pods --show-labels -l <same-selector>
kubectl get endpoints <name>

• Selector typo or label drift: the Service's selector must exactly match pod labels — a deploy that changed a label without updating the Service breaks silently.
• No Ready pods: a pod can be Running but not Ready, and not-Ready pods are excluded from endpoints by design — check readiness probes, covered in kubernetes-operations.
• containerPort mismatch: the Service's targetPort must match what the container actually listens on, not just what's documented.

Done when: kubectl get endpoints shows the expected pod IPs, or you've identified exactly why it doesn't.

2. Pick the Service type for the audience, not the convenience

ClusterIP is the default and correct choice for anything internal — don't expose things externally because LoadBalancer was easier to type. Each type answers a different "who can reach this": ClusterIP is cluster-internal, NodePort exposes a port on every node (rarely what you want in production), LoadBalancer provisions a cloud LB per Service (expensive at scale), and Ingress is the only one built to multiplex many HTTP services behind one entrypoint.