kubectl port-forwardReach a pod or Service from your laptop
kubectl port-forward opens a local port on your machine and tunnels its connections, through the API server and the node's kubelet, to a port inside a pod. It's how you reach an internal dashboard, a database or one specific pod without exposing anything publicly.
kubectl port-forward (POD | pod/NAME | svc/NAME | deploy/NAME) [LOCAL_PORT:]REMOTE_PORT [...] [--address 127.0.0.1] [-n NS]One api replica returns errors. Talk to that exact pod from your laptop, bypassing the Service and the load balancer.
kubectlThe Kubernetes CLI.
kubectl resolves the target to a single pod (for svc/ or deploy/ it lists the Service's or Deployment's pods and picks one running pod, translating the Service port to that pod's containerPort). It opens a listener on your machine, then POSTs to the pod's portforward subresource and upgrades to a streaming connection (WebSocket in current versions). The API server authorises create on pods/portforward and proxies the stream to the kubelet, which asks the container runtime to connect to the port inside the pod's network namespace. Each local TCP connection becomes a pair of data and error streams over that single tunnel. Only TCP works, not UDP. If the chosen pod dies, the tunnel breaks and kubectl exits with 'lost connection to pod'; it does not fail over to another replica.
LOCAL:REMOTEMap a local port to the pod's port, e.g. 8080:80:REMOTEPick a random free local portpod/ svc/ deploy/Target type; svc and deploy pick one pod--address ADDRLocal listen address(es); default localhost--pod-running-timeoutHow long to wait for a running pod (default 1m)-n NSNamespaceLoad-testing a Service through kubectl port-forward svc/apiAll traffic goes to one pod through the API server, which becomes the bottleneck; you measure the tunnel, not the app.
Test from inside the cluster or through the real Ingress/load balancer--address 0.0.0.0 on a laptop at a caféAnyone on that network can reach your forwarded database or admin UI with your access.
Keep the default localhost bindingUsing port-forward as the way users reach an appIt's a single developer tunnel that breaks on pod restarts and needs cluster credentials.
Expose it with a Service of type LoadBalancer or an Ingress/GatewayPort-forwarding a UDP port (DNS 53/udp)port-forward only carries TCP.
kubectl exec into a pod and use dig there, or run a debug podTry these on a Linux machine of your own. Each task has a hint and a solution.
Write the command to reach port 9090 of the Prometheus Service in namespace monitoring on your local port 19090.
Read this and explain the arrow: you ran 'kubectl port-forward svc/api 8080:80' and got 'Forwarding from 127.0.0.1:8080 -> 8080'.
Practise the 'port already in use' check in the sandbox: start a listener on 8080 with nc, then find which process holds the port.
kubectl port-forwardReach a pod or Service from your laptop
kubectl port-forward opens a local port on your machine and tunnels its connections, through the API server and the node's kubelet, to a port inside a pod. It's how you reach an internal dashboard, a database or one specific pod without exposing anything publicly.
kubectl port-forward (POD | pod/NAME | svc/NAME | deploy/NAME) [LOCAL_PORT:]REMOTE_PORT [...] [--address 127.0.0.1] [-n NS]One api replica returns errors. Talk to that exact pod from your laptop, bypassing the Service and the load balancer.
kubectlThe Kubernetes CLI.
kubectl resolves the target to a single pod (for svc/ or deploy/ it lists the Service's or Deployment's pods and picks one running pod, translating the Service port to that pod's containerPort). It opens a listener on your machine, then POSTs to the pod's portforward subresource and upgrades to a streaming connection (WebSocket in current versions). The API server authorises create on pods/portforward and proxies the stream to the kubelet, which asks the container runtime to connect to the port inside the pod's network namespace. Each local TCP connection becomes a pair of data and error streams over that single tunnel. Only TCP works, not UDP. If the chosen pod dies, the tunnel breaks and kubectl exits with 'lost connection to pod'; it does not fail over to another replica.
LOCAL:REMOTEMap a local port to the pod's port, e.g. 8080:80:REMOTEPick a random free local portpod/ svc/ deploy/Target type; svc and deploy pick one pod--address ADDRLocal listen address(es); default localhost--pod-running-timeoutHow long to wait for a running pod (default 1m)-n NSNamespaceLoad-testing a Service through kubectl port-forward svc/apiAll traffic goes to one pod through the API server, which becomes the bottleneck; you measure the tunnel, not the app.
Test from inside the cluster or through the real Ingress/load balancer--address 0.0.0.0 on a laptop at a caféAnyone on that network can reach your forwarded database or admin UI with your access.
Keep the default localhost bindingUsing port-forward as the way users reach an appIt's a single developer tunnel that breaks on pod restarts and needs cluster credentials.
Expose it with a Service of type LoadBalancer or an Ingress/GatewayPort-forwarding a UDP port (DNS 53/udp)port-forward only carries TCP.
kubectl exec into a pod and use dig there, or run a debug podTry these on a Linux machine of your own. Each task has a hint and a solution.
Write the command to reach port 9090 of the Prometheus Service in namespace monitoring on your local port 19090.
Read this and explain the arrow: you ran 'kubectl port-forward svc/api 8080:80' and got 'Forwarding from 127.0.0.1:8080 -> 8080'.
Practise the 'port already in use' check in the sandbox: start a listener on 8080 with nc, then find which process holds the port.