Kube-proxy services range of container ports

[pixie79]

Not sure how this could be done but for our application we could run the same container 10 times on the same minion quite happily using different ports as it is lightweight. To load balance though we would need to map the ports back to appear as one service port. To allow other machines to talk to it easily.

May be it could hang of the container port name and a matching regex on the pod name. So all pods that start Fred- with a port called http would be load balanced by the same service?

[erictune]

The pod template for the pod could specify that the external port can come
from a dynamically allocated range. Then the replication controller or
scheduler can assign a port. This seems related to podTemplates
#170

On Wed, Jul 23, 2014 at 11:30 PM, Mark Olliver [email protected]
wrote:

Not sure how this could be done but for our application we could run the
same container 10 times on the same minion quite happily using different
ports as it is lightweight. To load balance though we would need to map the
ports back to appear as one service port. To allow other machines to talk
to it easily.

May be it could hang of the container port name and a matching regex on
the pod name. So all pods that start Fred- with a port called http would be
load balanced by the same service?

—
Reply to this email directly or view it on GitHub
#597.

[erictune]

Mention #170

[erictune]

This might be a duplicate of #390

[lavalamp]

We're trying very, very hard to avoid dynamically allocated ports.

Since our model is IP-per-pod, this actually is OK and we can co-locate things with conflicting external ports. Unfortunately it's not completely implemented yet and I think they do still conflict. But we don't need dynamic ports to fix it. :)

[smarterclayton]

The conflict right now is (IIRC) assigning service ports and the container ports that are exposed on the host on each minion. The former seems like it's something that should be possible for the consumer to not care about what port the service is exposed on (create service, get back an IP and port to connect to), and the latter is just an artifact of the network configuration on the host and Docker (forcing the ports to be exposed on the container and the host).

Agree that the per pod ports should not be dynamic if we can build non-IaaS network solutions that make IP-per-container usable.

[pixie79]

No I think you have mistaken me, but it might also be my understanding.

For example say I have 4 minions I want to run my same docker image 16 times so 4 copies on each. Is this possible I am happy with them all having the same host and container ports.

The idea then is to run the service lb over the top to ensue requests are distributed among all 16.

[lavalamp]

Yeah, that's the idea. IP per pod, so ports won't conflict.

[ryfow]

Right now, if you specify a pod port with no hostPort value, kubernetes tells docker to default the hostPort to the same number as the containerPort.

I think that if no hostPort is specified, there should be no host ports allocated. I believe services are using the pod IP and Container Port anyway, so hostPorts shouldn't be necessary.

[thockin]

I agree with this. I want to change the ports API and semantics.

On Fri, Jul 25, 2014 at 8:03 AM, Ryan Fowler [email protected]
wrote:

Right now, if you don't specify a pod port with no hostPort value,
kubernetes tells docker to default the hostPort to the same number as the
containerPort.

I think that if no hostPort is specified, there should be no host ports
allocated. I believe services are using the pod IP and Container Port
anyway, so hostPorts shouldn't be necessary.

Reply to this email directly or view it on GitHub
#597 (comment)
.

[thockin]

This should be fixed for some time now.