Networking Deep Dive

Chapter 4 covered who can call the Kubernetes API. This chapter covers a different layer entirely: network-level traffic control within the cluster, going deeper than k8s1-6's basic Services material.

CNI — The Container Network Interface

Kubernetes itself doesn't implement pod networking directly — it delegates this to a CNI (Container Network Interface) plugin, a pluggable standard interface, much like Chapter 1's own CRI/containerd pluggability point. Popular implementations: Calico, Cilium, Flannel — each with different capabilities and performance characteristics. Worth knowing directly: some CNI plugins also implement Network Policies (below), while simpler ones (basic Flannel, for instance) don't — genuinely practical to know when troubleshooting later, since "why doesn't my NetworkPolicy do anything" can sometimes simply mean the CNI plugin in use doesn't support it at all.

The Default — Flat, Unrestricted Pod Networking

An important baseline fact: by default, every pod in a Kubernetes cluster can communicate with every other pod, across any namespace, with no restrictions at all. Genuinely surprising coming from a more locked-down mental model. This flat networking model is exactly what makes Chapter 6's Services/DNS work simply — but it also means a compromised pod can, by default, reach anything else in the cluster, a real security consideration worth naming directly.

Network Policies — Restricting Pod-to-Pod Traffic

A NetworkPolicy defines allow rules for traffic to/from pods matching a label selector (Chapter 5, Course 1's own label mechanism, reused again). By default, with no NetworkPolicy at all, everything is allowed.

A Concrete NetworkPolicy Example

Restricting k8s1-12's own capstone database to accept traffic only from pods labeled app: backend — closing a real security gap the capstone's own architecture left implicitly open, despite Chapter 6's Service already existing. This is genuinely the Kubernetes-internal equivalent of cloud1-5's own private-subnet analogy — defense in depth at the pod level, rather than the VPC/subnet level.

Service Meshes — A Brief Overview

Foreshadowed since Chapter 3, Course 1's own sidecar material: a service mesh — Istio and Linkerd being the most common — adds a layer of infrastructure specifically for managing service-to-service communication, typically implemented via a sidecar proxy (Chapter 3's own pattern, now with a concrete real use case) injected into every pod, intercepting all network traffic. What it adds beyond NetworkPolicies:

• Automatic mutual TLS (mTLS) between services (crypto1's own TLS/certificate material).
• Fine-grained traffic routing and canary deployments.
• Detailed per-service traffic metrics and observability (k8s2-7's upcoming chapter builds on this).
• Retry and circuit-breaking logic.

Genuinely powerful — and genuinely adding real operational complexity.

When You Need a Service Mesh vs. When NetworkPolicies Are Enough

Honest framing matching this course's own recurring convention (k8s1-1, k8s1-8): most clusters, even production ones, genuinely don't need a full service mesh. NetworkPolicies alone solve basic traffic restriction. A service mesh earns its complexity specifically at real microservices scale, when mTLS, fine-grained routing, or detailed per-service metrics become genuinely necessary — not adopted just because the name is well known.

Hands-On Exercises