• TechOps Examples
  • Posts
  • How to Use Kubernetes Port Forwarding to Access Applications in a Cluster

How to Use Kubernetes Port Forwarding to Access Applications in a Cluster

Author

Govardhana M K
January 24, 2026

In partnership with

TechOps Examples

Hey — It's Govardhana MK 👋

Welcome to another technical edition.

Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.

Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities, and articles.

👋 👋 A big thank you to today's sponsor WISPR FLOW

Dictate prompts and tag files automatically

Stop typing reproductions and start vibing code. Wispr Flow captures your spoken debugging flow and turns it into structured bug reports, acceptance tests, and PR descriptions. Say a file name or variable out loud and Flow preserves it exactly, tags the correct file, and keeps inline code readable. Use voice to create Cursor and Warp prompts, call out a variable like user_id, and get copy you can paste straight into an issue or PR. The result is faster triage and fewer context gaps between engineers and QA. Learn how developers use voice-first workflows in our Vibe Coding article at wisprflow.ai. Try Wispr Flow for engineers.

👀 Remote Jobs

Powered by: Jobsurface.com

📚️ Resources

Looking to promote your company, product, service, or event to 59,000+ Cloud Native Professionals? Let's work together. Advertise With Us

🧠 DEEP DIVE USE CASE

How to Use Kubernetes Port Forwarding to Access Applications in a Cluster

If you ever…

  • ran kubectl get pods and saw everything Running, but had no URL to actually open the app

  • needed to check a /health, /metrics, or admin endpoint that exists only inside the cluster

  • were debugging a prod issue and exposing a port externally was not an option

Port forwarding is the way to handle it.

Before getting into today’s context, you need to understand a few Kubernetes basics.

How kubectl Works

Every interaction you make with a Kubernetes cluster starts with kubectl, but kubectl itself never talks to pods directly.

  • kubectl is just a client that reads your kubeconfig and cluster context

  • All requests go to the Kubernetes API Server, not to nodes or pods

  • The API Server authenticates, authorizes, and validates every request

  • Cluster state is stored in etcd and accessed only by the API Server

  • Pods and other resources are always reached through the API Server

Because kubectl never connects to pods directly, Kubernetes can safely proxy traffic to workloads without exposing cluster networking.

What is kubectl port-forward

kubectl port-forward lets you access an application running inside a Kubernetes cluster by mapping a local port on your machine to a port on a pod or service.

This means:

  • No pod IPs are exposed

  • No node ports are opened

As long as you have API Server access and the required RBAC permissions, you can reach an internal application safely and temporarily using your local localhost port.

It is commonly used for debugging, inspecting internal APIs, and accessing admin or health endpoints safely and temporarily.

With this technical understanding, let’s look at the most common Kubernetes port forward patterns you will see in real-world environments.

  1. Port forward to a pod

  2. Port forward to a service

  3. Port forward via a deployment

  4. Remote port forward using another cluster context

🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)

Upgrade to Paid to read the rest.

Become a paying subscriber to get access to this post and other subscriber-only content.

Already a paying subscriber? Sign In.

Paid subscriptions get you:

  • • Access to archive of 250+ use cases
  • • Deep Dive use case editions (Thursdays and Saturdays)
  • • Access to Private Discord Community
  • • Invitations to monthly Zoom calls for use case discussions and industry leaders meetups
  • • Quarterly 1:1 'Ask Me Anything' power session