Back to lesson: Expose Workloads with the Right Service Type
Free lab · CKA Prep Program · Module 4: Services and networking
Service and ingress
30 min hands-on · Core
Browser Kubernetes (Killercoda 1-node) or Play-with-Kubernetes; no local installs.
Two ways to do this lab: in your browser on Killercoda (free, no install), or on Play-with-Kubernetes as a free practice field. The Killercoda button opens in a new tab; this study page stays here. Killercoda runs one free scenario at a time: if you see a waiting queue, close other Killercoda tabs and wait a minute.
Objectives
- Expose the same app three ways and compare reachability
- Route two hostnames through one Ingress
- Deny traffic with a NetworkPolicy and prove the deny
Step 1
Three service types
Expose a deployment as ClusterIP, then NodePort, then (if the environment supports it) LoadBalancer. From a test pod, curl each one and record which answers from where.
Step 2
One ingress, two hosts
Create an Ingress routing `one.test` and `two.test` to two different services. Add both names to `/etc/hosts` pointing at the ingress address and curl each path.
Step 3
Default deny
Apply a default-deny NetworkPolicy in the namespace, confirm curls fail, then add an allow rule for one client pod and confirm only it answers.
How to confirm it worked
- Reachability table recorded: which service type answers from where
- Both hostnames route to the correct service
- Deny proven by failed curl, allow proven by single-client success