Port-Forward a Kubernetes Service to localhost
Scenario
The platform team has deployed a hardened, distroless nginx image
(cgr.dev/chainguard/nginx) in the webapps namespace. A ClusterIP
Service named nginx-cgr-svc exposes the Deployment inside the
cluster, but ClusterIP Services are not reachable from outside the
cluster directly.
Task
- Inspect the
webappsnamespace and find the port on which the Servicenginx-cgr-svcis exposed. - Port-forward the Service
nginx-cgr-svcto localhost port3333oncplane-01. - Use
curlto fetch the page fromlocalhost:3333and save the response body to/home/laborant/index.html.
kubectl port-forward runs in the foreground and keeps your terminal
busy for as long as the tunnel is open. You will need two terminal
tabs for cplane-01: one to keep the port-forward running, and
another to run curl against localhost:3333.
You can open a second tab right from here:
new terminal on cplane-01Alternatively, you can run the port-forward in the background so that a single tab is enough. See Hint 3.
Hint 1 - Find the Service's Port
Before you can port-forward, you need to know which port the Service
exposes to the rest of the cluster. That value lives under
spec.ports[].port in the Service definition. It is not the same
as the port the container listens on internally (the Service handles
that translation via targetPort).
Use kubectl to inspect the resources in the webapps namespace.
Both the list view and the describe view will show you the port number
you need.
Documentation
Hint 2 - Port-Forward the Service (two-tab approach)
kubectl port-forward can target a Service directly using the
svc/<name> form. The argument that controls which ports are connected
follows the pattern <local-port>:<service-port>, where
<service-port> is the number you found in Hint 1 and <local-port>
is the port you want to open on cplane-01 (the task tells you which
one to use).
Because the command occupies the terminal for as long as the tunnel is
open, you will need a second terminal tab to run anything else while it
is active. Once it is running, ss -tlnp is a good way to confirm the
local port is in LISTEN state before you proceed.
Documentation
Hint 3 - Single-tab approach (background port-forward)
If you want to avoid opening a second tab, the shell lets you run any
command in the background by appending & to it. The shell variable
$! immediately captures the PID of the most recently backgrounded
process, which you can use later to stop it cleanly with kill.
The general pattern looks like:
<your port-forward command> &
PF_PID=$!
sleep 2 # give the tunnel time to establish
<your curl command>
Fill in the two commands from the other hints to complete the solution.
Keep the tunnel running until both test cases have passed —
verify_port_listening requires port 3333 to still be in LISTEN
state when the check fires.
Documentation
Hint 4 - Save the Page with curl
By default curl prints the response body to the terminal. You need
to redirect it to a file at a specific path instead. The curl man page
documents a flag designed exactly for this — it lets you name an output
file directly on the command line without shell redirection.
After running curl, use cat to inspect the saved file and confirm it
contains the HTML served by nginx.
Documentation