Around Go: Kubernetes · 3 MIN READ

Service routing: selectors, endpoints and port-forward

Trace a request from a local port through a Service to a ready application endpoint.

A Service object can exist while routing to no useful Pods. Diagnose its selector, selected endpoints, target port and application listener separately. This lesson uses the earlier internal Service go-api on port 80 targeting the Go container port 8080.

Check selector and ready endpoints

A Service selector matches Pod labels; EndpointSlices describe backend addresses and readiness. Deployment existence alone does not prove the Service selected its Pods. Query the named Service because the sample object does not have an app metadata label.

bash

kubectl --context dev-cluster -n go-lab describe service go-api
kubectl --context dev-cluster -n go-lab get pods -l app=go-api --show-labels
kubectl --context dev-cluster -n go-lab get endpointslices \
  -l kubernetes.io/service-name=go-api -o wide

Read the code

Empty endpoints suggest a selector mismatch, missing Pods or readiness problems. Compare targetPort 8080 with the actual Go listener. A listener bound to 127.0.0.1 inside the Pod cannot normally serve traffic arriving at its Pod interface.

Forward one local port and make a bounded request

port-forward supplies a temporary local development path; it is not a public ingress or load test. Bind it to loopback and keep the process running while you use a second terminal to call the local address.

bash

# Terminal 1; stop with Ctrl-C:
kubectl --context dev-cluster -n go-lab port-forward \
  --address 127.0.0.1 service/go-api 8080:80
# Terminal 2:
curl --max-time 5 --fail-with-body http://127.0.0.1:8080/healthz

Read the code

The local 8080 forwards to Service port 80, which resolves to a Pod target. If another local process owns 8080, choose a different local port. The session can end when its selected Pod disappears; it does not create durable routing.

Distinguish application access from a diagnostic tunnel

An in-cluster client in go-lab can normally resolve go-api; a client in another namespace can use go-api.go-lab.svc.cluster.local on a cluster using that DNS suffix. Network policy and DNS configuration still apply. A port-forward does not prove the ordinary in-cluster network route works.

bash

kubectl --context dev-cluster -n go-lab get service go-api -o yaml
kubectl --context dev-cluster -n go-lab get networkpolicy

Read the code

Check Service type, ports and selectors in the first output. No policies in this namespace is not a complete security audit: cluster networking and other policy mechanisms can also affect traffic. Ingress, public TLS and authentication need their own configuration.

TAKE THIS WITH YOU

Trace labels, endpoint readiness, Service ports and the listener as separate links. Port-forward is a useful temporary tunnel, but it cannot validate all normal service-network and public-ingress behavior.

Check your understanding

What does port-forward create in this development example?

Go to the source

Progress stays in this browser. No account needed.