CertGrid CertGrid
Hands-on Lab·Certified Kubernetes Application Developer

kubectl port-forward and proxy

`kubectl port-forward` tunnels a local port to something in the cluster through the API server, which means it works on any Service, needs no NodePort and no Ingress, and reaches things that are not exposed at all. This shows it against a Service, a Pod and a Deployment, adds `kubectl proxy` for the API itself, and contrasts all of it with a NodePort.

Services and Networking Guide 38 of 44 Beginner

Written against the versions above. A forward to `svc/name` resolves the Service to ONE of its Pods and tunnels to that Pod for the lifetime of the connection. It does not load-balance, and if that Pod is deleted the forward dies rather than moving - which is why a forward that stops working during a rollout is expected behaviour.

The forwards run on cka1001 and reach a two-replica Deployment on the workers. The final NodePort check is made against cka1001-node01.
Server NameIP AddressOSRolesCPURAMHDD
CKA1001192.168.0.175Ubuntu 26.04 LTSControl Plane Node2 Core4 GB50 GB
CKA1001-NODE01192.168.0.176Ubuntu 26.04 LTSWorker Node2 Core4 GB50 GB
CKA1001-NODE02192.168.0.177Ubuntu 26.04 LTSWorker Node2 Core4 GB50 GB
CKA1001-NODE03192.168.0.178Ubuntu 26.04 LTSWorker Node2 Core4 GB50 GB

Before you start

  1. Something to reach

  2. port-forward to a Service

  3. To a Pod, and to a Deployment

  4. The API itself, through a proxy

  5. What port-forward is not

Official sources