Details
Major Description
Design doc at https://docs.google.com/document/d/1tpnjfHsa5Joka23CqgGppqnK0jODcElBvTFUBBO-A38/edit?usp=sharing
Mesos enables flexible deployment of tasks in a shared cluster. A task may run on any slave and even move between slaves based on resource availability, framework shares, slave failures, and other constraints. To make the most of this flexibility, we need an automatic way to discover where tasks are and how to connect to the services they provide. To address this need, a number of service discovery systems have been proposed, based on proxies, DNS, or consistent stores such as Zookeeper and etcd.
Any service discovery system needs to draw information about currently running tasks, their location, and their configuration parameters (IP address, ports, etc). In a Mesos cluster with multiple frameworks, the only authoritative source of information about running tasks is the master itself. In order to automatically manage the service discovery system, the task information available in the master should include service discovery preferences and parameters.
If service discovery information is not available in the Mesos master, Mesos users will likely have to build auxiliary systems that gather and serve this information. Keeping the information in such auxiliary systems consistent with the task information in the master will only cause complications in the long term. It is best to store service discovery information along with all the other task information in the Mesos master.