[
https://issues.apache.org/jira/browse/MESOS-4823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15200365#comment-15200365
]
Avinash Sridharan edited comment on MESOS-4823 at 3/17/16 9:08 PM:
-------------------------------------------------------------------
[~lxpollitt] I completely agree with your observation that port mapping is just
one of the ways to expose the service to the external world. If the service
(layer 4 + layer 3) is completely addressable by the underlying CNI network and
port mapping is not required that is perfectly fine. The only point I am trying
to make is there are cases where port translation "might" be required by the
container to make its service accessible, but unfortunately there is no way in
CNI to communicate this information to the underlying plugin and hence we were
thinking of implementing this piece in the isolator itself. It is an opt-in
where the frameworks would specify whether they want port mapping or not.
The idea here is that we should not be breaking the CNI spec, but at the same
time we feel that the spec itself is evolving and we should try to compensate
for the missing pieces.
Would love to schedule a hangout if you would like to discuss further on this
and get some closure as to whether this is an acceptable solution to enable
port mapping in CNI or maybe come up with an alternate solution that does not
touch the CNI isolator.
was (Author: [email protected]):
[~lxpollitt] I completely agree with your observation that port mapping is just
one of the ways to expose the service to the external world. If the service
(layer 4 + layer 3) is completely addressable by the underlying CNI network and
port mapping is not required that is perfectly fine. The only point I am trying
to make is there are cases where port translation "might" be required by the
container to make its service accessible, but unfortunately there is no way in
CNI to communicate this information to the underlying plugin and hence we were
thinking of implementing this piece in the isolator itself. It is an opt-in
where the frameworks would specify whether they want to port mapping or not.
The idea here is that we should not be breaking the CNI spec, but at the same
time we feel that the spec itself evolving and we should try to compensate for
the missing pieces.
Would love to schedule a hangout if you would like to discuss further on this
and get some closure as to whether this is an acceptable solution to enable
port mapping in CNI or maybe come up with an alternate solution that does not
touch the CNI isolator.
> Implement port forwarding in `network/cni` isolator
> ---------------------------------------------------
>
> Key: MESOS-4823
> URL: https://issues.apache.org/jira/browse/MESOS-4823
> Project: Mesos
> Issue Type: Task
> Components: containerization
> Environment: linux
> Reporter: Avinash Sridharan
> Assignee: Avinash Sridharan
> Priority: Critical
> Labels: mesosphere
>
> Most docker and appc images wish to expose ports that micro-services are
> listening on, to the outside world. When containers are running on bridged
> (or ptp) networking this can be achieved by installing port forwarding rules
> on the agent (using iptables). This can be done in the `network/cni`
> isolator.
> The reason we would like this functionality to be implemented in the
> `network/cni` isolator, and not a CNI plugin, is that the specifications
> currently do not support specifying port forwarding rules. Further, to
> install these rules the isolator needs two pieces of information, the exposed
> ports and the IP address associated with the container. Bother are available
> to the isolator.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
