Interworking between containers
Container Service provides an independent IP address that is reachable within the cluster for each container in the cluster. Containers can communicate with each other by using the independent IP addresses instead of being exposed to the host port by means of Network Address Translation (NAT). Therefore, the dependency on the IP address of the host is removed, avoiding port conflict issues among multiple containers when configuring NAT. The following section describes how to realize cross-host container communication under different network models.
In a Virtual Private Cloud (VPC):
VPC helps you build an isolated network environment based on Alibaba Cloud. You can have full control over your own virtual network, including a free IP address range, Classless Inter-Domain Routing (CIDR) block division, and the configurations of route table and gateway. By configuring the VPC route table, Container Service forwards inter-container access requests to the Elastic Compute Service (ECS) instances corresponding to the container IP address range. See as follows.
Start Docker daemon on a cluster node (172.16.1.1) and set the default IP address range of the bridge network to 192.168.1.0/24. Start Docker daemon on another node (172.16.1.2) and set the default IP address range of the bridge network to 192.168.2.0/24. Set the corresponding routing rule in the VRouter route table under the VPC to forward access requests from 192.168.1.0/24 to the node 172.16.1.1. Set a similar routing rule for the other node.
Then, if a container with the IP address 192.168.1.2 on node 1 accesses a container with the IP address 192.168.2.2 on node 2, the access request is forwarded by means of the route table to a corresponding machine. The access request is then forwarded to the bridge of Docker0 according to the routing rule created by Docker. Finally, the request is forwarded to the container with the IP address 192.168.2.2.
Besides, Container Service assigns independent CIDR blocks and route entries for containers in the VPC. This helps avoid conflicting with original VSwitch CIDR block, route table entries, and IP route table on the machine. Otherwise, the access request might not be forwarded to the correct container.
In a classic network:
Docker 1.9 and later versions support a native cross-host container network based on the VXLAN protocol. In a classic network, Container Service creates a network environment for inter-container communication in one cluster based on Docker Overlay Network. The multi-host container network virtualized from the Docker Overlay Network is the same virtualized subnet, so containers can communicate with each other across hosts.
In a multi-container application, link is often used to describe the dependency between containers. For example, WordPress Web service depends on the MySQL database service. Then, when a WordPress container is started, a series of parameters of the MySQL container, including the IP addresses and ports for database connection, can be obtained by using a link.
However, the Docker link only supports container connection on the same host node, while Container Service supports cross-node container connection. When the container IP address is changed, the container alias in the link is also changed. These actions are consistent with those on the link used on a single node.
Access from a container to a virtual machine
Containers in Container Service retain routes for external network access. Therefore, if a container needs to access the services or IP address of a virtual machine, the IP address or domain name of the virtual machine can be used directly.