Services and NetworkPolicies Made Simple: How Traffic Reaches Pods (and When It’s Blocked) — CKAD Guidelines

A Pod starts running in your cluster. It has an IP address, so the first instinct is: “I’ll call this IP.” The problem is that Pods are not meant to be stable. They can restart, be replaced, or be rescheduled, and their IP addresses can change. If clients depend on Pod IPs, things break.
That’s why you create a Service.

Service: what it is and how it relates to Pods

A Service is a stable network entry point (DNS name + virtual IP) that forwards traffic to a group of Pods.
Think of it like this:
Pods are the workers doing the job.
The Service is the reception desk with one fixed address.
Clients talk to the reception desk; the desk forwards the request to an available worker.

A Service decides which Pods belong to it by using labels. If the Pods have the right labels, they become targets behind the Service.
Minimal Service YAML

apiVersion: v1
kind: Service
metadata:
  name: backend-svc
spec:
  selector:
    app: backend
  ports:
  - port: 80
    targetPort: 8080

What you should remember (CKAD)

Services route traffic based on labels. If labels don’t match, the Service routes to nothing (no endpoints).
A Service routes traffic; it does not secure it.

Now imagine you have two apps: a frontend and a backend. The frontend calls the backend through the Service name. By default, this usually works because cluster networking is open.

Then you want control: “Only some Pods should be allowed to talk to other Pods.” That is what NetworkPolicies are for.

NetworkPolicy: what it is and how it relates to Pods and Services

A NetworkPolicy defines which network traffic is allowed to and/or from Pods.

It works like a set of firewall rules attached to Pods:

• It selects Pods using labels.

• It declares what sources are allowed to reach them (ingress) and/or where they are allowed to send traffic (egress).

NetworkPolicies do not apply to Services directly. A Service forwards traffic to Pods, and the NetworkPolicy decision happens at the Pod level. So the Service can still “point” to a Pod, but the Pod can refuse the connection based on policy rules.
Minimal NetworkPolicy YAML (allow only frontend → backend on 8080)

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-allow-frontend
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

What you should remember (CKAD)

• NetworkPolicies apply to Pods, not Services.

• If a policy selects a Pod for Ingress or Egress, that direction becomes default-deny (only explicitly allowed traffic passes).

• A policy that selects no Pods does nothing.

Simple mental model
Think of a Pod as a room with two doors: Ingress (in) and Egress (out).
By default, both doors are open.
- If policyTypes: ["Ingress"] applies to the Pod → the in door closes by default; only sources in spec.ingress[].from (and optional ports) can enter.
- If policyTypes: ["Egress"] applies to the Pod → the out door closes by default; only destinations in spec.egress[].to (and optional ports) can be reached.
Only the direction mentioned becomes default-deny; the other stays open.

A simple mental map when traffic fails:

1. Routing question: Is traffic being routed to the correct Pods?
   This is handled by the Service (selectors and endpoints).

2. Permission question: Once traffic reaches the Pod, is it allowed?
   This is handled by the NetworkPolicy (pod selectors, allowed sources/destinations, and ports).

In short:

• Service decides where traffic goes.

• NetworkPolicy decides whether traffic is allowed.

• The final decision is enforced at the Pod.

Command cheat sheet (For CKAD preparation)

Services:

kubectl get svc
kubectl describe svc <svc-name>
kubectl get endpoints <svc-name>

Pods and labels:

kubectl get pods --show-labels
kubectl describe pod <pod-name>

NetworkPolicies:

kubectl get netpol
kubectl describe netpol <policy-name>

Field reference:

kubectl explain service.spec
kubectl explain netpol.spec