Red Hat Bugzilla – Bug 1461477
Port-forwarding requires services bound to 127.0.0.1 or 0.0.0.0/0 (*)
Last modified: 2017-06-15 11:43:02 EDT
Description of problem:
The OpenShift documentation for port-fowarding does not note the limitation that a service within a pod must listen to 0.0.0.0/0 (or at least 'lo' or 127.0.0.1) in order for port-forwarding to function properly. Pods, services, and routes are not affected.
Version-Release number of selected component (if applicable):
Although it is assumed services should listen to all interfaces, many applications may be configured to listen to interfaces by name (eth0, for example). It is suggested in the Kubernetes API that 0.0.0.0/0 must be used but this is not a requirement for pods, services, and routes to function.
Launch a service within a container that takes a named interface as an argument for an address to bind a port to (e.g. eth0)
This is seen when using `oc port-forward` when a container's exposed service does not listen to all interfaces:
[user@host ~]$ oc port-forward example-pod 5000:8001
Forwarding from 127.0.0.1:5000 -> 8001
Handling connection for 5000
E0612 13:08:03.098455 15544 portforward.go:329] an error occurred forwarding 5000 -> 8001: error forwarding port 8001 to pod example-pod, uid : exit status 1: 2017/06/12 13:08:03 socat E connect(3, AF=2 127.0.0.1:8001, 16): Connection refused
Within the pod/container, the 'curl' command can be used to show the service is listening to eth0 but not lo.
[user@host ~]$ oc rsh example-pod
sh-4.2$ curl -ik --head https://10.1.2.34:8001/path/to/service
HTTP/1.1 200 OK
Date: Wed, 14 Jun 2017 13:51:40 GMT
sh-4.2$ curl -ik --head https://127.0.0.1:8001/path/to/service
curl: (7) Failed connect to 127.0.0.1:8001; Connection refused
The issue was documented in Kubernetes upstream at
A proposal to add an address flag to kubectl port-forward was submitted here:
A patch to add the address flag to kubectl port-forward was submitted here:
I don't see this being added to OpenShift until it is available in Kubernetes upstream. In the meantime I am working around the issue by running netcat inside the container to forward connections as follows:
while [ 1 ]; do
nc -l 127.0.0.1 <service_port> -c 'nc <pod_ip> <service_port>'
It's not an elegant or a robust solution, just a work-around for special use cases where port forwarding is required and the service within the container cannot be bound to 0.0.0.0/0 and does not support multiple bind interfaces.