By default, every Pod in a Kubernetes cluster can reach every other Pod in every other namespace — the cluster network is flat, and there is no network-layer separation between the production API and the development database. This flat default model is a significant blast radius amplifier: a compromised Pod in a development namespace can attempt connections to production databases, internal admin interfaces, and cluster metadata services. NetworkPolicies implement layer 4 (TCP/UDP) micro-segmentation by selecting Pods via label selectors and defining which ingress traffic sources and egress traffic destinations are permitted. A NetworkPolicy is not enforced by Kubernetes itself — it is a declarative specification that the cluster's CNI plugin (Calico, Cilium, WeaveNet) reads and translates into kernel-level packet filter rules. Clusters using a CNI plugin that does not implement NetworkPolicy (such as Flannel without a NetworkPolicy engine) silently ignore all NetworkPolicy resources, creating a false sense of security.
25 minintermediate
NetworkPolicies — ingress and egress traffic control between Pods
Analogy🏏Cricket
🏏 Think of it like cricket: The Pod-ReplicaSet-Deployment hierarchy maps precisely onto the three levels of IPL franchise team management. A Pod is a single player on the field at a given moment — the smallest unit of participation, carrying its own identity and fulfilling a specific role in the current game. A ReplicaSet is the franchise's match-day playing XI contract — it specifies that exactly eleven players matching a specific profile must always be on the field; if one is injured and leaves, the team management immediately sends a substitute of the same profile to restore the count. A Deployment is the franchise's season-long team strategy — it manages how the playing XI evolves between matches: when a new batting approach is adopted, the Deployment replaces the old XI with the new one in a controlled rolling substitution rather than swapping all eleven players simultaneously and disrupting team cohesion. Just as the franchise director does not manage individual players directly — the playing XI contract (ReplicaSet) handles the count and the season strategy (Deployment) handles the transitions — you never manage Pods directly in production; the Deployment manages the transition and the ReplicaSet maintains the count. This reveals why the three-level hierarchy exists rather than one omnibus 'workload' object: each level solves one specific problem, and composing three focused abstractions produces better separation of concerns than one object that conflates scheduling, scaling, and update management.
Lesson 24 of 33
0% complete