intermediate~4h

Networking II: Ingress & Network Policies

Ingress solves HTTP/HTTPS routing: one entry point routing to many backend Services by hostname and URL path, with centralized TLS termination. NetworkPolicy adds explicit allow rules; once any policy

Ingress itself is just routing-rules -- it does nothing without an Ingress Controller watching and implementing it.
Kubernetes networking is flat and open by default -- every Pod can reach every other Pod with no restriction.
Once any NetworkPolicy selects a Pod for a direction (ingress/egress), that direction becomes default-deny except for explicit allows.
NetworkPolicy enforcement is delegated to the CNI plugin -- not all CNIs support it.
TLS termination at the Ingress layer does NOT encrypt the subsequent hop to backend Pods.

Install an Ingress Controller (e.g. ingress-nginx, or a cloud-managed one) in the cluster -- an Ingress resource does nothing without one watching it.
Create backend Services (ClusterIP) for each application the way you normally would.
Create an Ingress resource with rules mapping hostnames/paths to those backend Services, and reference a TLS Secret for HTTPS termination.
The Ingress Controller watches Ingress objects and programs its own routing (e.g. generates nginx config, reloads) to match.
Separately, to lock down Pod-to-Pod traffic, write NetworkPolicy resources with podSelector + ingress/egress rules for the specific Pods that need restricting.
Remember: the moment any NetworkPolicy selects a Pod for a direction, that direction becomes default-deny for that Pod except what's explicitly allowed -- a policy for one app doesn't affect Pods it doesn't select.

A single Ingress Controller routing app.example.com to a frontend Service and api.example.com/v1 to a backend API Service, with one shared TLS certificate.
Isolating a payments microservice with a NetworkPolicy that allows ingress only from the checkout service's Pods and denies everything else, limiting blast radius if another service is compromised.
A default-deny-all NetworkPolicy applied per namespace as a baseline, with explicit allow rules layered on for services that genuinely need to communicate.
Path-based routing on a single Ingress splitting /api and /admin to two entirely different backend Services under one domain.
Egress NetworkPolicy restricting a Pod so it can only reach an approved external API endpoint and internal DNS, blocking exfiltration paths.

Terminate TLS at the Ingress layer but still encrypt Pod-to-Pod traffic in-cluster (via mTLS/service mesh) for anything handling sensitive data -- Ingress TLS termination does not protect the hop to backend Pods.
Start NetworkPolicy adoption with a default-deny baseline per namespace, then add specific allow rules -- safer than trying to enumerate every existing connection first.
Verify your CNI plugin actually enforces NetworkPolicy before relying on it -- some CNIs silently ignore NetworkPolicy objects entirely.
Use path/host-based routing on a single Ingress Controller instead of provisioning a LoadBalancer per app, to cut cost and operational surface.
Label namespaces and Pods consistently so NetworkPolicy selectors stay maintainable as the number of policies grows.

Assuming NetworkPolicy is enforced by Kubernetes itself -- enforcement is delegated entirely to the CNI plugin, and on a CNI without support, policies are silently accepted but do nothing.
Writing a NetworkPolicy that selects a Pod for ingress but forgetting DNS (port 53 to kube-dns/CoreDNS) in the allowed egress -- the Pod loses the ability to resolve any hostname.
Believing Ingress TLS termination secures the entire request path -- traffic from the Ingress Controller to backend Pods is typically plain HTTP unless separately configured.
Deploying an Ingress resource with no Ingress Controller running in the cluster and expecting it to route traffic -- the resource is inert without a controller.
Writing overlapping Ingress rules across multiple Ingress objects for the same host, causing unpredictable routing depending on controller-specific tie-breaking.
Not testing NetworkPolicy changes in a non-production namespace first -- an overly broad default-deny policy can silently cut off traffic engineers didn't realize depended on it.

Ingress Controllers sit on the request hot path for all external traffic -- tune worker-process/connection-count and keepalive settings on the controller as ingress traffic grows.
Consolidate many Services behind fewer Ingress Controller replicas with host/path-based routing rather than one LoadBalancer per app, cutting both cost and cross-hop latency variance.
NetworkPolicy rule evaluation cost scales with policy count and selector complexity on some CNIs -- keep policies as narrowly scoped and few as practical for Pods handling high connection volume.
Enable HTTP/2 or gRPC support explicitly on the Ingress Controller if backend services need it -- it's not on by default on every controller and silently falls back to HTTP/1.1 otherwise.

Run at least two replicas of the Ingress Controller behind a highly-available LoadBalancer -- it's a single point of failure for all external traffic if under-replicated.
Automate TLS certificate renewal (e.g. cert-manager) rather than manually rotating Ingress TLS Secrets -- expired certificates are a common, avoidable outage cause.
Treat NetworkPolicy rollout like any other production change -- apply to staging first, since an overly restrictive policy is a silent traffic-drop incident rather than a loud failure.
Monitor Ingress Controller error rates and latency specifically, since it sits in front of every externally-facing request.

Install ingress-nginx (or similar) and route two hostnames to two different backend Services through a single Ingress resource.
Configure TLS termination on the Ingress using a self-signed or cert-manager-issued certificate and confirm HTTPS works end-to-end.
Apply a default-deny NetworkPolicy in a namespace, confirm existing Pod-to-Pod traffic breaks, then add a specific allow rule and confirm it's restored.
Write a NetworkPolicy isolating one Deployment's Pods so only Pods with a specific label can reach them, and verify with a test Pod that lacks that label.

Ingress provides HTTP/HTTPS-aware routing via one shared entry point, reducing per-application external LB needs.
Without an Ingress Controller, Ingress objects have no effect.
Kubernetes Pod-to-Pod networking is flat and open by default; NetworkPolicy introduces any restriction.
NetworkPolicy enforcement depends entirely on CNI plugin support -- verify actual enforcement.

Want a visual for this concept?

Generate a diagram tailored to “Networking II: Ingress & Network Policies” — the AI picks whichever visual (flowchart, comparison, sequence, etc.) best fits.

Practice quiz

Next Step

Continue to Storage: Volumes, PVs, PVCs & StorageClass →← Back to all Kubernetes chapters