mesos-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Qian Zhang (JIRA)" <>
Subject [jira] [Commented] (MESOS-8534) Allow nested containers in TaskGroups to have separate network namespaces
Date Fri, 23 Feb 2018 01:03:00 GMT


Qian Zhang commented on MESOS-8534:

[~sagar8192] for the use case that you mentioned in the description, I am a bit confused why
you put the containers binding to the same port (8888) in a pod. I think the principle of
pod is, containers for different purposes (e.g., each of them is serving on a different port)
but sharing the same lifecycle should be put in a pod. So I am wondering if it is possible
to put your containers in different pods or have them bind to different ports?

> Allow nested containers in TaskGroups to have separate network namespaces
> -------------------------------------------------------------------------
>                 Key: MESOS-8534
>                 URL:
>             Project: Mesos
>          Issue Type: Task
>          Components: containerization
>            Reporter: Sagar Sadashiv Patwardhan
>            Priority: Minor
>              Labels: cni
> As per the discussion with [~jieyu] and [~avinash.mesos] , I am going to allow nested
containers in TaskGroups to have separate namespaces. I am also going to retain the existing
functionality, where nested containers can share namespaces with the parent/root container.
> *Use case:* At Yelp, we have this application called seagull that runs multiple tasks
in parallel. It is mainly used for running tests that depend on other containerized internal
microservices. It was developed before mesos had support for docker-executor. So, it uses
a custom executor, which directly talks to docker daemon on the host and run a bunch of service
containers along with the process where tests are executed. Resources for all these containers
are not accounted for in mesos. Clean-up of these containers is also a headache. We have a
tool called docker-reaper that automatically reaps the orphaned containers once the executor
goes away. In addition to that, we also run a few cron jobs that clean-up any leftover containers.
> We are in the process of containerizing the process that runs the tests. We also want
to delegate the responsibility of lifecycle management of docker containers to mesos and
get rid of the custom executor. We looked at a few alternatives to do this and decided to
go with pods because they provide all-or-nothing(atomicity) semantics that we need for our
application. But, we cannot use pods directly because all the containers in a pod have the
same network namespace. The service discovery mechanism requires all the containers to have
separate IPs. All of our microservices bind to 8888 container port, so we will have port collision
unless we are giving separate namespaces to all the containers in a pod.
> *Proposal:* I am planning to allow nested containers to have separate namespaces. If
NetworkInfo protobuf for nested containers is not empty, then we will assign separate mnt
and network namespaces to the nested containers. Otherwise,  they will share the network
and mount namepsaces with the parent/root container.

This message was sent by Atlassian JIRA

View raw message