All Products
Document Center

Service discovery

Last Updated: Feb 14, 2018

Principles of service discovery in a cluster

The service discovery in a cluster can be implemented by using the routing mesh or the built-in DNS service:

  • By using the routing mesh: The routing mesh combines service discovery with Server Load Balancer. For more information, see Routing and Server Load Balancer between services in a cluster.

  • By using DNS: With the built-in DNS+VIP+IPVS mechanism, the cluster allocates a VIP for each started service and resolves the service name as the VIP in the DNS. Requests sent to this VIP will be automatically distributed to multiple active tasks (corresponds to containers) under the service.

For this scenario, you can consider implementing service discovery by using the built-in DNS service, without exposing any node ports or joining the ingress network.

Swarm mode provides the DNS-based service discovery mechanism. Note that the DNS server here is also distributed and every host has a DNS server. The manager will allocate a VIP (virtual IP address) for this service and establish a mapping record between the VIP and the service name in the DNS. Corresponding iptables and IPVS will be configured in the network sandbox of every container. In a network, a corresponding iptables and IPVS rule will be added whenever a service is added, which makes the service become accessible across the network.

Service Discovery Principle

Application 1 and application 2 join the same network my-net. The client service in the my-net network initiates an access request to a service of application 2. The service of application 2 can be accessed by using the service name or VIP. To access the service by using the service name, the container will access the DNS service embedded in the Docker Engine to retrieve the VIP. Then, the VIP request is loaded to a specific container under the service by using Iptables and IPVS.

Service discovery approaches

In a swarm mode cluster, Container Service provides multiple approaches for discovering services in a cluster. We recommend that you use service name and container name for service discovery. The DNS service embedded in the Docker Engine will resolve the service name and container name into the correct IP address for service discovery.

Note: The applications must join the same network to implement the mutual discovery between services.

Service discovery by container name

Container Service not only supports service access by container IP address, but also supports service access by names of other containers in the network. In this example, you can access the service by the container name wordpress_web.1.xxxxxxxxxxxxxxxxxx in the container wordpress_mysql.1.xxxxxxxxxxxxxxxxxxx.


If the container_name is not specified in the orchestration file, the default naming rules are as follows:

  • Compose V1/V2: The default container name is {project-name}_{service-name}_{container-index}. You can access a container of another service by using the container name after you connect to the web terminal.
  • Compose V3: The default container name is {project-name}_{service-name}.{container-index}.{random character}. You can view the container in the Container Service console.


Service discovery by service name

Swarm mode cluster supports service discovery by service name. The default format of a service name is {project-name}_{service-name}. The built-in DNS service will resolve the service name into a correct IP address (VIP) for discovery.