The line between service discovery and networking can become surprisingly
blurred in a container context. Service discovery is the process of
automatically providing clients1 of a service with connection information
(normally IP address and port) for an appropriate2 instance of that service. This problem is easy
in a static, single-host system where there is exactly one instance of
everything, but is much more complicated in a distributed system with multiple
instances of services that come and go over time. One way to approach discovery is
for the client simply to request the service by name (e.g.,
api), and do
some magic on the backend to have this resolve to the appropriate location. This
“magic” can take the form of simple ambassador containers, a service discovery
solution such as Consul, a networking solution such as Weave (which includes
service discovery features), or some combination of the previous.
For our purposes, networking can be regarded as the process of connecting containers together. It does not involve plugging in physical Ethernet cables, although it often involves software equivalents such as veth. Container networking starts from the assumption that there is a route available between hosts, whether that route involves traversing the public Internet or just a fast local switch.
So, service discovery allows clients to discover instances, and networking takes care of putting the connections in place. Networking ...