-
Notifications
You must be signed in to change notification settings - Fork 842
Docker Containerizer IP-per-container tasks are not auto-allocated a Service Port #3636
Comments
Whoops, setting network to HOST seems to have worked. Sorry for the issue flash. |
OK Confirmed that this behavior is definitely happening, regardless of what type of Network is specified as the network type. |
Here's some more info to illustrate the problem:
And the response includes a service port of 10001 (I've trimmed the response to only show important information): This app does specify the ipAddress field:
But now we no longer are allocated a servicePort to map to: Marathon-lb operates on the assumption that all services (even those which are just using vhosts) are mapped to a service port. Since marathon is responsible for allocating the service ports, this bug makes marathon-lb incompatible with ip-per-container tasks. Furthermore, marathon-lb is unable to compensate for this bug without the chance of service port collisions happening. |
I implemented a marathon-lb fix (d2iq-archive/marathon-lb#144) which has now been merged into master - this will allow the LB to utilize IP per container. However, without the fix to this issue in Marathon, the change in the LB is pretty redundant fix - the LB can't do anything without the service port. It is possible to implement a workaround in the LB to auto-assign service ports when they aren't returned by Marathon, but this isn't an ideal workaround because it's only useful when using vhost since the marathon-lb assigned service port will be arbitrarily chosen by the LB and so you can't rely on accessing a specific LB port for your service. |
Trying to understand the ask here. In the case of IP-per-CT it sounds like you want Marathon to allocate a hostPort from resource offers and link that host port to a containerAddress (containerIP:containerPort)? If MarathonLB can already determine which containerIP:containerPort tuples as assigned to a task and use such address for LB (implied by the marathon-lb fix above) then why does Marathon need to provide the hostPort-to-containerAddress linkage? [EDIT] If I'm grok'ing the issue here and this really is a requirement, then we could probably configure the Docker container in BRIDGE mode pretty easily since Docker already understands how to link host ports and container ports. Any container type operating in HOST mode probably needs assistance from an executor/containerizer to proxy network connections. |
With IP per task/container, we don't want a host port - the IP and port of the container is directly exposed and so there is no requirement for a host port. The problem is that in the IP per container app data, Marathon does not return a Service Port - so the LB has to assign it's own service port - which isn't particularly sound - Marathon should really be the one responsible for Service port management, otherwise there are potential clashes between ports assigned by Marathon and Marathon-LB |
@jdef We're not really talking about host or container ports here. Let me rephrase the issue with some context: Currently, all Marathon applications that register with marathon-lb are assigned a service port. Despite the fact that servicePorts are a marathon-lb concept, Marathon is the one that allocates and keeps track of available servicePorts. When launching a ip-per-container application, it is currently impossible to receive a servicePort from Marathon. There are two scenarios that should trigger the allocation of a service port.
The first point is an enhancement request, but not one that this issue is requesting, as it isn't a useful use-case for ip-per-container anyways. Instead, this issue was opened to fix the second point, which is a bug. |
I am trying to deploy the marathon-lb on DCOS cluster to scale some of the applications (internal). I am using overlay network for all the apps (Calico). Based on https://hub.docker.com/r/mesosphere/marathon-lb/ , confirmed that it's possible. Then found this thread which has useful information. Still, I am not able to complete the deployment. I used the JSON config which was downloaded as part of "dcos package install --options=options.json marathon-lb", and edited that to use 'calico-nw', instead of host. I get the following error in logs Is this the correct way? Is there a doc/guide doing this. Thanks. |
@PranjalMishra you should hop on the Calico or DC/OS slack or start a new issue so we can troubleshoot why your system is not working. Those sysctl logs aren't something I've ever seen, so maybe your Additionally, see the above mentioned issue for a small status update on Calico/IP-per-ct + Marathon-LB. Basically, even if you resolve those sysctl issues, Marathon-LB isn't compatible with Marathon's IP-per-ct at the moment. |
@djosborne used the writeup https://www.projectcalico.org/calico-dcos-demo-security-speed-and-no-more-port-forwarding/ (Step 5) |
The However, I've found that this is still not happening with Unified / CNI apps. I've filed a follow up issue to track the issue at #4548 |
@djosborne @jdef , We're running Nuage SDN and it looks like when Marthon IP-Per-Task is invoked, containers are not getting servicePort assigned, and as a result no Marathon-LB load balancing possible. Environment:
|
@djosborne docker containerizer. I am using marathon-1.3.0-1 + Nuage SDN with IP-Per-Task. Marathon LB does not get servicePort passed on, hence no load balancing. |
@djosborne I just upgraded my Marathon to 1.3.5. Re-run Marathon-LB. No dice. Here is the JSON file of the services I want to put behind LB File: zk.kafka.json
Here is the JSON file of the Marathon LB I am deploying: File: marathon-lb.json
Marathon-LB is not getting servicePorts passed along: |
@djosborne would you be able to take a look at my reply above, please? If yes and confirmed, can we re-open the ticket, please? |
@akamalov Mine is working on Marathon 1.3.2. But your issue is different than the original issue here. For your case, I suggest you try the following:
|
Thanks for replying @djosborne
One of the reasons I went with BRIDGE mode on Marathon-LB is to assign an IP address of Nuage to Marathon-LB containers , which completely divorces it from the host. Containers to be load-balanced are also getting their IP off SDN framework. I guess I have to open up a ticket with Marathon-LB. Thanks again. |
I'm launching two near-identical applications, one includes the "ipAddress" field as shown below, the other does not. They are both specifiying VHOSTS.
The one that does not specify the ipAddress field is assigned a servicePort.
The one that does specify the ipAddress field is not assigned a servicePort.
Is there any reason for this difference in behavior? If an app is using IP-per-container and specifies a VHOST, I believe it should still receive a serviceport to map to on the load balancer.
The text was updated successfully, but these errors were encountered: