This is a cache of https://docs.openshift.com/container-platform/3.3/dev_guide/port_forwarding.html. It is a snapshot of the page at 2024-11-26T04:22:14.757+0000.
Port Forwarding | Developer Guide | OpenShift Container Platform 3.3
    OpenShift docs are moving and will soon only be available at docs.redhat.com, the home of all Red Hat product documentation. Explore the new docs experience today.
  1. Documentation
    2. history
×

Port Forwarding

Overview

You can use the cli to forward one or more local ports to a pod. This allows you to listen on a given or random port locally, and have data forwarded to and from given ports in the pod.

Basic Usage

Support for port forwarding is built into the cli:

$ oc port-forward <pod> [<local_port>:]<remote_port> [...[<local_port_n>:]<remote_port_n>]

The cli listens on each local port specified by the user, forwarding via the protocol described below.

Ports may be specified using the following formats:

5000

The client listens on port 5000 locally and forwards to 5000 in the pod.
6000:5000

The client listens on port 6000 locally and forwards to 5000 in the pod.
:5000 or 0:5000

The client selects a free local port and forwards to 5000 in the pod.

For example, to listen on ports 5000 and 6000 locally and forward data to and from ports 5000 and 6000 in the pod, run:

$ oc port-forward <pod> 5000 6000

To listen on port 8888 locally and forward to 5000 in the pod, run:

$ oc port-forward <pod> 8888:5000

To listen on a free port locally and forward to 5000 in the pod, run:

$ oc port-forward <pod> :5000

Or, alternatively:

$ oc port-forward <pod> 0:5000

Protocol

clients initiate port forwarding to a pod by issuing a request to the Kubernetes API server:

/proxy/minions/<node_name>/portForward/<namespace>/<pod>

In the above URL:

  • <node_name> is the FQDN of the node.

  • <namespace> is the namespace of the target pod.

  • <pod> is the name of the target pod.

For example:

/proxy/minions/node123.openshift.com/portForward/myns/mypod

After sending a port forward request to the API server, the client upgrades the connection to one that supports multiplexed streams; the current implementation uses SPDY.

The client creates a stream with the port header containing the target port in the pod. All data written to the stream is delivered via the Kubelet to the target pod and port. Similarly, all data sent from the pod for that forwarded connection is delivered back to the same stream in the client.

The client closes all streams, the upgraded connection, and the underlying connection when it is finished with the port forwarding request.

Administrators can see the Architecture guide for more information.