Port Forwarding Patterns

Kubernetes Port Forwarding Patterns

You're inside a dev cluster, access to the network is restricted, and the service you just deployed is acting up. There’s no LoadBalancer, no ingress controller in place, and opening up a port is not an option because the network team is either slow or says no.

This is where kubectl port-forward unblocks you.

Here are four port forwarding patterns you’ll actually use.

1. Port Forward to Pod

Quickest way to access a container.

It sets up a direct TCP tunnel from your machine to the container port. No Service required.

Ideal for quick API testing or debugging a one-off container without having to figure out DNS or labels.

kubectl port-forward pod/k8s-pod 8080:80

2. Port Forward to Service

Ideal when multiple pods are behind a service.

Built-in load balancing (round-robin), session affinity if configured, and the ability to test service level behavior without exposing it externally.

kubectl port-forward svc/k8s-service 8080:80

Note: Even though the pod port behind the service is :50 (as shown in the image), the kubectl port-forward command is forwarding to the Service's target port, which is commonly exposed as :80

3. Port Forward via Deployment

Often, you just deployed something via a Helm chart or GitOps pipeline, and you don’t want to manually inspect pod names.

If you know the Deployment name, this shortcut selects one of its pods using label selectors.

kubectl port-forward deploy/k8s-deploy 8080:80

4. Port Forward from Another Cluster Context

This one comes up when you're managing multiple clusters.

Maybe a dev cluster in EKS and a staging cluster in GKE and your local kubeconfig has contexts for each.

Also relevant when you have a bastion host in place and you’ve configured ProxyCommand in your kubeconfig for that cluster.

Forwarding just works over the jump host without needing to expose anything externally.

kubectl --context=other-cluster port-forward pod/k8s-pod 8080:80

kubectl port-forward provides a practical way to debug or test workloads without creating new attack surfaces.

Give it a try next time you hit a service that’s live inside the cluster but invisible from the outside.