For marathon health checks, the current state seems to be this: there's an implicit assumption in marathon that the order of networks declared in the app spec completely aligns with the order of the networkinfos (ip addresses) reported by mesos to marathon for some task; given that, the health checker code leverages an "effectivePort" computation that simply picks the first IP address (which presumably maps to the first declared app network). this means that marathon health checks are only executable against container ports associated with the first declared app network – (this is from a code review vs. empirical testing).
If this *is the case* then either we should:
(a) document it clearly for people, or else;
(b) fix it so that marathon health checks can access ports on non-primary container networks