Command Palette

Search for a command to run...

Hectal
Phase 3Intermediate4 of 10 in Kubernetes

Networking

How traffic actually finds a pod — from a Service's internal load balancing to Ingress at the cluster's edge, and the DNS that ties every name together.

Topic 1.2 introduced Services as a stable address for a set of pods. This phase goes deeper: how that address actually gets translated into real traffic reaching a real pod, how to expose many services through one shared entry point, how to lock down which pods can talk to which, and the DNS system that makes every service name resolvable in the first place.

0/4 · 0%
4 topics ~56 min 10 code blocks & diagrams
Start with the first topic
1
3.1

Service Networking & kube-proxy

kube-proxy, running on every node, is what actually makes a Service's virtual IP work — intercepting traffic to it and forwarding to one of the real, healthy pods behind it.

14 min 1 diagram 1 code practice

2
3.2

Ingress & Ingress Controllers

An Ingress routes external HTTP(S) traffic to many different Services through ONE shared entry point, based on hostname and path — the standard alternative to provisioning a separate LoadBalancer per service.

14 min 1 diagram 2 code practice

3
3.3

NetworkPolicy: Locking Down Pod-to-Pod Traffic

By default, every pod in a cluster can reach every other pod — a NetworkPolicy is how you actually restrict that, enforcing a genuine allow-list of exactly which traffic should be permitted.

14 min 1 diagram 2 code practice

4
3.4

CoreDNS & Service Discovery

CoreDNS is what actually resolves a Service's name into its ClusterIP — every pod is automatically configured to use it, which is why service discovery in Kubernetes just works without any manual DNS configuration.

14 min 1 diagram 1 code practice