WO2018095138A1 - 容器的部署方法、服务间的通信方法及相关装置 - Google Patents
容器的部署方法、服务间的通信方法及相关装置 Download PDFInfo
- Publication number
- WO2018095138A1 WO2018095138A1 PCT/CN2017/104108 CN2017104108W WO2018095138A1 WO 2018095138 A1 WO2018095138 A1 WO 2018095138A1 CN 2017104108 W CN2017104108 W CN 2017104108W WO 2018095138 A1 WO2018095138 A1 WO 2018095138A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- container
- service
- namespace
- ipc
- network
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 77
- 238000004891 communication Methods 0.000 title claims abstract description 74
- 238000012545 processing Methods 0.000 claims description 12
- 238000002955 isolation Methods 0.000 abstract description 24
- 238000005516 engineering process Methods 0.000 description 12
- 238000010586 diagram Methods 0.000 description 10
- 230000006870 function Effects 0.000 description 6
- 230000008569 process Effects 0.000 description 5
- 239000007787 solid Substances 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 238000011161 development Methods 0.000 description 3
- 230000008520 organization Effects 0.000 description 3
- 101100513046 Neurospora crassa (strain ATCC 24698 / 74-OR23-1A / CBS 708.71 / DSM 1257 / FGSC 987) eth-1 gene Proteins 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 230000006399 behavior Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
- G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
- G06F9/5055—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering software capabilities, i.e. software resources associated or available to the machine
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5061—Partitioning or combining of resources
- G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/547—Remote procedure calls [RPC]; Web services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
- H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
- H04L41/5054—Automatic deployment of services triggered by the service manager, e.g. service implementation by automatic configuration of network components
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/12—Avoiding congestion; Recovering from congestion
- H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0272—Virtual private networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45595—Network integration; Enabling network access in virtual machine instances
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
- H04L12/5601—Transfer mode dependent, e.g. ATM
- H04L2012/5614—User Network Interface
- H04L2012/5618—Bridges, gateways [GW] or interworking units [IWU]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
Definitions
- the present invention relates to the field of virtualization technologies, and in particular, to a method for deploying a container, a method for communicating between services, and related devices.
- Docker container technology is a lightweight operating system virtualization technology, although the containers on the same host (physical or virtual) share the operating system kernel, but the resources used between different containers (such as CPU, Memory, etc.) They are isolated from each other.
- the isolation between containers is generally achieved by the namespace technology provided by the Linux kernel.
- the Linux kernel provides host name, inter-process communication (IPC), network, mount, and user isolation through namespace technology.
- the docker container engine when the docker container engine receives the container deployment and deploys the container, it creates a bridge named docker0 on the host to provide data exchange services for all containers, and for each container. Establish a separate network namespace (net namespace), then establish a network interface (eth) in the network namespace of each container, and finally through the virtual network device (veth pair) technology (with two ends, spanning The network namespace, similar to the pipeline, allows the container's network interface to communicate with the docker0 bridge, as shown in Figure 1a.
- the docker0 bridge can provide network data exchange functions for different containers on the same host, and can also send data packets in the container to the user-specified overlay network for communication across the host nodes.
- micro-service architecture has emerged.
- the overall idea of the microservice architecture is to decompose the application and divide the traditional single application into multiple fine-grained services, which reduces the coupling of the system and improves the flexibility of the system.
- Microservices provide the ultimate value to users through coordination.
- the microservices architecture divides the system into a large number of independent services, each of which is served by multiple specific service instances, so the traffic between services will be larger and the communication will be more frequent than the traditional software architecture.
- the communication method between the service and the service needs to be as fast as possible.
- a service consumer application referred to as SC App
- a load balance (LB) module are deployed in the same docker container.
- the LB module communicates with the service provider application (SP App) to be accessed by the inter-container network, that is, the LB module sends the data of the SC App to the host through the virtual network interface eth0 of the container to which the SC App belongs.
- SP App service provider application
- the docker0 bridge (docker0 bridge), through which the SC App data is forwarded to the virtual network interface eth1 of the container to which the SP App belongs.
- the access between the containers on the same host needs to pass through the virtual network interface eth0 to the bridge docker0 bridge, and then through the bridge docker0 bridge to the virtual network interface eth1 such a network path, in the middle requires data packaging, routing, etc.
- the link layer and network layer operation there is room for optimization in data communication speed.
- the container to be communicated can be placed in the same IPC namespace to make the container between the containers. Communication is through IPC, as shown in Figure 1c.
- this solution can enable high-speed communication between different containers through IPC, it also enables IPC communication for containers that do not need to communicate. For example, container B needs to access container A, while container C also needs to access container A, but container B and container C do not need data communication.
- This scheme makes container B and container C also run in the same IPC namespace, thus destroying The isolation between the container B and the container C. Therefore, if the same container needs to be accessed by multiple other containers, using this scheme will destroy the isolation between all containers.
- the present application provides a container deployment method, a communication method between services, and related devices, which can improve the access speed between containers while ensuring isolation between containers on the same host.
- the first aspect of the present application provides a method for deploying a container, which is applied to a network device, where the network device can refer to any physical machine or virtual machine in the network.
- the network device creates a corresponding container for the first service by deploying the container deployment message and deploys the first service; the container deployment message includes the container mirroring information and the association information of the container, and the corresponding container is created by using the container mirroring information.
- the operating parameter of the container is a parameter of the first network namespace, so that the first load balancing container shares the first network namespace at runtime; and by creating a loopback interface in the first network namespace, so that The first load balancing container and the first service container are capable of communicating through the loopback interface.
- the network device determines, according to the association information of the container, that the container of the second service associated with the container of the first service exists on the network device, setting a startup parameter of the first load balancing container to a second The parameter of the IPC namespace; the second IPC namespace is the IPC namespace corresponding to the container of the second service; thus, the first load balancing container can pass the IPC interface of the second IPC namespace after being started.
- the container of the second service communicates.
- the network device in the first network namespace may be used because the first load balancing container shares the first network namespace corresponding to the container of the first service at runtime; therefore, the first load balancing container runs
- the load balancing module can be bound to provide a load balancing service on the loopback interface established in the first network namespace; except for the container of the first service corresponding to the first load balancing container, other containers cannot pass the loopback interface. Access to the load balancing container ensures isolation between containers on the same host.
- the startup parameter of the first load balancing container is set to be the first
- the parameter of the second IPC namespace corresponding to the container of the second service enables the first load balancing container to access the container of the second service through the IPC interface of the second IPC namespace when starting, thereby ensuring the same host Based on the isolation between the containers on the top, the access speed between the containers is improved.
- the network device determines, according to the association information of the container, that the container associated with the container of the first service does not exist on the network device, setting the first load balancing container
- the startup parameter is a parameter of the third IPC namespace
- the third IPC namespace is an independent IPC namespace, which is different from the foregoing first IPC namespace and the second IPC namespace.
- a separate IPC namespace is configured for the first load balancing container to ensure isolation between the containers.
- a bridge is created for the network device by starting the container engine, and the bridge is used to provide a data exchange service.
- the first network name corresponding to the container that created the first service is empty
- a virtual network device is created in the first network namespace, and the virtual network device can be understood as a virtual network card, and the virtual network device is connected to the bridge to enable the first service.
- the container communicates with a container of other services than the first network namespace.
- the network device sends the service address corresponding to the first service to the service registration center; the service address corresponding to the first service includes the network of the virtual network device. Interface address and IPC interface address of the first IPC namespace. Therefore, the service address corresponding to all the deployed services can be queried by accessing the service registration center, and the corresponding service can be accessed through the queried service address.
- the second aspect of the present application provides a communication method between services, which is applied to the network device provided by the first aspect of the present application, wherein the container of the second service has been created and operated on the network device, and the corresponding second load balancing is performed.
- a container the second service container has a corresponding second network namespace and a second IPC namespace; when the first service container and the corresponding first load balancing container are created; the container corresponding to the first service is created a network namespace and a first inter-process communication IPC namespace, and setting a running parameter of the first load balancing container as a parameter of the first network namespace, and creating a loopback interface in the first network namespace, and
- the startup parameter of the first load balancing container is set to a parameter of the second IPC namespace, wherein the parameter of the second IPC namespace is different from the parameter of the first IPC namespace.
- the communication method between the services includes:
- the container of the first service sends a service access request to the first load balancing container through the loopback interface created in the first network namespace to access the container of the second service.
- the first load balancing container acquires a service address corresponding to the container of the second service according to the service access request, wherein the first load balancing container can be found by accessing the service address recorded in the service registration center to access the second service.
- the service address corresponding to the container of the second service includes a network interface address of the second network namespace corresponding to the container of the second service and an IPC interface address of the second IPC namespace.
- the first load balancing container can access the container of the second service through the IPC interface address of the second IPC namespace.
- the network device in the first network namespace may be used because the first load balancing container shares the first network namespace corresponding to the container of the first service at runtime; therefore, the first load balancing container runs
- the load balancing module can be bound to provide a load balancing service on the loopback interface established in the first network namespace; except for the container of the first service corresponding to the first load balancing container, other containers cannot pass the loopback interface. Access the load balancing container. Therefore, under the premise of ensuring the isolation between the containers on the same host, when the container of the first service is deployed, the startup parameter of the first load balancing container is set to correspond to the container of the second service.
- the first load balancing container can access the container of the second service through the IPC interface address of the second IPC namespace when starting, thereby ensuring the container on the same host On the basis of isolation, the access speed between containers is improved.
- a third aspect of the present application provides a container deployment apparatus, the container deployment apparatus comprising at least one unit for performing the method of deploying the container provided in the first aspect or any one of the first aspects.
- a fourth aspect of the present application provides a communication device between services, the communication device of the service comprising at least one of a communication method for performing inter-service provided in the second aspect or any one of the second aspects unit.
- a fifth aspect of the present application provides a storage medium storing program code, when the program code is executed by a network device, performing the container provided by the first aspect or any one of the implementation manners of the first aspect Deployment method.
- the storage medium includes, but is not limited to, a flash memory (English: flash memory), a hard disk (HDD) or a solid state drive (SSD).
- a storage medium in which a program code is stored, the program code When the network device is operated, the communication method between the services provided by the second aspect or any one of the second aspects is performed.
- the storage medium includes, but is not limited to, a flash memory, a hard disk or a solid state disk.
- FIG. 1a is a schematic structural diagram of a container deployment solution provided by the present application.
- FIG. 1b is another schematic structural diagram of a container deployment solution provided by the present application.
- FIG. 1c is another schematic structural diagram of a container deployment solution provided by the present application.
- FIG. 2 is a schematic structural diagram of a microservice deployment system provided by the present application.
- FIG. 3 is another schematic structural diagram of a container deployment solution provided by the present application.
- FIG. 4 is a schematic structural diagram of a network device provided by the present application.
- FIG. 5 is a schematic flow chart of a method for deploying a container provided by the present application.
- FIG. 6 is a schematic flowchart of a communication method between services provided by the present application.
- Figure 7 is a schematic structural view of a container deployment device provided by the present application.
- FIG. 8 is a schematic structural diagram of a communication device between services provided by the present application.
- FIG. 2 is a schematic structural diagram of a docker container-based microservice deployment system provided by the present application.
- the deployment system includes a management node, a task node, and a service registry.
- the management node may receive the container deployment message sent by the service personnel, and schedule the container to run on a task node.
- the task node here may refer to any physical machine PM or virtual machine VM in the network.
- the container management module runs on the task node.
- it can be a docker container engine, which can receive instructions from the management node and start the container on the task node according to the instruction.
- the application running in the container needs to provide services to the external service, it needs to register the service address with the service registry. Therefore, after the application container (App Container) is launched, the service access address of the application in the container is sent to the service instance registration message.
- the service registry registers a service instance, and the server instance registration message includes the service name and the service instance address.
- the application 1 in FIG. 2 is deployed in a container. If the application 1 needs to provide services externally, it needs to register the service address with the service registration center, that is, send the service instance registration message to the service registration center of the service access address of the application 1 in the container. Go to the registration service instance.
- Application 2 is similar to the deployment of Application 1, and will not be described here.
- Each application provides two service addresses (such as http://container_ip:8080) and IPC message queue name (ContainerName_IPC), that is, after each container is started, it can be externally passed through the network (for example, http://container_ip: 8080) and IPC message queue name (ContainerName_IPC) access the services provided by the container.
- the service registry maintains the available instance address table of all the services in the deployment system by receiving and saving the service instance registration information.
- the structure of a service instance address table in the deployment system can be as shown in Table 1 below:
- the service name is the type of service
- the instance address table is a list of all container instance access addresses of a service type.
- the service registration center provides the query function of the service instance address.
- the external service instance query message (the service name is included in the message) can be used to obtain the instance access address of the corresponding service.
- Each container that deploys an application has a corresponding load balancing container (LB container) on the same task node to provide service access.
- the load balancing 1 in FIG. 2 corresponds to the application 1 for providing the service access function for the application 1.
- the load balancing 1 and the application 1 are deployed in different containers, and the two containers share one network namespace.
- Load balancing 2 is similar to the deployment of load balancing 1. It is not mentioned here.
- the load balancing container works on the loopback interface, and the application container can perform high-speed data communication with the load balancing container through the loopback interface. When the application container accesses the service, it sends a service access request to the load balancing container.
- the request contains the service name to be accessed and the specific service interface (the interface providing the specific function, similar to the function interface), such as http://127.0 .0.1:8000/ServiceA/GetProductInfo?
- the load balancing container obtains all service instance addresses of a service by sending a service instance query message to the service registry.
- the service registration center may also automatically identify the task node where the load balancing container that sends the query request is located, and return the IPC address of the service instance on the same task node to the load balancing container to the load according to the task node where the load balancing container is located. Balance the container.
- the application container When the application container wants to access the service, it selects a service instance address to access according to a certain load balancing policy.
- a service instance address For the application container wants to access the service, it selects a service instance address to access according to a certain load balancing policy.
- the IPC address fails to access, the service instance of other network interfaces is accessed through the rotation scheduling policy.
- Linux supports the Loopback Interface, which allows clients and server programs running on the same host to communicate over TCP/IP.
- Class A network 127 is reserved for the loopback interface. Normally, most systems assign the IP address 127.0.0.1 to this interface.
- An IP packet passed to the loopback interface is copied directly from the transmit buffer to the receive buffer during processing, eliminating the need for operation at the data link layer and the physical layer. Loopback interfaces can only be accessed within the same network namespace and cannot be accessed externally.
- Interprocess Communication IPC is a technology provided by the operating system for fast communication between different processes. Compared with network communication, IPC usually ends up with direct memory copy between processes, eliminating the need for network protocol stack packet unpacking, route query, rule matching, link transmission, etc., which has a very large speed advantage over network communication.
- Common IPC technologies include shared memory, IPC message queues, and system V/POSIX pipes.
- the server creates an IPC channel, and the client and the server exchange data through the IPC channel.
- inter-process communication within a container actually has interprocess communication in the same inter-process communication namespace (IPC namespace), so a unique identifier is needed to distinguish.
- IPC namespace inter-process communication namespace
- Applying for an IPC resource applies for such a globally unique 32-bit ID, so the IPC namespace actually contains the system IPC identifier and the file system that implements the POSIX message queue. Processes under the same IPC namespace are visible to each other, while processes under other IPC namespaces are invisible to each other.
- the container deployment solution provided by the present application is A schematic diagram of the structure.
- an application container (a container in which the application 1 or the application 2 is deployed) runs an application written by a user to provide external services.
- the load balancing container (the container with load balancing 1 or load balancing 2 deployed in the figure) is a standard container provided by the system. It works in the loopback interface (lo in the figure) to receive the service access request of the application container, and is responsible for registering from the service. The center obtains the access address of the service and forwards the service access request of the application container to the selected service instance container through a certain load balancing policy to obtain the service result and returns it to the application container.
- the application container and its corresponding load balancing container share the same network namespace.
- the virtual network interface is a standard virtual network device (which can be considered as a network card).
- the container of application 1 and the container of application 2 shown in FIG. 3 can pass.
- the virtual network interface in the respective network namespace communicates with the container outside the network namespace, and the container in the same network namespace can also be used for fast data communication through the loopback interface (lo) (the network data will be directly in memory).
- the container (process) that is not in the same network namespace cannot access the loopback interface lo in the network namespace, and can only perform standard network data communication through the virtual network interface.
- the application container runs in a separate IPC namespace, so users don't have to worry about the impact of other containers when writing applications, leaving isolation between applications.
- the IPC namespace of the load balancing container corresponding to the container to be deployed is set to the container that needs to be accessed.
- the IPC namespace such that the load balancing container corresponding to the container to be deployed can perform high-speed IPC communication with the container that needs to be accessed, but does not destroy the container to be deployed and the container that needs to be accessed (application 1 in the figure)
- the isolation between the container and the container of application 2 while the standard load balancing container is provided by the system, the behavior is fully controllable, and the shared IPC namespace does not have security and isolation effects on the application.
- the task node in FIG. 3 can be implemented by the network device 200 in FIG. 4.
- the organization structure of the network device 200 is as shown in FIG. 4, and includes a processor 202, a memory 204, and a transceiver 206, and can also include a bus 208.
- the processor 202, the memory 204, and the transceiver 206 can implement communication connection with each other through the bus 208, and can also implement communication by other means such as wireless transmission.
- the memory 204 may include a volatile memory (English: volatile memory), such as random-access memory (English: random-access memory, abbreviation: RAM); the memory may also include non-volatile memory (English: non-volatile memory) For example, read-only memory (English: read-only memory, abbreviation: ROM), flash memory (English: flash memory), hard disk (English: hard disk drive, abbreviation: HDD) or solid state drive (English: solid state drive, Abbreviation: SSD); the memory 204 may also include a combination of the above types of memory.
- the program code for implementing the deployment method of the container provided in FIG. 5 of the present application is saved in the memory 204 and executed by the processor 202.
- Network device 200 communicates with other devices through transceiver 206.
- the processor 202 can be a central processing unit (CPU).
- the transceiver 206 is configured to receive a container deployment message, where the container deployment message includes container image information and associated information of the container.
- the processor 202 is configured to create a container of the first service according to the container image information, and a first network namespace corresponding to the container that creates the first service and a first inter-process communication IPC namespace;
- the startup parameter is used by the first load balancing container to pass the IPC interface of the second IPC namespace after startup Communicating with the container of the second service, the parameters of the second IPC namespace and the parameters of the first IPC namespace are different.
- the network device in the first network namespace may be used because the first load balancing container shares the first network namespace corresponding to the container of the first service at runtime; therefore, the first load balancing container runs
- the load balancing module can be bound to provide a load balancing service on the loopback interface established in the first network namespace; except for the container of the first service corresponding to the first load balancing container, other containers cannot pass the loopback interface. Access to the load balancing container ensures isolation between containers on the same host.
- the startup parameter of the first load balancing container is set to The parameter of the second IPC namespace corresponding to the container of the second service, so that the first load balancing container can access the container of the second service through the IPC interface of the second IPC namespace when starting, thereby ensuring the same sink Based on the isolation between the containers on the host, the access speed between the containers is improved.
- processor 202 is further configured to:
- the processor 202 the network device 200 is configured with a bridge, the bridge is used to provide a data exchange service, and the processor 202 is configured to create a corresponding container of the first service.
- the processor 202 is further configured to:
- Creating a virtual network device in the first network namespace the virtual network device being configured to connect with the bridge, so that the container of the first service and other services outside the first network namespace Container communication.
- the processor 202 is further configured to:
- the service address corresponding to the first service includes a network interface address of the virtual network device and an IPC interface address of the first IPC namespace.
- the application also provides a method for deploying a container.
- the network device 200 in FIG. 4 executes the method during operation, and a schematic flowchart thereof is shown in FIG. 5.
- the network device may be a physical machine or a virtual machine in the network, and the network device receives the container deployment message.
- the network device may receive the management device by using the container management module in the network device.
- the container deployment message sent.
- the container deployment message includes container image information and associated information of the container.
- the container image information includes some necessary parameters for creating the container, such as the identifier ID of the image.
- the container deployment message further includes other parameters required for creating the container. Specifically, the other parameters are determined by the container to be created. Type is determined.
- the association information of the container is used to indicate the container of other services that need to be accessed, for example, when the container of the first service is deployed, the container of other services needs to be accessed to obtain corresponding setting parameters and the like.
- a network bridge is created on the network device, where the bridge is used to provide a data exchange service, and the first network namespace corresponding to the container that creates the first service and the first inter-process communication IPC name After the space, the method further includes:
- Creating a virtual network device in the first network namespace the virtual network device being configured to connect with the bridge, so that the container of the first service and other services outside the first network namespace Container communication.
- the method further includes:
- the service address corresponding to the first service includes a network interface address of the virtual network device and an IPC interface address of the first IPC namespace.
- the network device creates a container of the first service according to the container image information in the container deployment message, and a first network namespace corresponding to the container that creates the first service and a first inter-process communication IPC namespace.
- the container of the first service is used to deploy a service provided by the application.
- the container management module in the network device starts the container instance in a bridge mode provided by a bridge provided by the docker container engine (the following bridges are collectively referred to as docker0 bridge).
- a container of the first service (hereinafter referred to as C2) is created according to the container deployment message.
- the docker container engine creates a new network namespace (hereinafter referred to as Np2) and an IPC namespace (hereinafter referred to as Ip2) for C2, and creates a standard Linux virtual network device interface eth0 in Np2 (for example, IP is 10.1. 0.101) Provides network services for the containers in Np2, and then connects the eth0 interface with the docker0 bridge of the network device through the virtual network device (veth pair) technology, so that the containers in Np2 can communicate with other containers through the docker0 bridge. Network communication. After C2 starts, it will run in the network namespace Np2 and the IPC namespace Ip2.
- Np2 new network namespace
- Ip2 IPC namespace
- the service registration module applied in C2 will name its own service address (that is, the virtual network device interface address and corresponding IPC in the network namespace corresponding to C2).
- the IPC interface address of the space such as http://10.1.0.101:8080 and ContainerC2_IPC, and the information of the service to which it belongs (for example, the service is ServiceB) are sent to the service registry registration service instance.
- the network device creates a first load balancing container corresponding to the container of the first service, and sets an operating parameter of the first load balancing container as a parameter of the first network namespace, and the operating parameter
- the first load balancing container is used to share the first network namespace at runtime.
- the system provides a standard load balancing image Mlb including a load balancing module, and the container management module in the network device automatically creates a load balancing corresponding to the first service container (for example, C2) by using the load balancing image Mlb. Container (eg C3).
- the load balancing module in the load balancing container eg, C3) can query the service registry for all instance access addresses for each service.
- the IPC access address of the instance is also returned.
- the container C1 of the second service has been created on the same task node (network device) (for example, the service belongs to ServiceA); for example, C3 queries the service registry for the instance address table of ServiceA on the task node (network device) where C1 is located.
- the service registry will detect that C1 and C3 are on the same task node (network device), so not only the network address of C1 (that is, the address of the virtual network device interface created in the network namespace to which C1 belongs) is returned. It also returns the IPC interface address of C1 (that is, the IPC interface address in the IPC namespace to which C1 belongs). Subsequent C3 is going to When accessing C1, the interface access of the ContainerC1_IPC IPC service address is preferred.
- the network device creates a loopback interface in the first network namespace; the loopback interface is used by the first load balancing container to communicate with the container of the first service.
- the C3 running parameter net_namespace is set to Np2, so that the C3 runtime shares the network namespace Np2 with C2, that is, the virtual network device in Np2 can be used together, so the load balancing module running in C3 is bound to the first network name.
- a load balancing service is provided on the loopback interface in space.
- the startup parameter is used by the first load balancing container to communicate with the container of the second service through an IPC interface of the second IPC namespace after startup, and parameters and locations of the second IPC namespace The parameters of the first IPC namespace are different.
- the method further includes:
- the parameters of the third IPC namespace are different from the parameters of the first IPC namespace and the parameters of the second IPC namespace.
- the container management module in the network device may search for the affinity container of the container of the first service on the network device (the affinity container is also the container of the first service)
- An associated container that is, a container for other services that the container of the first service needs to access).
- the container of the second service has been created on the network device, and the container of the first service is determined to be associated with the container of the second service, the container of the first service needs to access the container. a container of the second service, to obtain a related parameter of the container of the second service, etc.; then, the network device searches for a second IPC namespace corresponding to the container of the second service, and sets a startup parameter of the first load balancing container The parameter of the second IPC namespace, so that the first load balancing container can communicate with the container of the second service through the IPC interface of the second IPC namespace after startup.
- a container C1 of the second service (ServiceA) has been created on the network device, wherein the container C2 of the first service (ServiceB) is associated with the container C1 of the second service (ServiceA), in the network device
- the container management module finds the affinity container C1, and binds the container C1 of the second service to the container C2 of the first service to provide services through the IPC, and knows that the IPC namespace of C1 is Ip1. If you have multiple affinity containers, you can randomly select one to bind.
- the startup parameter of the load balancing container C3 corresponding to the container C2 of the first service is the second IPC namespace ipc_namespace: Ip1, so that when C3 is started, IPC communication can be performed with the container in Ip1 (ie, the container can be used with the second service) C1 performs IPC communication).
- the load balancing module in C3 works on the loopback interface in the network namespace corresponding to the container of the first service. That is, C2 under the same network namespace can only be accessed through the address of the loopback interface (for example, 127.0.0.1), and other containers cannot be accessed.
- the network device sets a startup parameter of the first load balancing container.
- the parameters of the third IPC namespace are different from the parameters of the first IPC namespace and the parameters of the second IPC namespace.
- the first load balancing container uses a separate third IPC namespace, not a total Eat the IPC namespace of other containers.
- the network device in the first network namespace may be used because the first load balancing container shares the first network namespace corresponding to the container of the first service during operation; Therefore, the load balancing module running in the first load balancing container can be bound to provide a load balancing service on the loopback interface established in the first network namespace; in addition to the first service container corresponding to the first load balancing container Other containers cannot access the load balancing container through the loopback interface, ensuring isolation between containers on the same host.
- the startup parameter of the first load balancing container is set to be the first
- the parameter of the second IPC namespace corresponding to the container of the second service enables the first load balancing container to access the container of the second service through the IPC interface of the second IPC namespace when starting, thereby ensuring the same host Based on the isolation between the containers on the top, the access speed between the containers is improved.
- the present application also provides a communication method between services, which is applied to the network device 200 provided by the present application.
- the communication method between the services provided by the present application has the following premise based on the method for deploying the container provided by the present application.
- the container of the second service and the corresponding second load balancing container have been created and started on the network device 200, and the container of the second service has a corresponding second network namespace and a second IPC namespace; a first service container and a corresponding first load balancing container; creating a first network namespace corresponding to the first service container and a first inter-process communication IPC namespace, and setting the first load balancing container
- the operating parameter is a parameter of the first network namespace, and a loopback interface is created in the first network namespace, and the startup parameter of the first load balancing container is set as a parameter of the second IPC namespace.
- the parameter of the second IPC namespace and the parameter of the first IPC namespace are different.
- the container of the first service sends a service access request to the first load balancing container by using the loopback interface created in the first network namespace.
- the first load balancing container acquires a service address corresponding to the container of the second service according to the service access request, and the service address corresponding to the container of the second service includes a corresponding location of the container of the second service.
- the network interface address of the second network namespace and the IPC interface address of the second IPC namespace are included in the first load balancing container.
- the first load balancing container accesses the container of the second service by using an IPC interface address of the second IPC namespace.
- the container (C1) of the second service and the corresponding second load balancing container have been created and started on the network device 200, and the container (C1) of the second service has a corresponding second network.
- a namespace (Np1) and a second IPC namespace (Ip1) when creating a container (C2) of the first service and the corresponding first load balancing container (C3); creating a container (C2) corresponding to the first service a first network namespace (Np2) and a first inter-process communication IPC namespace (Ip2), and setting an operating parameter (net_namespace) of the first load balancing container (C3) as a parameter of the first network namespace (Np2), and creating a loopback interface (lo) in the first network namespace, and setting a startup parameter (ipc_namespace) of the first load balancing container (C3) to the second IPC namespace (Ip1)
- the parameter of the second IPC namespace (Ip1) and the parameter of the first Ip1 when creating
- the service address includes a network interface address (for example, http://10.2.0.101:8080) of the second network namespace (Ip1) corresponding to the C1 and an IPC interface address of the second IPC namespace (Ip1) (for example, Http://10.1.0.101:8080
- the C3 accesses the C1 through the IPC interface address of the second IPC namespace (Ip1).
- the network device in the first network namespace may be used. Therefore, the load balancing module running in the first load balancing container can be bound to provide a load balancing service on the loopback interface established in the first network namespace; except the first service corresponding to the first load balancing container The container, other containers cannot access the load balancing container through the loopback interface. Therefore, under the premise of ensuring the isolation between the containers on the same host, when the container of the first service is deployed, the startup parameter of the first load balancing container is set to correspond to the container of the second service.
- the first load balancing container can access the container of the second service through the IPC interface address of the second IPC namespace when starting, thereby ensuring the container on the same host On the basis of isolation, the access speed between containers is improved.
- the embodiment of the present application further provides a container deployment device 600, which may be implemented by the network device 200 shown in FIG. 4, or may be implemented by an application-specific integrated circuit (ASIC), or programmable.
- Logic device (English: programmable logic device, PLD) implementation.
- the PLD may be a complex programmable logic device (CPLD), an FPGA, a general array logic (GAL), or any combination thereof.
- the container deployment device 600 is used to implement the method of deploying the container shown in FIG. When the method of deploying the container shown in FIG. 5 is implemented by software, the device 600 may also be a software module.
- a schematic diagram of the organization of the container deployment device 600 is as shown in FIG. 7, and includes a transceiver unit 602 and a processing unit 604.
- the steps 401 and 401 in the method for deploying the container shown in FIG. 5 are executed; when the processing unit 604 is in operation, step 402 in the method for deploying the container shown in FIG. 5 is executed. 405 and the alternatives in steps 402-405.
- the transceiver unit 602 can also be implemented by the transceiver 206 as shown in FIG. 4
- the processing unit 604 can also be implemented by the processor 202 as shown in FIG.
- the container deployment device 600 receives the container deployment message and creates a container of the first service and a first load balancing container corresponding to the container of the first service, since the first load balancing container shares the container of the first service at runtime
- the first network namespace that is, the network device in the first network namespace can be used; therefore, the load balancing module running in the first load balancing container can bind the loopback established in the first network namespace
- the load balancing service is provided on the interface; except for the container of the first service corresponding to the first load balancing container, the other containers cannot access the load balancing container through the loopback interface, thereby ensuring isolation between the containers on the same host. Sex.
- the container of the second service When the container of the second service has been created on the network device and the container of the first service is determined to be associated with the container of the second service according to the received container deployment message, setting the startup parameter of the first load balancing container to the second
- the parameter of the second IPC namespace corresponding to the container of the service enables the first load balancing container to access the container of the second service through the IPC interface of the second IPC namespace when starting, thereby ensuring the same host
- the isolation between the containers is based on the speed of access between the containers.
- the embodiment of the present application further provides a communication device 700 between the services.
- the device 700 can be implemented by using the network device 200 shown in FIG. 4, and can also be implemented by an ASIC or a PLD.
- the above PLD may be a complex programmable logic device CPLD, FPGA, GAL or any combination thereof.
- the communication device 700 of the service is used to implement the communication method between the services shown in FIG. 6.
- the device 700 may also be a software module.
- the organization structure of the communication device 700 of the service room includes: a container 702 of the first service and a corresponding first load balancing container 704, a container 706 of the second service, and a corresponding second load balancing container 708.
- step 501 in the communication method between the services shown in FIG. 6 and an alternative thereof are executed; when the first load balancing container 704 is in operation, the communication method between the services shown in FIG. 6 is executed. Steps 502 to 503 and alternatives thereof.
- the network device in the first network namespace can be used because the first load balancing container 704 shares the first network namespace corresponding to the container 702 of the first service during operation; Therefore, the load balancing module running in the first load balancing container 704 can be bound to provide a load balancing service on the loopback interface established in the first network namespace; in addition to the first service corresponding to the first load balancing container 704 The container 702, other containers cannot access the load balancing container through the loopback interface. Therefore, under the premise of ensuring the isolation between the containers on the same host, when the container 702 of the first service is deployed, the startup parameter of the first load balancing container 704 is set to the container 706 of the second service.
- the disclosed system, apparatus, and method may be implemented in other manners.
- the device embodiments described above are merely illustrative.
- the division of the unit is only a logical function division.
- there may be another division manner for example, multiple units or components may be combined or Can be integrated into another system, or some features can be ignored or not executed.
- the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed to multiple network devices. Some or all of the devices may be selected according to actual needs to achieve the purpose of the solution of the embodiment.
- each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
- the above integrated unit can be implemented in the form of hardware or in the form of a software functional unit.
- the integrated unit if implemented in the form of a software functional unit and sold or used as a standalone product, may be stored in a computer readable storage medium. Based on such understanding, all or part of the technical solution of the present invention may be embodied in the form of a software product.
- the computer software product is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods described in various embodiments of the present invention.
- the foregoing storage medium includes: a universal serial bus flash disk (English: USB flash disk), a mobile hard disk, a read-only memory (English: read-only memory, ROM), a random access memory. (English: random access memory, RAM), a disk or a disc, and other media that can store program code.
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明实施例公开了一种容器的部署方法、服务间的通信方法及相关装置,能够在保证同一宿主机上的容器之间具备隔离性的基础上,提高容器之间的访问速度。容器的部署方法包括:接收容器部署消息,容器部署消息包括容器镜像信息以及容器的关联信息;根据容器镜像信息创建第一服务的容器以及对应的第一网络命名空间和第一进程间通信IPC命名空间;创建第一服务的容器对应的第一负载均衡容器,并设置第一负载均衡容器的运行参数为第一网络命名空间的参数;在第一网络命名空间中创建环回接口;根据所述容器的关联信息,确定所述网络设备上存在与所述第一服务的容器相关联的第二服务的容器,设置第一负载均衡容器的启动参数为第二IPC命名空间的参数。
Description
本申请要求于2016年11月25日提交中国专利局、申请号为201611053035.7,发明名称为“容器的部署方法、服务间的通信方法及相关装置”的中国专利申请的优先权,其全部内容通过引用结合在本申请中。
本发明涉及虚拟化技术领域,特别涉及容器的部署方法、服务间的通信方法及相关装置。
随着以docker为代表的容器技术的兴起,业界出现了一种以容器作为应用程序(application,App)运行形态的趋势。Docker容器技术是一种轻量级的操作系统虚拟化技术,虽然同一宿主机(物理机或虚拟机)上的容器共享操作系统内核,但不同容器之间使用的资源(如CPU、Memory等)是相互隔离的。容器之间的隔离,一般是通过linux内核提供的命名空间(namespace)技术来实现。Linux内核通过命名空间技术提供了主机名、进程间通信(inter-process communication,IPC)、网络(Network)、挂载点(Mount)、用户(User)的隔离功能。
现有技术中同一个宿主机上的不同容器之间的通信,一般都是通过网络通讯来进行的。以docker容器引擎为例,docker容器引擎在接收到容器部署消而部署容器时,会在宿主机上创建一个名为docker0的网桥(bridge)为所有容器提供数据交换服务,同时为每个容器建立单独的网络命名空间(network namespace,简称net namespace),然后在每个容器的网络命名空间中建立一个网络接口(eth),最后通过虚拟网络设备对(veth pair)技术(有两端,跨越网络命名空间,类似管道)使得容器的网络接口与docker0网桥进行通讯,如图1a所示。docker0网桥可以为同一宿主机上的不同容器提供网络数据交换功能,也可以将容器内的数据包发到用户指定的覆盖网络(overlay network)中进行跨宿主机节点的通讯。
随着技术的发展,特别是互联网技术的发展,应用的规模及复杂性大大提高。传统的烟囱式的单体应用架构已经不能很好的适应目前的应用开发,因此出现了微服务架构。微服务架构的总体思想是通过对应用进行解耦,将传统单体应用划分成多个细粒度的服务,降低系统的耦合性,提高系统的灵活度。微服务之间通过相互协调配合来为用户提供最终价值。微服务架构会将系统划分成大量的独立服务,每个服务又会由多个具体的服务实例来提供服务,所以服务间的通信量会比较大,通信也比较频繁,相比传统的软件构架,服务与服务之间需要尽量快速的通信方法。在图1b所示的一个现有的基于docker容器的应用程序的部署方案中,服务消费者应用(简称SC App)与负载均衡(load balance,LB)模块部署在同一个docker容器内。其中,SC App与LB模块之间通过IPC的方式可以达到内存访问级的数据通信速度。而LB模块与要访问的服务提供者应用(简称SP App)则以容器间网络进行通信,即LB模块把SC App的数据通过SC App所属容器的虚拟网络接口eth0发送到宿主机上的命名为docker0的网桥(docker0 bridge),再通过该网桥将SC App的数据转发到SP App所属容器的虚拟网络接口eth1。因此,上述同一宿主机上的容器之间访问需要通过虚拟网络接口eth0到网桥docker0 bridge,再通过网桥docker0 bridge到虚拟网络接口eth1这样的网络路径,中间需要进行数据打包、路由等一系列链路层和网络层操作,数据通信速度存在优化空间。
为了提高同一宿主机上的容器之间的数据通信速度,考虑使用IPC的方式来提高数据通信速度,即可以把要进行通信的容器放置在同一个IPC命名空间(namespace)中来使得容器间可以通过IPC进行通信,如图1c所示。然而,该方案虽然可以使得不同容器间通过IPC进行高速通信,但同时也使得本来不需要进行通信的容器也可以进行IPC通信。例如容器B要访问容器A,同时容器C也需要访问容器A,但容器B和容器C不需要进行数据通信,该方案使得容器B和容器C也运行在同一个IPC命名空间中,这样就破坏了容器B和容器C之间的隔离性。因此,如果同一个容器需要被多个其他容器进行访问,采用该方案的话会破坏所有容器之间的隔离性。
发明内容
本申请提供了一种容器的部署方法、服务间的通信方法及相关装置,能够在保证同一宿主机上的容器之间具备隔离性的基础上,提高容器之间的访问速度。
本申请第一方面提供了一种容器的部署方法,应用于网络设备,该网络设备可以是指网络中任意的物理机或者虚拟机。该网络设备通过接收容器部署消息为第一服务创建对应的容器并部署该第一服务;该容器部署消息包括容器镜像信息和容器的关联信息,通过该容器镜像信息为第一服务创建对应的容器以及为该第一服务的容器创建对应的第一网络命名空间和第一IPC命名空间;同时,可自动为该第一服务的容器创建对应的第一负载均衡容器,并设置该第一负载均衡容器的运行参数为该第一网络命名空间的参数,以使该第一负载均衡容器在运行时共享该第一网络命名空间;且通过在该第一网络命名空间中创建环回接口,以使该第一负载均衡容器与该第一服务的容器能够通过该环回接口通信。
当该网络设备根据所述容器的关联信息,确定所述网络设备上存在与所述第一服务的容器相关联的第二服务的容器时,设置该第一负载均衡容器的启动参数为第二IPC命名空间的参数;该第二IPC命名空间即为该第二服务的容器对应的IPC命名空间;由此,该第一负载均衡容器在启动后能够通过该第二IPC命名空间的IPC接口与该第二服务的容器通信。
由于该第一负载均衡容器在运行时共享该第一服务的容器对应的第一网络命名空间,即可以使用该第一网络命名空间中的网络设备;因此,该第一负载均衡容器中运行的负载均衡模块能够绑定在该第一网络命名空间中建立的环回接口上提供负载均衡服务;除了该第一负载均衡容器对应的第一服务的容器,其他的容器均无法通过该环回接口访问该负载均衡容器,保证了同一宿主机上的容器之间的隔离性。当网络设备上已创建该第二服务的容器且根据接收的容器部署消息确定该第一服务的容器与该第二服务的容器关联时,通过设置该第一负载均衡容器的启动参数为该第二服务的容器对应的第二IPC命名空间的参数,使得该第一负载均衡容器在启动时,能够通过该第二IPC命名空间的IPC接口访问该第二服务的容器,从而在保证同一宿主机上的容器之间具备隔离性的基础上,提高了容器之间的访问速度。
在一种可能的实现方式中,当该网络设备根据所述容器的关联信息,确定所述网络设备上不存在与所述第一服务的容器相关联的容器时,设置该第一负载均衡容器的启动参数为第三IPC命名空间的参数,该第三IPC命名空间为独立的IPC命名空间,与前述的第一IPC命名空间以及第二IPC命名空间不相同。由此,为该第一负载均衡容器配置了独立的IPC命名空间,以保证容器之间的隔离性。
在一种可能的实现方式中,在接收到容器部署消息时,通过启动容器引擎为该网络设备创建网桥,该网桥用于提供数据交换服务。在创建该第一服务的容器对应的第一网络命名空
间和第一IPC命名空间后,在该第一网络命名空间中创建虚拟网络设备,该虚拟网络设备可以理解为虚拟网卡,通过该虚拟网络设备与该网桥连接,能够使该第一服务的容器与该第一网络命名空间之外的其他服务的容器通信。
在一种可能的实现方式中,在创建该虚拟网络设备后,该网络设备将该第一服务对应的服务地址发送到服务注册中心;该第一服务对应的服务地址包括该虚拟网络设备的网络接口地址和该第一IPC命名空间的IPC接口地址。由此,可以通过访问该服务注册中心可以查询到所部署的所有服务对应的服务地址,通过查询到的服务地址可以访问对应的服务。
本申请第二方面提供了一种服务间的通信方法,应用于本申请第一方面所提供的网络设备,其中,该网络设备上已创建并运行第二服务的容器和对应的第二负载均衡容器,该第二服务的容器具有对应的第二网络命名空间和第二IPC命名空间;在创建第一服务的容器和对应的第一负载均衡容器时;创建该第一服务的容器对应的第一网络命名空间和第一进程间通信IPC命名空间,并设置该第一负载均衡容器的运行参数为该第一网络命名空间的参数,且在该第一网络命名空间中创建环回接口,并设置该第一负载均衡容器的启动参数为该第二IPC命名空间的参数,其中,该第二IPC命名空间的参数和该第一IPC命名空间的参数不相同。基于前述内容,该服务间的通信方法包括:
该第一服务的容器通过该第一网络命名空间中创建的该环回接口向该第一负载均衡容器发送服务访问请求,以访问第二服务的容器。该第一负载均衡容器根据该服务访问请求获取该第二服务的容器对应的服务地址,其中,该第一负载均衡容器可通过查询服务注册中心中记录的服务地址,找到以访问第二服务的容器所对应的服务地址。该第二服务的容器所对应的服务地址包括该第二服务的容器对应的该第二网络命名空间的网络接口地址和该第二IPC命名空间的IPC接口地址。由此,该第一负载均衡容器可通过该第二IPC命名空间的IPC接口地址访问该第二服务的容器。
由于该第一负载均衡容器在运行时共享该第一服务的容器对应的第一网络命名空间,即可以使用该第一网络命名空间中的网络设备;因此,该第一负载均衡容器中运行的负载均衡模块能够绑定在该第一网络命名空间中建立的环回接口上提供负载均衡服务;除了该第一负载均衡容器对应的第一服务的容器,其他的容器均无法通过该环回接口访问该负载均衡容器。因此,在保证了同一宿主机上的容器之间的隔离性的前提下,在部署第一服务的容器时,通过设置该第一负载均衡容器的启动参数为该第二服务的容器对应的第二IPC命名空间的参数,由此,该第一负载均衡容器在启动时,能够通过该第二IPC命名空间的IPC接口地址访问该第二服务的容器,从而在保证同一宿主机上的容器之间具备隔离性的基础上,提高了容器之间的访问速度。
本申请第三方面提供了一种容器的部署装置,该容器的部署装置包括了用于执行第一方面或第一方面的任一种实现方式中提供的容器的部署方法的至少一个单元。
本申请第四方面提供了一种服务间的通信装置,该服务间的通信装置包括了用于执行第二方面或第二方面的任一种实现方式中提供的服务间的通信方法的至少一个单元。
本申请的第五方面,提供了一种存储介质,该存储介质中存储了程序代码,该程序代码被网络设备运行时,执行第一方面或第一方面的任意一种实现方式提供的容器的部署方法。该存储介质包括但不限于快闪存储器(英文:flash memory),硬盘(英文:hard disk drive,HDD)或固态硬盘(英文:solid state drive,SSD)。
本申请的第六方面,提供了一种存储介质,该存储介质中存储了程序代码,该程序代码
被网络设备运行时,执行第二方面或第二方面的任意一种实现方式提供的服务间的通信方法。该存储介质包括但不限于快闪存储器,硬盘或固态硬盘。
图1a为本申请所提供的容器部署方案的一个结构示意图;
图1b为本申请所提供的容器部署方案的另一结构示意图;
图1c为本申请所提供的容器部署方案的另一结构示意图;
图2为本申请所提供的微服务部署系统的一个架构示意图;
图3为本申请所提供的容器部署方案的另一结构示意图;
图4为本申请所提供的网络设备的一个结构示意图;
图5为本申请所提供的容器的部署方法的一个流程示意图;
图6为本申请所提供的服务间的通信方法的一个流程示意图;
图7为本申请所提供的容器的部署装置的一个结构示意图;
图8为本申请所提供的服务间的通信装置的一个结构示意图。
本申请的说明书和权利要求书以及上述附图说明的附图中所涉及的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。下面结合本申请实施例中的附图,对本申请实施例中的技术方案进行描述。
如图2所示,为本申请提供的一种基于docker容器的微服务部署系统的架构示意图。该部署系统包括管理节点、任务节点和服务注册中心。其中,管理节点可以接收业务人员发送的容器部署消息,将容器调度到某个任务节点上运行。这里的任务节点可以是指网络中任意的物理机PM或者虚拟机VM。任务节点上运行着容器管理模块,例如可以是docker容器引擎,可以接收管理节点的指令,根据该指令在任务节点上启动容器。
运行在容器内的应用如果要对外提供服务,需要向服务注册中心注册服务地址,因此每个部署了应用的容器(App Container)启动之后会把容器内应用的服务访问地址发送服务实例注册消息到服务注册中心去注册服务实例,该服务器实例注册消息中包含了服务名和服务实例地址。例如,图2中的应用1部署在一个容器中,该应用1如果要对外提供服务,需要向服务注册中心注册服务地址,即将容器内应用1的服务访问地址发送服务实例注册消息到服务注册中心去注册服务实例。应用2与应用1的部署方式类似,此处不再赘述。每个应用都提供了网络(例如http://container_ip:8080)和IPC消息队列名(ContainerName_IPC)两种服务地址,即每个容器启动后,可以从外部通过网络(例如http://container_ip:8080)和IPC消息队列名(ContainerName_IPC)两种方式访问容器提供的服务。服务注册中心通过接收并保存服务实例注册信息维护了部署系统中所有服务的可用实例地址表,本部署系统中的一个服务实例地址表结构可参考下表1所示:
表1
表1中服务名即服务的类型,实例地址表中是某个服务类型所有的容器实例访问地址的列表。服务注册中心对外提供服务实例地址的查询功能,外部可以通过发送服务实例查询消息(消息中包含服务名)获取对应服务所有的实例访问地址。
每一个部署了应用的容器在同一任务节点上都有一个对应的负载均衡容器(LB container)来为其提供服务访问功能。例如,图2中的负载均衡1与应用1对应,用于为应用1提供服务访问功能,负载均衡1与应用1部署在不同的容器中,这两个容器共享一个网络命名空间。负载均衡2与负载均衡1的部署方式类似,此处不再赘述。负载均衡容器工作在环回接口上,应用的容器可以通过环回接口与负载均衡容器进行高速的数据通信。应用的容器要访问服务时,会向负载均衡容器发送服务访问请求,请求中包含了要访问的服务名及具体的服务接口(提供具体功能的接口,类似函数接口),如http://127.0.0.1:8000/ServiceA/GetProductInfo?id=120的服务访问请求就是要访问表1中ServiceA的GetProductInfo接口来获取某个产品的具体信息。负载均衡容器通过向服务注册中心发送服务实例查询消息获取某个服务的所有服务实例地址。具体的,服务注册中心还可以自动识别发送查询请求的负载均衡容器所在的任务节点,根据负载均衡容器所在的任务节点,把与负载均衡容器在同一任务节点上的服务实例的IPC地址返回给负载均衡容器。在应用的容器要访问服务时,根据一定的负载均衡策略选一个服务实例地址进行访问。在这里,可参考一种简单的策略:优先通过IPC接口访问在同一任务节点上的服务实例,如果同一任务节点上存在多个服务提供者实例,则为服务消费者容器随机绑定一个服务提供者实例进行访问。当IPC地址访问失败时,再通过轮转调度策略访问其他网络接口的服务实例。
Linux支持环回接口(Loopback Interface),这个接口允许运行在同一台主机上的客户程序和服务器程序通过TCP/IP进行通信。A类网络127就是为环回接口预留的。通常情况下,大多数系统把IP地址127.0.0.1分配给这个接口。一个传给环回接口的IP数据包在处理的时候直接从发送缓存拷贝到接收缓存,省去了在数据链路层和物理层的操作。环回接口只能在同一个网络命名空间内进行访问,外部无法访问。
进程间通信IPC,是由操作系统提供的用于不同进程间进行快速通信的技术。相比网络通信,IPC通常最终通过进程间直接的内存拷贝来实现,免除了网络协议栈封包解包、路由查询、规则匹配、链路传输等过程,相比网络通信有着非常大的速度优势。常用的IPC技术包括共享内存、IPC消息队列、system V/POSIX管道等。一般是服务端创建一个IPC通道,客户端和服务端通过IPC通道进行数据交换。
然而与虚拟机不同的是,容器内部进程间通信对宿主机来说,实际上是具有相同进程间通信命名空间(IPC namespace)中的进程间通信,因此需要一个唯一的标识符来进行区别。申请IPC资源就申请了这样一个全局唯一的32位ID,所以IPC namespace中实际上包含了系统IPC标识符以及实现POSIX消息队列的文件系统。在同一个IPC namespace下的进程彼此可见,而与其他的IPC namespace下的进程则互相不可见。
基于图2所示的微服务部署系统的架构,如图3所示,为本申请所提供容器部署方案的
一个结构示意图。
如图3所示,应用容器(图示中部署了应用1或应用2的容器)运行着由用户编写的对外提供服务的应用程序。负载均衡容器(图示中部署了负载均衡1或负载均衡2的容器)是由系统提供的标准容器,工作在环回接口(图示中lo)接收应用容器的服务访问请求,负责从服务注册中心获取服务的访问地址并通过一定的负载均衡策略转发应用容器的服务访问请求到选定的服务实例容器获取服务结果并返回给应用容器。应用容器和其对应的负载均衡容器共享同一个网络命名空间,虚拟网络接口是一个标准的虚拟网络设备(可以认为是一块网卡),图3所示的应用1的容器和应用2的容器可以通过各自网络命名空间中的虚拟网络接口与其网络命名空间之外的容器进行数据通信,也可以通过环回接口(lo)对在同一网络命名空间内的容器进行快速的数据通信(网络数据会直接内存拷贝到对应进程),但不在同一网络命名空间内的容器(进程)无法访问该网络命名空间内的环回接口lo,只能通过虚拟网络接口进行标准的网络数据通信。应用容器采用独立的IPC命名空间来运行,因此用户在编写应用时无需考虑其他容器的影响,保留了应用之间的隔离性。任务节点上的容器管理模块在部署容器时,如果检测到任务节点上存在待部署容器需要访问的容器,则会把待部署的容器对应的负载均衡容器的IPC命名空间设置为该需要访问的容器的IPC命名空间,这样待部署的容器对应的负载均衡容器就可以与该需要访问的容器进行高速的IPC通信,但没有破坏待部署的容器和该需要访问的容器之间(图中应用1的容器和应用2的容器)的隔离性,而标准的负载均衡容器由系统提供,行为完全可控,共享IPC命名空间也不会对应用造成安全和隔离性影响。
图3中的任务节点可以通过图4中的网络设备200实现,网络设备200的组织结构示意图如图4所示,包括处理器202、存储器204和收发器206,还可以包括总线208。
其中,处理器202、存储器204和收发器206可以通过总线208实现彼此之间的通信连接,也可以通过无线传输等其他手段实现通信。
存储器204可以包括易失性存储器(英文:volatile memory),例如随机存取存储器(英文:random-access memory,缩写:RAM);存储器也可以包括非易失性存储器(英文:non-volatile memory),例如只读存储器(英文:read-only memory,缩写:ROM),快闪存储器(英文:flash memory),硬盘(英文:hard disk drive,缩写:HDD)或固态硬盘(英文:solid state drive,缩写:SSD);存储器204还可以包括上述种类的存储器的组合。在通过软件来实现本申请提供的技术方案时,用于实现本申请图5提供的容器的部署方法的程序代码保存在存储器204中,并由处理器202来执行。
网络设备200通过收发器206与其他设备通信。
处理器202可以为中央处理器(英文:central processing unit,CPU)。
所述收发器206,用于接收容器部署消息,所述容器部署消息包括容器镜像信息以及容器的关联信息。
所述处理器202,用于根据所述容器镜像信息创建第一服务的容器以及创建所述第一服务的容器对应的第一网络命名空间和第一进程间通信IPC命名空间;
创建所述第一服务的容器对应的第一负载均衡容器,并设置所述第一负载均衡容器的运行参数为所述第一网络命名空间的参数,所述运行参数用于所述第一负载均衡容器在运行时共享所述第一网络命名空间;
在所述第一网络命名空间中创建环回接口,所述环回接口用于所述第一负载均衡容器与
所述第一服务的容器通信;
根据所述容器的关联信息,确定所述网络设备上存在与所述第一服务的容器相关联的第二服务的容器,获取所述第二服务的容器对应的第二IPC命名空间的参数,并设置所述第一负载均衡容器的启动参数为所述第二IPC命名空间的参数;所述启动参数用于所述第一负载均衡容器在启动后通过所述第二IPC命名空间的IPC接口与所述第二服务的容器通信,所述第二IPC命名空间的参数和所述第一IPC命名空间的参数不相同。
由于该第一负载均衡容器在运行时共享该第一服务的容器对应的第一网络命名空间,即可以使用该第一网络命名空间中的网络设备;因此,该第一负载均衡容器中运行的负载均衡模块能够绑定在该第一网络命名空间中建立的环回接口上提供负载均衡服务;除了该第一负载均衡容器对应的第一服务的容器,其他的容器均无法通过该环回接口访问该负载均衡容器,保证了同一宿主机上的容器之间的隔离性。当网络设备200上已创建该第二服务的容器且根据接收的容器部署消息确定该第一服务的容器与该第二服务的容器关联时,通过设置该第一负载均衡容器的启动参数为该第二服务的容器对应的第二IPC命名空间的参数,使得该第一负载均衡容器在启动时,能够通过该第二IPC命名空间的IPC接口访问该第二服务的容器,从而在保证同一宿主机上的容器之间具备隔离性的基础上,提高了容器之间的访问速度。
可选的,所述处理器202还用于:
当根据所述容器的关联信息,确定所述网络设备上存在与所述第一服务的容器相关联的第二服务的容器时,设置所述第一负载均衡容器的启动参数为第三IPC命名空间的参数,所述第三IPC命名空间的参数与所述第一IPC命名空间的参数以及所述第二IPC命名空间的参数均不相同。
可选的,所述处理器202,所述网络设备200上创建有网桥,所述网桥用于提供数据交换服务,所述处理器202用于创建所述第一服务的容器对应的第一网络命名空间和第一进程间通信IPC命名空间后,所述处理器202还用于:
在所述第一网络命名空间中创建虚拟网络设备,所述虚拟网络设备用于与所述网桥连接,以使所述第一服务的容器与所述第一网络命名空间之外的其他服务的容器通信。
可选的,所述处理器202用于创建虚拟网络设备后,所述处理器202还用于:
将所述第一服务对应的服务地址发送到服务注册中心;所述第一服务对应的服务地址包括所述虚拟网络设备的网络接口地址和所述第一IPC命名空间的IPC接口地址。
本申请还提供了一种容器的部署方法,图4中的网络设备200运行时执行该方法,其流程示意图如图5所示。
401、接收容器部署消息,所述容器部署消息包括容器镜像信息以及容器的关联信息。
需要说明的是,该网络设备可以是网络中的物理机或者虚拟机,网络设备接收容器部署消息,在一个可能实现方式中,该网络设备可通过该网络设备中的容器管理模块来接收管理设备发来的容器部署消息。其中,该容器部署消息包括容器镜像信息以及容器的关联信息。其中,容器镜像信息包括创建容器的一些必要参数,比如镜像的标识ID;可选的,所述容器部署消息中还包括创建容器需要的其他参数,具体的,该其他参数由待创建的容器的类型确定。容器的关联信息用于指示所需要访问的其他服务的容器,例如部署第一服务的容器时,需要访问其他服务的容器以获取相应的设置参数等。
402、根据所述容器镜像信息创建第一服务的容器以及创建所述第一服务的容器对应的第一网络命名空间和第一进程间通信IPC命名空间。
可选的,所述网络设备上创建有网桥,所述网桥用于提供数据交换服务,所述创建所述第一服务的容器对应的第一网络命名空间和第一进程间通信IPC命名空间后,所述方法还包括:
在所述第一网络命名空间中创建虚拟网络设备,所述虚拟网络设备用于与所述网桥连接,以使所述第一服务的容器与所述第一网络命名空间之外的其他服务的容器通信。
可选的,所述创建虚拟网络设备后,所述方法还包括:
将所述第一服务对应的服务地址发送到服务注册中心;所述第一服务对应的服务地址包括所述虚拟网络设备的网络接口地址和所述第一IPC命名空间的IPC接口地址。
需要说明的是,该网络设备根据所述容器部署消息中的容器镜像信息创建第一服务的容器以及创建所述第一服务的容器对应的第一网络命名空间和第一进程间通信IPC命名空间,所述第一服务的容器用于部署应用所提供的服务。具体的,根据所述容器部署消息,该网络设备中的容器管理模块以docker容器引擎提供的网桥(以下网桥的命名统一称为docker0 bridge)桥接模式启动容器实例。例如,根据所述容器部署消息,创建第一服务的容器(以下简称C2)。具体的,docker容器引擎会为C2创建新的网络命名空间(以下简称Np2)和IPC命名空间(以下简称Ip2),并在Np2中创建一个标准的Linux虚拟网络设备接口eth0(例如IP为10.1.0.101)为Np2中的容器提供网络服务,然后再通过虚拟网络设备对(veth pair)技术把eth0接口与网络设备的docker0 bridge连接,这样Np2中的容器就可以通过docker0 bridge与其他的容器进行标准的网络通信。C2启动后会运行在网络命名空间Np2和IPC命名空间Ip2中,C2中应用的服务注册模块会把自身的服务地址(即C2对应的网络命名空间中的虚拟网络设备接口地址和对应的IPC命名空间的IPC接口地址,例如http://10.1.0.101:8080和ContainerC2_IPC)及自身所属服务(例如所属服务为ServiceB)的信息发送到服务注册中心注册服务实例。
403、创建所述第一服务的容器对应的第一负载均衡容器,并设置所述第一负载均衡容器的运行参数为所述第一网络命名空间的参数。
需要说明的是,网络设备创建所述第一服务的容器对应的第一负载均衡容器,并设置所述第一负载均衡容器的运行参数为所述第一网络命名空间的参数,所述运行参数用于所述第一负载均衡容器在运行时共享所述第一网络命名空间。具体的,系统提供一个标准的包含了负载均衡模块的负载均衡镜像Mlb,该网络设备中的容器管理模块使用负载均衡镜像Mlb自动创建一个与该第一服务的容器(例如C2)对应的负载均衡容器(例如C3)。该负载均衡容器(例如C3)中的负载均衡模块可以从服务注册中心查询到每个服务的所有实例访问地址。其中,对于在同一个任务节点(网络设备)上的服务实例,同时也返回实例的IPC访问地址。设置C3的运行参数net_namespace为Np2对应的参数,使得C3运行时与C2共享网络命名空间Np2,即可以共同使用Np2中的网络设备。假设在同一个任务节点(网络设备)上已创建第二服务的容器C1(例如所属服务为ServiceA);如C3在C1所在的任务节点(网络设备)上向服务注册中心查询ServiceA的实例地址表时,返回的地址列表入下:
http://10.1.0.101:8080|ContainerC1_IPC;
http://10.2.0.101:8080
其中,服务注册中心会检测到C1与C3在同一个任务节点(网络设备)上,因此,不仅返回了C1的网络地址(即在C1所属的网络命名空间中创建的虚拟网络设备接口的地址),还返回了C1的IPC接口地址(即C1所属的IPC命名空间中的IPC接口地址)。后续C3在要
访问C1时,会优先选择ContainerC1_IPC这个IPC服务地址的接口访问。
404、在所述第一网络命名空间中创建环回接口。
需要说明的是,该网络设备在所述第一网络命名空间中创建环回接口;所述环回接口用于所述第一负载均衡容器与所述第一服务的容器通信。具体的,可以使用Linux命令“ifconfig lo:0 127.0.0.1 netmask 255.0.0.0up”来创建并启动一个环回接口并指定了内部访问地址为127.0.0.1。由于设置C3的运行参数net_namespace为Np2,使得C3运行时与C2共享网络命名空间Np2,即可以共同使用Np2中的虚拟网络设备,所以C3中运行的负载均衡模块会绑定在该第一网络命名空间中的环回接口上提供负载均衡服务。
405、根据所述容器的关联信息,确定所述网络设备上存在与所述第一服务的容器相关联的第二服务的容器,获取所述第二服务的容器对应的第二IPC命名空间的参数,并设置所述第一负载均衡容器的启动参数为所述第二IPC命名空间的参数。
其中,所述启动参数用于所述第一负载均衡容器在启动后通过所述第二IPC命名空间的IPC接口与所述第二服务的容器通信,所述第二IPC命名空间的参数和所述第一IPC命名空间的参数不相同。
可选的,所述方法还包括:
根据所述容器的关联信息,确定所述网络设备上不存在与所述第一服务的容器相关联的容器,设置所述第一负载均衡容器的启动参数为第三IPC命名空间的参数,所述第三IPC命名空间的参数与所述第一IPC命名空间的参数以及所述第二IPC命名空间的参数均不相同。
需要说明的是,本发明实施例中可以由网络设备中的容器管理模块查找该网络设备上是否存在该第一服务的容器的亲和容器(该亲和容器也就是与该第一服务的容器有关联的容器,即该第一服务的容器所需要访问的其他服务的容器)。
如果该网络设备上已创建了第二服务的容器,且从上述容器的关联信息中确定该第一服务的容器与该第二服务的容器有关联,即该第一服务的容器需要访问该第二服务的容器,以获取该第二服务的容器的相关参数等;那么,该网络设备通过查找该第二服务的容器对应的第二IPC命名空间,并设置该第一负载均衡容器的启动参数为该第二IPC命名空间的参数,从而该第一负载均衡容器在启动后可以通过第二IPC命名空间的IPC接口与该第二服务的容器通信。例如,该网络设备上已创建了第二服务(ServiceA)的容器C1,其中,该第一服务(ServiceB)的容器C2与该第二服务(ServiceA)的容器C1有关联,该网络设备中的容器管理模块查找到亲和容器C1,并绑定第二服务的容器C1为第一服务的容器C2通过IPC提供服务,并获知C1的IPC namespace为Ip1。如果有多个亲和容器,可以随机选择一个进行绑定。设置该第一服务的容器C2对应的负载均衡容器C3的启动参数为第二IPC命名空间ipc_namespace:Ip1,这样当C3启动后可以与Ip1中的容器进行IPC通信(即可以与第二服务的容器C1进行IPC通信)。同时,在该网络设备上启动该第一服务的容器C2对应的负载均衡容器C3后,C3中的负载均衡模块会工作在该第一服务的容器对应的网络命名空间中的环回接口上,即只能由同一网络命名空间(network namespace)下的C2通过该环回接口的地址(例如127.0.0.1)来访问,其他容器无法访问。
另一方面,如果根据所述容器的关联信息,确定所述网络设备上不存在与所述第一服务的容器相关联的容器时,那么,该网络设备设置该第一负载均衡容器的启动参数为第三IPC命名空间的参数,该第三IPC命名空间的参数与该第一IPC命名空间的参数以及该第二IPC命名空间的参数均不相同。此时,该第一负载均衡容器使用独立的第三IPC命名空间,不共
享其他容器的IPC命名空间。
在本申请提供的容器的部署方法中,由于该第一负载均衡容器在运行时共享该第一服务的容器对应的第一网络命名空间,即可以使用该第一网络命名空间中的网络设备;因此,该第一负载均衡容器中运行的负载均衡模块能够绑定在该第一网络命名空间中建立的环回接口上提供负载均衡服务;除了该第一负载均衡容器对应的第一服务的容器,其他的容器均无法通过该环回接口访问该负载均衡容器,保证了同一宿主机上的容器之间的隔离性。当网络设备上已创建该第二服务的容器且根据接收的容器部署消息确定该第一服务的容器与该第二服务的容器关联时,通过设置该第一负载均衡容器的启动参数为该第二服务的容器对应的第二IPC命名空间的参数,使得该第一负载均衡容器在启动时,能够通过该第二IPC命名空间的IPC接口访问该第二服务的容器,从而在保证同一宿主机上的容器之间具备隔离性的基础上,提高了容器之间的访问速度。
本申请还提供了一种服务间的通信方法,应用于本申请所提供的网络设备200,基于本申请提供的容器的部署方法,本申请提供的服务间的通信方法具备如下前提。其中,所述网络设备200上已创建并启动第二服务的容器和对应的第二负载均衡容器,所述第二服务的容器具有对应的第二网络命名空间和第二IPC命名空间;在创建第一服务的容器和对应的第一负载均衡容器时;创建所述第一服务的容器对应的第一网络命名空间和第一进程间通信IPC命名空间,并设置所述第一负载均衡容器的运行参数为所述第一网络命名空间的参数,且在所述第一网络命名空间中创建环回接口,并设置所述第一负载均衡容器的启动参数为所述第二IPC命名空间的参数,其中,所述第二IPC命名空间的参数和所述第一IPC命名空间的参数不相同。该服务间的通信方法的流程示意图如图6所示。
501、所述第一服务的容器通过所述第一网络命名空间中创建的所述环回接口向所述第一负载均衡容器发送服务访问请求。
502、所述第一负载均衡容器根据所述服务访问请求获取所述第二服务的容器对应的服务地址,所述第二服务的容器对应的服务地址包括所述第二服务的容器对应的所述第二网络命名空间的网络接口地址和所述第二IPC命名空间的IPC接口地址。
503、所述第一负载均衡容器通过所述第二IPC命名空间的IPC接口地址访问所述第二服务的容器。
需要说明的是,例如,所述网络设备200上已创建并启动第二服务的容器(C1)和对应的第二负载均衡容器,所述第二服务的容器(C1)具有对应的第二网络命名空间(Np1)和第二IPC命名空间(Ip1);在创建第一服务的容器(C2)和对应的第一负载均衡容器(C3)时;创建所述第一服务的容器(C2)对应的第一网络命名空间(Np2)和第一进程间通信IPC命名空间(Ip2),并设置所述第一负载均衡容器(C3)的运行参数(net_namespace)为所述第一网络命名空间的参数(Np2),且在所述第一网络命名空间中创建环回接口(lo),并设置所述第一负载均衡容器(C3)的启动参数(ipc_namespace)为所述第二IPC命名空间(Ip1)的参数,其中,所述第二IPC命名空间(Ip1)的参数和所述第一IPC命名空间(Ip2)的参数不相同。
在C2通过该C3访问C1时,该C2通过Ip2中创建的环回接口lo向C3发送服务访问请求,该C3根据该服务访问请求从服务注册中心获取该C1对应的服务地址,该C1对应的服务地址包括该C1对应的该第二网络命名空间(Ip1)的网络接口地址(例如http://10.2.0.101:8080)和该第二IPC命名空间(Ip1)的IPC接口地址(例如
http://10.1.0.101:8080|ContainerC1_IPC);该C3通过该第二IPC命名空间(Ip1)的IPC接口地址访问该C1。
在本申请提供的服务间的通信方法中,由于该第一负载均衡容器在运行时共享该第一服务的容器对应的第一网络命名空间,即可以使用该第一网络命名空间中的网络设备;因此,该第一负载均衡容器中运行的负载均衡模块能够绑定在该第一网络命名空间中建立的环回接口上提供负载均衡服务;除了该第一负载均衡容器对应的第一服务的容器,其他的容器均无法通过该环回接口访问该负载均衡容器。因此,在保证了同一宿主机上的容器之间的隔离性的前提下,在部署第一服务的容器时,通过设置该第一负载均衡容器的启动参数为该第二服务的容器对应的第二IPC命名空间的参数,由此,该第一负载均衡容器在启动时,能够通过该第二IPC命名空间的IPC接口地址访问该第二服务的容器,从而在保证同一宿主机上的容器之间具备隔离性的基础上,提高了容器之间的访问速度。
需要说明的是,本申请实施例中,若无特殊说明,不限定各步骤之间的先后顺序,不限定各步骤之间的相互依赖关系。
本申请实施例还提供了容器的部署装置600,该装置600可以通过图4所示的网络设备200实现,还可以通过专用集成电路(英文:application-specific integrated circuit,ASIC)实现,或可编程逻辑器件(英文:programmable logic device,PLD)实现。上述PLD可以是复杂可编程逻辑器件(英文:complex programmable logic device,CPLD),FPGA,通用阵列逻辑(英文:generic array logic,GAL)或其任意组合。该容器的部署装置600用于实现图5所示的容器的部署方法。通过软件实现图5所示的容器的部署方法时,该装置600也可以为软件模块。
容器的部署装置600的组织结构示意图如图7所示,包括:收发单元602和处理单元604。收发单元602工作时,执行图5所示的容器的部署方法中的步骤401及步骤401中的可选方案;处理单元604工作时,执行图5所示的容器的部署方法中的步骤402~405及步骤402~405中的可选方案。应注意,本申请实施例中,收发单元602也可由如图4中所示的收发器206实现,处理单元604也可由如图4中所示的处理器202实现。
该容器的部署装置600通过接收容器部署消息并创建第一服务的容器以及所述第一服务的容器对应的第一负载均衡容器,由于第一负载均衡容器在运行时共享第一服务的容器对应的第一网络命名空间,即可以使用该第一网络命名空间中的网络设备;因此,该第一负载均衡容器中运行的负载均衡模块能够绑定在该第一网络命名空间中建立的环回接口上提供负载均衡服务;除了该第一负载均衡容器对应的第一服务的容器,其他的容器均无法通过该环回接口访问该负载均衡容器,保证了同一宿主机上的容器之间的隔离性。当网络设备上已创建第二服务的容器且根据接收的容器部署消息确定该第一服务的容器与该第二服务的容器关联时,通过设置该第一负载均衡容器的启动参数为该第二服务的容器对应的第二IPC命名空间的参数,使得该第一负载均衡容器在启动时,能够通过该第二IPC命名空间的IPC接口访问该第二服务的容器,从而在保证同一宿主机上的容器之间具备隔离性的基础上,提高了容器之间的访问速度。
本申请实施例还提供了服务间的通信装置700,该装置700可以通过图4所示的网络设备200实现,还可以通过ASIC实现,或PLD实现。上述PLD可以是复杂可编程逻辑器件CPLD,FPGA,GAL或其任意组合。该服务间的通信装置700用于实现图6所示的服务间的通信方法。通过软件实现图6所示的服务间的通信方法时,该装置700也可以为软件模块。
服务间的通信装置700的组织结构示意图如图8所示,包括:第一服务的容器702和对应的第一负载均衡容器704,第二服务的容器706和对应的第二负载均衡容器708。第一服务的容器702工作时,执行图6所示的服务间的通信方法中的步骤501及其可选方案;第一负载均衡容器704工作时,执行图6所示的服务间的通信方法中的步骤502~503及其可选方案。
该服务间的通信装置700中,由于该第一负载均衡容器704在运行时共享该第一服务的容器702对应的第一网络命名空间,即可以使用该第一网络命名空间中的网络设备;因此,该第一负载均衡容器704中运行的负载均衡模块能够绑定在该第一网络命名空间中建立的环回接口上提供负载均衡服务;除了该第一负载均衡容器704对应的第一服务的容器702,其他的容器均无法通过该环回接口访问该负载均衡容器。因此,在保证了同一宿主机上的容器之间的隔离性的前提下,在部署第一服务的容器702时,通过设置该第一负载均衡容器704的启动参数为该第二服务的容器706对应的第二IPC命名空间的参数,由此,该第一负载均衡容器704在启动时,能够通过该第二IPC命名空间的IPC接口地址访问该第二服务的容器706,从而在保证同一宿主机上的容器之间具备隔离性的基础上,提高了容器之间的访问速度。
上述装置的相关描述可以对应参阅方法实施例部分的相关描述和效果进行理解,本处不做过多赘述。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,在上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其他实施例的相关描述。
对于前述的各方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本发明并不受所描述的动作顺序的限制,因为依据本发明,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所涉及的动作和模块并不一定是本发明所必需的。
在本发明所提供的几个实施例中,应该理解到,所揭露的系统,装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络设备上。可以根据实际的需要选择其中的部分或者全部设备来实现本实施例方案的目的。
另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明的技术方案的全部或部分可以以软件产品的形式体现出来。该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:通用串行总线闪存盘(英文:USB flash disk)、移动硬盘、只读存储器(英文:read-only memory,ROM)、随机存取存储器
(英文:random access memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述,以上实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案脱离权利要求的范围。
Claims (10)
- 一种容器的部署方法,应用于网络设备,其特征在于,包括:接收容器部署消息,所述容器部署消息包括容器镜像信息以及容器的关联信息;根据所述容器镜像信息创建第一服务的容器以及创建所述第一服务的容器对应的第一网络命名空间和第一进程间通信IPC命名空间;创建所述第一服务的容器对应的第一负载均衡容器,并设置所述第一负载均衡容器的运行参数为所述第一网络命名空间的参数,所述运行参数用于所述第一负载均衡容器在运行时共享所述第一网络命名空间;在所述第一网络命名空间中创建环回接口,所述环回接口用于所述第一负载均衡容器与所述第一服务的容器通信;根据所述容器的关联信息,确定所述网络设备上存在与所述第一服务的容器相关联的第二服务的容器;获取所述第二服务的容器对应的第二IPC命名空间的参数,并设置所述第一负载均衡容器的启动参数为所述第二IPC命名空间的参数;所述启动参数用于所述第一负载均衡容器在启动后通过所述第二IPC命名空间的IPC接口与所述第二服务的容器通信,所述第二IPC命名空间的参数和所述第一IPC命名空间的参数不相同。
- 根据权利要求1所述的方法,其特征在于,所述方法还包括:根据所述容器的关联信息,确定所述网络设备上不存在与所述第一服务的容器相关联的容器;设置所述第一负载均衡容器的启动参数为第三IPC命名空间的参数,所述第三IPC命名空间的参数与所述第一IPC命名空间的参数以及所述第二IPC命名空间的参数均不相同。
- 根据权利要求1或2所述的方法,其特征在于,所述网络设备上创建有网桥,所述网桥用于提供数据交换服务,所述创建所述第一服务的容器对应的第一网络命名空间和第一进程间通信IPC命名空间后,所述方法还包括:在所述第一网络命名空间中创建虚拟网络设备,所述虚拟网络设备用于与所述网桥连接,以使所述第一服务的容器与所述第一网络命名空间之外的其他服务的容器通信。
- 根据权利要求3所述的方法,其特征在于,所述创建虚拟网络设备后,所述方法还包括:将所述第一服务对应的服务地址发送到服务注册中心;所述第一服务对应的服务地址包括所述虚拟网络设备的网络接口地址和所述第一IPC命名空间的IPC接口地址。
- 一种服务间的通信方法,应用于网络设备,其特征在于,所述网络设备上已创建并运行第二服务的容器和对应的第二负载均衡容器,所述第二服务的容器具有对应的第二网络命名空间和第二进程间通信IPC命名空间;在创建第一服务的容器和对应的第一负载均衡容器时,创建所述第一服务的容器对应的第一网络命名空间和第一IPC命名空间,并设置所述第一负载均衡容器的运行参数为所述第一网络命名空间的参数,且在所述第一网络命名空间中创建环回接口,并设置所述第一负载均衡容器的启动参数为所述第二IPC命名空间的参数,其中,所述第二IPC命名空间的参数和所述第一IPC命名空间的参数不相同;所述方法包括:所述第一服务的容器通过所述第一网络命名空间中创建的所述环回接口向所述第一负载均衡容器发送服务访问请求;所述第一负载均衡容器根据所述服务访问请求获取所述第二服务的容器对应的服务地 址,所述第二服务的容器对应的服务地址包括所述第二服务的容器对应的所述第二网络命名空间的网络接口地址和所述第二IPC命名空间的IPC接口地址;所述第一负载均衡容器通过所述第二IPC命名空间的IPC接口地址访问所述第二服务的容器。
- 一种容器的部署装置,其特征在于,包括:收发单元,用于接收容器部署消息,所述容器部署消息包括容器镜像信息以及容器的关联信息;处理单元,用于根据所述容器镜像信息创建第一服务的容器以及创建所述第一服务的容器对应的第一网络命名空间和第一进程间通信IPC命名空间;创建所述第一服务的容器对应的第一负载均衡容器,并设置所述第一负载均衡容器的运行参数为所述第一网络命名空间的参数,所述运行参数用于所述第一负载均衡容器在运行时共享所述第一网络命名空间;在所述第一网络命名空间中创建环回接口,所述环回接口用于所述第一负载均衡容器与所述第一服务的容器通信;根据所述容器的关联信息,确定所述网络设备上存在与所述第一服务的容器相关联的第二服务的容器;获取所述第二服务的容器对应的第二IPC命名空间的参数,并设置所述第一负载均衡容器的启动参数为所述第二IPC命名空间的参数;所述启动参数用于所述第一负载均衡容器在启动后通过所述第二IPC命名空间的IPC接口与所述第二服务的容器通信,所述第二IPC命名空间的参数和所述第一IPC命名空间的参数不相同。
- 根据权利要求6所述的装置,其特征在于,所述处理单元还用于:根据所述容器的关联信息,确定所述网络设备上不存在与所述第一服务的容器相关联的容器;设置所述第一负载均衡容器的启动参数为第三IPC命名空间的参数,所述第三IPC命名空间的参数与所述第一IPC命名空间的参数以及所述第二IPC命名空间的参数均不相同。
- 根据权利要求6或7所述的装置,其特征在于,所述装置上创建有网桥,所述网桥用于提供数据交换服务,所述处理单元用于创建所述第一服务的容器对应的第一网络命名空间和第一进程间通信IPC命名空间后,所述处理单元还用于:在所述第一网络命名空间中创建虚拟网络设备,所述虚拟网络设备用于与所述网桥连接,以使所述第一服务的容器与所述第一网络命名空间之外的其他服务的容器通信。
- 根据权利要求8所述的装置,其特征在于,所述处理单元用于创建虚拟网络设备后,所述处理单元还用于:将所述第一服务对应的服务地址发送到服务注册中心;所述第一服务对应的服务地址包括所述虚拟网络设备的网络接口地址和所述第一IPC命名空间的IPC接口地址。
- 一种服务间的通信装置,其特征在于,所述装置上已创建并运行第二服务的容器和对应的第二负载均衡容器,所述第二服务的容器具有对应的第二网络命名空间和第二进程间通信IPC命名空间;在创建第一服务的容器和对应的第一负载均衡容器时;创建所述第一服务的容器对应的第一网络命名空间和第一IPC命名空间,并设置所述第一负载均衡容器的运行参数为所述第一网络命名空间的参数,且在所述第一网络命名空间中创建环回接口,并设置所述第一负载均衡容器的启动参数为所述第二IPC命名空间的参数,其中,所述第二IPC 命名空间的参数和所述第一IPC命名空间的参数不相同;所述装置还包括:第一服务的容器,用于通过所述第一网络命名空间中创建的所述环回接口向所述第一负载均衡容器发送的服务访问请求;第一负载均衡容器,用于根据所述服务访问请求获取所述第二服务的容器对应的服务地址,所述第二服务的容器对应的服务地址包括所述第二服务的容器对应的所述第二网络命名空间的网络接口地址和所述第二IPC命名空间的IPC接口地址;第一负载均衡容器,用于通过所述第二IPC命名空间的IPC接口地址访问所述第二服务的容器。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP17874844.8A EP3471366B1 (en) | 2016-11-25 | 2017-09-28 | Container deployment method, communication method between services and related devices |
US16/414,303 US11003480B2 (en) | 2016-11-25 | 2019-05-16 | Container deployment method, communication method between services, and related apparatus |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201611053035.7A CN108111470B (zh) | 2016-11-25 | 2016-11-25 | 容器的部署方法、服务间的通信方法及相关装置 |
CN201611053035.7 | 2016-11-25 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/414,303 Continuation US11003480B2 (en) | 2016-11-25 | 2019-05-16 | Container deployment method, communication method between services, and related apparatus |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2018095138A1 true WO2018095138A1 (zh) | 2018-05-31 |
Family
ID=62194770
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2017/104108 WO2018095138A1 (zh) | 2016-11-25 | 2017-09-28 | 容器的部署方法、服务间的通信方法及相关装置 |
Country Status (4)
Country | Link |
---|---|
US (1) | US11003480B2 (zh) |
EP (1) | EP3471366B1 (zh) |
CN (1) | CN108111470B (zh) |
WO (1) | WO2018095138A1 (zh) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110209492A (zh) * | 2019-03-21 | 2019-09-06 | 腾讯科技(深圳)有限公司 | 一种数据处理方法及装置 |
CN110224860A (zh) * | 2019-05-17 | 2019-09-10 | 平安科技(深圳)有限公司 | 负载均衡应用创建方法、装置、计算机设备及存储介质 |
CN110502761A (zh) * | 2019-08-27 | 2019-11-26 | 北京金山数字娱乐科技有限公司 | 一种翻译平台及其负载调整方法 |
CN111897551A (zh) * | 2020-08-03 | 2020-11-06 | 上海嗨酷强供应链信息技术有限公司 | 一种云环境下快速克隆软件环境的平台及方法 |
CN112346750A (zh) * | 2020-11-16 | 2021-02-09 | 珠海格力电器股份有限公司 | 组态软件控制方法、系统和存储介质 |
US11283676B2 (en) * | 2018-06-11 | 2022-03-22 | Nicira, Inc. | Providing shared memory for access by multiple network service containers executing on single service machine |
CN115277419A (zh) * | 2022-08-09 | 2022-11-01 | 湖南大学 | 一种无服务计算中加速网络启动方法 |
Families Citing this family (52)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11947489B2 (en) | 2017-09-05 | 2024-04-02 | Robin Systems, Inc. | Creating snapshots of a storage volume in a distributed storage system |
US11748203B2 (en) * | 2018-01-11 | 2023-09-05 | Robin Systems, Inc. | Multi-role application orchestration in a distributed storage system |
US11099937B2 (en) | 2018-01-11 | 2021-08-24 | Robin Systems, Inc. | Implementing clone snapshots in a distributed storage system |
US11392363B2 (en) | 2018-01-11 | 2022-07-19 | Robin Systems, Inc. | Implementing application entrypoints with containers of a bundled application |
US11582168B2 (en) | 2018-01-11 | 2023-02-14 | Robin Systems, Inc. | Fenced clone applications |
CN108833163B (zh) * | 2018-06-13 | 2020-08-28 | 平安科技(深圳)有限公司 | Linux虚拟服务器的创建方法、装置、计算机设备及存储介质 |
US11023328B2 (en) | 2018-07-30 | 2021-06-01 | Robin Systems, Inc. | Redo log for append only storage scheme |
US10976938B2 (en) | 2018-07-30 | 2021-04-13 | Robin Systems, Inc. | Block map cache |
US11074091B1 (en) * | 2018-09-27 | 2021-07-27 | Juniper Networks, Inc. | Deployment of microservices-based network controller |
US11036439B2 (en) | 2018-10-22 | 2021-06-15 | Robin Systems, Inc. | Automated management of bundled applications |
CN109343963B (zh) * | 2018-10-30 | 2021-12-07 | 杭州数梦工场科技有限公司 | 一种容器集群的应用访问方法、装置及相关设备 |
CN109168185B (zh) * | 2018-11-12 | 2021-01-22 | 杭州安恒信息技术股份有限公司 | 一种基于网络命名空间的网络扫描方法及装置 |
CN111340230B (zh) * | 2018-12-18 | 2024-01-23 | 北京小桔科技有限公司 | 一种服务提供方法、装置、服务器及计算机可读存储介质 |
CN109561108B (zh) * | 2019-01-07 | 2020-09-01 | 中国人民解放军国防科技大学 | 一种基于策略的容器网络资源隔离控制方法 |
CN109828851A (zh) * | 2019-01-16 | 2019-05-31 | 烽火通信科技股份有限公司 | 一种基于非管理员权限的进程间通信方法及系统 |
US11075884B2 (en) * | 2019-02-01 | 2021-07-27 | NeuVector, Inc. | Network context monitoring within service mesh containerization environment |
US11086725B2 (en) | 2019-03-25 | 2021-08-10 | Robin Systems, Inc. | Orchestration of heterogeneous multi-role applications |
CN109976771B (zh) * | 2019-03-28 | 2023-06-27 | 新华三技术有限公司 | 一种应用的部署方法及装置 |
US11256434B2 (en) | 2019-04-17 | 2022-02-22 | Robin Systems, Inc. | Data de-duplication |
US11836505B2 (en) * | 2019-05-07 | 2023-12-05 | Ab Initio Technology Llc | Dynamic distribution of container images |
CN110289983B (zh) * | 2019-05-17 | 2022-09-20 | 平安科技(深圳)有限公司 | 负载均衡应用创建方法、装置、计算机设备及存储介质 |
CN112243045A (zh) * | 2019-07-16 | 2021-01-19 | 北京东土科技股份有限公司 | 服务数据处理方法、装置、节点结构及电子设备 |
US11226847B2 (en) | 2019-08-29 | 2022-01-18 | Robin Systems, Inc. | Implementing an application manifest in a node-specific manner using an intent-based orchestrator |
US11520650B2 (en) | 2019-09-05 | 2022-12-06 | Robin Systems, Inc. | Performing root cause analysis in a multi-role application |
US11249851B2 (en) | 2019-09-05 | 2022-02-15 | Robin Systems, Inc. | Creating snapshots of a storage volume in a distributed storage system |
US20210075887A1 (en) * | 2019-09-09 | 2021-03-11 | Red Hat, Inc. | Artificial intelligence-powered diagram-to-deployment converter |
US11347684B2 (en) | 2019-10-04 | 2022-05-31 | Robin Systems, Inc. | Rolling back KUBERNETES applications including custom resources |
US11113158B2 (en) | 2019-10-04 | 2021-09-07 | Robin Systems, Inc. | Rolling back kubernetes applications |
CN110830574B (zh) * | 2019-11-05 | 2023-01-20 | 浪潮云信息技术股份公司 | 一种基于docker容器实现内网负载均衡的方法 |
CN112862658A (zh) * | 2019-11-28 | 2021-05-28 | 中兴通讯股份有限公司 | Gpu运行方法、装置、设备及存储介质 |
US11403188B2 (en) | 2019-12-04 | 2022-08-02 | Robin Systems, Inc. | Operation-level consistency points and rollback |
CN111176788B (zh) * | 2019-12-24 | 2023-08-25 | 优刻得科技股份有限公司 | Kubernetes集群的主节点的部署方法及系统 |
CN113127134A (zh) * | 2019-12-30 | 2021-07-16 | 北京懿医云科技有限公司 | 容器集群、基于容器集群的多租户部署方法及电子设备 |
US11722356B2 (en) * | 2020-01-09 | 2023-08-08 | Vmware, Inc. | Enabling integration of solutions with software-defined networking platform |
CN111209089B (zh) * | 2020-02-28 | 2023-08-22 | 杭州师范大学 | 一种ctf竞赛在线环境类题目安全部署方法 |
CN113395310A (zh) * | 2020-03-12 | 2021-09-14 | 华为技术有限公司 | 一种微服务调用方法、装置、设备及介质 |
CN113676501A (zh) * | 2020-05-13 | 2021-11-19 | 北京金山云网络技术有限公司 | 基于Kubernetes集群的应用部署方法、装置以及电子设备 |
US11108638B1 (en) | 2020-06-08 | 2021-08-31 | Robin Systems, Inc. | Health monitoring of automatically deployed and managed network pipelines |
US11528186B2 (en) | 2020-06-16 | 2022-12-13 | Robin Systems, Inc. | Automated initialization of bare metal servers |
US11740980B2 (en) | 2020-09-22 | 2023-08-29 | Robin Systems, Inc. | Managing snapshot metadata following backup |
US11743188B2 (en) | 2020-10-01 | 2023-08-29 | Robin Systems, Inc. | Check-in monitoring for workflows |
US11271895B1 (en) | 2020-10-07 | 2022-03-08 | Robin Systems, Inc. | Implementing advanced networking capabilities using helm charts |
US11456914B2 (en) | 2020-10-07 | 2022-09-27 | Robin Systems, Inc. | Implementing affinity and anti-affinity with KUBERNETES |
US11750451B2 (en) | 2020-11-04 | 2023-09-05 | Robin Systems, Inc. | Batch manager for complex workflows |
CN112187671B (zh) * | 2020-11-05 | 2024-03-12 | 北京金山云网络技术有限公司 | 一种网络接入方法及其相关设备 |
US11556361B2 (en) | 2020-12-09 | 2023-01-17 | Robin Systems, Inc. | Monitoring and managing of complex multi-role applications |
WO2022128059A1 (en) * | 2020-12-14 | 2022-06-23 | Telefonaktiebolaget Lm Ericsson (Publ) | Load balancing in a system |
CN112698970B (zh) * | 2020-12-31 | 2024-07-12 | 北京千方科技股份有限公司 | 用于微服务架构的服务调用方法、装置及计算机存储介质 |
CN114915609B (zh) * | 2021-01-29 | 2024-06-25 | 中国电信股份有限公司 | 容器多网络平面适配方法和装置 |
CN113360172B (zh) * | 2021-06-30 | 2024-02-27 | 李建 | 应用部署方法、装置、计算机设备及存储介质 |
CN113691624B (zh) * | 2021-08-24 | 2024-07-19 | 亿咖通(湖北)技术有限公司 | 基于容器的数据传输方法及设备 |
CN116033021B (zh) * | 2022-12-29 | 2024-05-28 | 数字广东网络建设有限公司 | 容器化应用网络访问方法、装置、电子设备及存储介质 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103678203A (zh) * | 2013-12-13 | 2014-03-26 | 国家计算机网络与信息安全管理中心 | 一种实现网卡零拷贝方法及装置 |
CN105681217A (zh) * | 2016-04-27 | 2016-06-15 | 深圳市中润四方信息技术有限公司 | 用于容器集群的动态负载均衡方法及系统 |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8656412B2 (en) * | 2009-12-25 | 2014-02-18 | International Business Machines Corporation | Pipeline across isolated computing environments |
EP3108365A1 (en) * | 2014-02-20 | 2016-12-28 | Telefonaktiebolaget LM Ericsson (publ) | Methods, apparatuses, and computer program products for deploying and managing software containers |
US10104166B2 (en) * | 2014-05-20 | 2018-10-16 | Citrix Systems, Inc. | Systems and methods for providing load balancing as a service |
CN105577779A (zh) * | 2015-12-21 | 2016-05-11 | 用友网络科技股份有限公司 | 一种容器化部署大企业私有云的方法和系统 |
US20170272400A1 (en) * | 2016-03-17 | 2017-09-21 | Microsoft Technology Licensing, Llc | Network virtualization of containers in computing systems |
-
2016
- 2016-11-25 CN CN201611053035.7A patent/CN108111470B/zh active Active
-
2017
- 2017-09-28 WO PCT/CN2017/104108 patent/WO2018095138A1/zh unknown
- 2017-09-28 EP EP17874844.8A patent/EP3471366B1/en active Active
-
2019
- 2019-05-16 US US16/414,303 patent/US11003480B2/en active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103678203A (zh) * | 2013-12-13 | 2014-03-26 | 国家计算机网络与信息安全管理中心 | 一种实现网卡零拷贝方法及装置 |
CN105681217A (zh) * | 2016-04-27 | 2016-06-15 | 深圳市中润四方信息技术有限公司 | 用于容器集群的动态负载均衡方法及系统 |
Non-Patent Citations (2)
Title |
---|
DOCKER: "Introduction to Container Security Understanding the Isolation Properties of Docker", WHITE PAPER, 31 August 2016 (2016-08-31), XP055558826, Retrieved from the Internet <URL:www.docker.com> * |
See also references of EP3471366A4 |
Cited By (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11283676B2 (en) * | 2018-06-11 | 2022-03-22 | Nicira, Inc. | Providing shared memory for access by multiple network service containers executing on single service machine |
US11750446B2 (en) | 2018-06-11 | 2023-09-05 | Nicira, Inc. | Providing shared memory for access by multiple network service containers executing on single service machine |
CN110209492B (zh) * | 2019-03-21 | 2023-09-05 | 腾讯科技(深圳)有限公司 | 一种数据处理方法及装置 |
CN110209492A (zh) * | 2019-03-21 | 2019-09-06 | 腾讯科技(深圳)有限公司 | 一种数据处理方法及装置 |
CN110224860A (zh) * | 2019-05-17 | 2019-09-10 | 平安科技(深圳)有限公司 | 负载均衡应用创建方法、装置、计算机设备及存储介质 |
CN110502761A (zh) * | 2019-08-27 | 2019-11-26 | 北京金山数字娱乐科技有限公司 | 一种翻译平台及其负载调整方法 |
CN110502761B (zh) * | 2019-08-27 | 2023-09-19 | 北京金山数字娱乐科技有限公司 | 一种翻译平台及其负载调整方法 |
CN111897551A (zh) * | 2020-08-03 | 2020-11-06 | 上海嗨酷强供应链信息技术有限公司 | 一种云环境下快速克隆软件环境的平台及方法 |
CN111897551B (zh) * | 2020-08-03 | 2021-07-02 | 汇链通供应链科技(上海)有限公司 | 一种云环境下快速克隆软件环境的平台及方法 |
CN112346750A (zh) * | 2020-11-16 | 2021-02-09 | 珠海格力电器股份有限公司 | 组态软件控制方法、系统和存储介质 |
CN112346750B (zh) * | 2020-11-16 | 2022-04-01 | 珠海格力电器股份有限公司 | 组态软件控制方法、系统和存储介质 |
CN115277419A (zh) * | 2022-08-09 | 2022-11-01 | 湖南大学 | 一种无服务计算中加速网络启动方法 |
CN115277419B (zh) * | 2022-08-09 | 2024-01-26 | 湖南大学 | 一种无服务计算中加速网络启动方法 |
Also Published As
Publication number | Publication date |
---|---|
US11003480B2 (en) | 2021-05-11 |
CN108111470B (zh) | 2020-06-16 |
EP3471366A4 (en) | 2019-06-26 |
CN108111470A (zh) | 2018-06-01 |
EP3471366B1 (en) | 2021-06-09 |
EP3471366A1 (en) | 2019-04-17 |
US20190272205A1 (en) | 2019-09-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2018095138A1 (zh) | 容器的部署方法、服务间的通信方法及相关装置 | |
US11743182B2 (en) | Container networking interface for multiple types of interfaces | |
US11301279B2 (en) | Associating virtual IP address of virtual server with appropriate operating system in server cluster | |
US10135726B2 (en) | Virtualization port layer including physical switch port and logical switch port | |
US20170052807A1 (en) | Methods, apparatuses, and computer program products for deploying and managing software containers | |
US20180139174A1 (en) | Central namespace controller for multi-tenant cloud environments | |
US8830870B2 (en) | Network adapter hardware state migration discovery in a stateful environment | |
US9712538B1 (en) | Secure packet management for bare metal access | |
US20220278927A1 (en) | Data interfaces with isolation for containers deployed to compute nodes | |
WO2019204023A1 (en) | Cross-regional virtual network peering | |
US9910687B2 (en) | Data flow affinity for heterogenous virtual machines | |
JP2020515987A (ja) | 分離されたネットワークスタックにわたるインテリジェントなスレッド管理 | |
US20170359414A1 (en) | Management of Advanced Connection State During Migration | |
US10911405B1 (en) | Secure environment on a server | |
WO2013049990A1 (en) | Live logical partition migration with stateful offload connections using context extraction and insertion | |
US20190356697A1 (en) | Methods and apparatus to assign security in networked computing environments | |
US10735319B1 (en) | Virtual container extended network virtualization in server cluster | |
WO2018184701A1 (en) | Method for operating virtual machines on a virtualization platform and corresponding virtualization platform | |
US10853126B2 (en) | Reprogramming network infrastructure in response to VM mobility | |
US10795727B2 (en) | Flexible automated provisioning of single-root input/output virtualization (SR-IOV) devices | |
US9559865B2 (en) | Virtual network device in a cloud computing environment | |
US20190238476A1 (en) | Suppressing broadcasts in cloud environments | |
US10728146B1 (en) | Virtual container dynamic virtual IP address | |
US10929169B2 (en) | Reprogramming network infrastructure in response to VM mobility |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 17874844 Country of ref document: EP Kind code of ref document: A1 |
|
ENP | Entry into the national phase |
Ref document number: 2017874844 Country of ref document: EP Effective date: 20190110 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |