Services & Networking
Give Pods stable addresses, expose them, control who can talk to whom, and route external traffic.
The full loop: understand → drill the commands → prove it under the clock. Every objective below is taught here and practised in the drills.
1Understand it
Services
Pods are ephemeral and their IPs change, so you never talk to a Pod directly. A Service gives a stable name and IP that load-balances across Pods matched by labels. ClusterIP is internal-only, NodePort opens a port on every node, LoadBalancer provisions an external load balancer.
- Service selects Pods by label and load-balances across them.
- ClusterIP (internal) → NodePort (node port) → LoadBalancer (external).
- A Service's ClusterIP is stable for its whole life.
Service discovery & DNS
Every Service gets a DNS name inside the cluster, so apps find each other by name, not IP. Same namespace uses the short name; across namespaces use service.namespace. This is how microservices locate one another.
- Same namespace: http://web. Cross-namespace: http://web.other-ns.
- Full form: service.namespace.svc.cluster.local.
- DNS is provided by CoreDNS in the cluster.
NetworkPolicies
By default every Pod can talk to every other Pod. A NetworkPolicy locks that down, it specifies which Pods may send traffic to (ingress) or receive from (egress) a selected set of Pods. This is how you isolate workloads.
- Default is allow-all; a policy selecting a Pod flips it to default-deny for that direction.
- Rules match by podSelector, namespaceSelector, or ipBlock.
- Requires a CNI plugin that enforces policies (e.g. Calico).
Namespace-wide default-deny for incoming traffic
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: default-deny-ingress }
spec:
podSelector: {} # selects ALL pods in the namespace
policyTypes: ["Ingress"] # no ingress rules = deny all inboundIngress
A Service exposes one app; Ingress routes external HTTP/HTTPS to many Services by hostname and path, behind one entry point. An Ingress controller (like nginx) does the routing; the Ingress object is just the rules.
- Routes by host and path to backend Services.
- Needs an Ingress controller running to take effect.
- Handles TLS termination via a referenced Secret.
2 Drill the commands & prove it
Mastery, 0/6 objectives
An objective turns green only when you've solved every drill in it, not just one.
- Expose pods and deployments as Services with kubectl expose, choosing port, target-port, and type0/6
- Create Services imperatively with kubectl create service (clusterip, nodeport) and understand type semantics0/3
- Inspect Services, endpoints, and connectivity with get svc/ep -o wide and port-forward0/4
- Filter resources with label selectors including equality and set-based (-l) expressions0/3
- Author and explain NetworkPolicy: podSelector, policyTypes, ingress/egress from podSelector/namespaceSelector/ipBlock, and default-deny0/5
- Create Ingress rules imperatively and reason about Service DNS FQDNs0/4
Expose deployment 'web' as a ClusterIP Service on port 80 forwarding to container port 8080.
Drills check the command pattern deterministically, there is often more than one correct form. For full fidelity, pair this with real-cluster reps (the killer.sh simulator is included free with your exam registration).