Communication infrastructure equipped with an extensive network of services; associated computer program process and product.

Abstract

Communication infrastructure equipped with an extensive service mesh; Process and associated computer program product.This infrastructure comprises a data plane, consisting of first and second clusters of machines connected by a network. The first cluster, and the second cluster respectively, provide a service (151, 161) equipped with a communication proxy (152, 162). A control plane, for each cluster, consists of a local service mesh, which includes a local controller (13, 23) to configure the local proxy(ies) of the cluster, and a local service routing agent (14, 24) to: discover the services running on the cluster by querying the local controller; send and receive advertisement messages with the local agents of other clusters to share the discovered services across the different clusters; determine a traffic distribution policy for each local proxy; and command the local controller to deploy the distribution policy to each local proxy. (See Figure 2 for the abstract.)

Description

Description Title of the invention: Communication infrastructure equipped with a extended service mesh; Process and program product associated computer.

[0001] = The invention relates to the field of communication infrastructures and, more particu- particularly that of service routing within communication infrastructures.

[0002] — Service routing consists of directing traffic on the infrastructure network communication, between a client application, which requires a service, and an instance of a service application, which is capable of rendering the required service.

[0003] A client application (or client in the following) is any type of software, which is executed on a network machine, such as user equipment, and which is adapted to issue a service request.

[0004] — A service application (or service in the following) is any type of software, which is run on a network machine, such as a server, and is suitable for provide the requested service.

[0005] — Service routing is application-level routing that should not be confused with network-level routing, such as IP routing. It is not simply route the flows to a network machine designated by its IP address, but, among the set of applications running on a machine, to route traffic from or to a particular application, this being for example designated by a Uniform Resource Identifier - URI.

[0006] In a communications infrastructure, multiple instances of the same app- Service applications are executed at the same time on different machines in the network. Therefore, communication between a customer and a service can be seen as an “anycast” communication in which multiple recipients are able to provide the service requested by the customer.

[0007] — Service routing must therefore lead to a routing decision consisting of choose a particular recipient, ie. to choose a particular instance, among all recipients, i.e. instances of the same service application dis- available on the infrastructure.

[0008] — The selection of a recipient can be made according to several criteria to lead to the selection of the most suitable instance of the service application for the customer. It can for example, it may be a load balancing objective between the different instances of the service or even optimization of the quality of user experience of the client application by reducing, for example, the latency of access to the service.

[0009] | Several families of technical solutions are known for the creation of a routing. In "anycast IP routing", the different instances of a service are identified by the same prefix. This prefix is ​​announced via an IP routing protocol (e.g. OSPF, BGP, etc.). The selection of the best route by the IP routing protocol directs the traffic from the sending node on which the client application is running to the receiving node on which the instance of the selected service application is running. It is therefore the routing protocol that selects the best route between machines based on criteria such as the network topology, the routing policy within the network, or the metrics of the routing protocol used on the network. In "load balancing", the service request is directed to the IP address of an intermediate node (this IP address being called a virtual IP address). This intermediate node modifies the address of the recipient with that of the selected service instance. This solution is most often used in a network hosting a large number of service instances such as a data center. Load balancing can be used when the selection of a service instance is made from among a plurality of co-located instances, each of these instances being identified by a different IP address. Packets reaching the virtual IP address of the intermediate node are redirected to the IP address of the selected service instance in a consistent manner. Thus, all packets of the same flow are directed to the same instance. In "domain name resolution," a domain name server (DNS) selects a particular instance when it resolves a domain name. More precisely, when a client seeks to reach a service, it transmits a resolution query to the DNS server, this query containing a domain name. The DNS server resolves the domain name in the resolution query. To do this, the DNS reads the various addresses associated with the domain name from a database. This set of addresses is then ordered by the DNS. The DNS responds to the resolution query by transmitting the ordered set of possible addresses to the client. The client then seeks to reach the first address in this ordered set. To direct traffic, the DNS server simply needs to order the various possible addresses appropriately to direct the client to a specific service instance. In a "Service Mesh", a dedicated layer controls communication between different services co-located on a cluster of machines. A cluster, for example of servers, is a set of machines of the same type (terminals, computers, servers, etc.) communicating along a communication link. Typically, a service is actually atomized into a plurality of elementary microservices. Receiving a request from a client requesting the implementation of this service triggers the execution of a series of microservices. For example, providing the service consists of first executing a microservice for querying a database, then a microservice for formatting the response, and finally a microservice for encrypting this response. The service mesh then allows the networking of these microservices and the management of traffic between these microservices on the communication link of the cluster of machines. A service mesh includes, associated with each service instance, a communication proxy. Optionally, an ingress proxy associated with a gateway service ensures the connection between the communication link of the cluster of machines and an external communication network, such as the internet. The service mesh also includes a controller, which allows in particular to discover the instances of the different services present on the cluster of machines, then to configure the different proxies of the discovered instances in order to finely manage the distribution of traffic between these different service instances. The discovery step allows to associate a logical identifier, such as a domain name or a URI, representing the type of service of each deployed instance, as well as a technical identifier to access a particular instance, such as an IP address). The purpose of this controller is first to discover the service instances deployed on the cluster, then to configure the communication proxies of each of these instances according to a management policy. This management policy is defined by a management operator prior to the deployment of the cluster's software configuration. This policy is therefore static. Additionally, the controller also aims to manage certificate management for secure communication between proxies in the cluster. Thus, the different proxies, each of which constitutes a communication interface of the associated service instance, will be configured in a coherent manner within the service mesh by the messages of a control plane. A service mesh addresses the various limitations of the other technical solutions mentioned above. Thus, a service mesh allows for routing at the service level (application layer 7 of the OSI model — “Open Systems Interconnection”), whereas IP anycast routing allows for routing at the communication protocol level (network layer 3 of the OSD model). Thus, the service mesh offers much finer granularity. The load balancer, which also offers less granulation since it relies on connection identifiers from layer 4 of the OSI model, mainly forms a bottleneck since it intercepts all requests from service, where a service mesh allows traffic management by configuring each of the communication proxies. Finally, the DNS server can hardly respond quickly to a failure or overload event of a service instance. More generally, the update time of a DNS server is not compatible with the level of decision required for a client application. However, the disadvantage of the technical solution of a service mesh is that it was designed to be deployed locally, on a cluster of machines, particularly in a data center. However, we would like to develop the service mesh so that it can operate on an architecture where services can be provided by several distinct clusters but interconnected by an intermediate communication network, in particular clusters physically located on remote sites. It should be noted that it is currently possible to extend the discovery carried out by a service mesh to services offered on different distinct clusters, but by relying on a centralized solution allowing the configuration of all the clusters and ensuring their consistency. The distribution of traffic between these services is configured statically, prior to the deployment of the software configurations of each of the clusters. For example, the “Admiral” software (registered trademark) allows the development of a centralized and hierarchical service mesh on several clusters. However, there is no service routing mechanism that is adaptive, i.e., one that can take into account the dynamic evolution of the communication infrastructure during its use, such as the availability of different service instances and the state of the network in the service routing decision. The present invention therefore aims to address this problem. To this end, the subject of the invention is a communication infrastructure provided with an extended service mesh, the communication infrastructure comprising a data plane and a control plane, the data plane comprising a first cluster of machines and a second cluster of machines connected to each other by an intermediate network by means of a first gateway and a second gateway respectively, the first cluster of machines providing at least a first service provided with a first communication proxy and the second cluster of machines providing at least a second service provided with a second communication proxy, the control plane comprising a first local service mesh and a second local service mesh, the first local service mesh comprising a first controller provided by the first cluster of machines and adapted to configure the first communication proxy so that it implements a traffic distribution defined by the first controller, and the second local service mesh comprising a second controller provided by the second cluster of machines and adapted to configure the second communication proxy so that it implements a traffic distribution defined by the second controller, the infrastructure being characterized in that the first cluster of machines is provided with a first service routing agent and the second cluster of machines is provided with a second service routing agent, the first service routing agent, respectively the second service routing agent, being adapted to: discover the services executed at the current time on the first cluster of machines by querying the first controller, respectively on the second cluster of machines by querying the second controller;transmitting and receiving announcement messages with the second agent, respectively the first agent, so as to share information relating to the discovered services; depending on the services executed at the current time on the first and second clusters of machines, determining a first traffic distribution policy for the or each first proxy of the first cluster of machines, respectively a second traffic distribution policy for the or each second proxy of the second cluster of machines; and, commanding the first controller, respectively the second controller, so that the latter deploys the first traffic distribution policy, respectively the second traffic distribution policy. According to particular embodiments, the infrastructure includes one or more of the following characteristics, taken in isolation or in all technically possible combinations: - the first service routing agent, respectively the second service routing agent, is adapted to receive from the first gateway, respectively from the second gateway, information on a state of the network, and to determine the first traffic distribution policy, respectively the second traffic distribution policy not only as a function of the services executed at the current time on the first and second clusters of machines, but also of the current state of the network. - the first service routing agent, respectively the second service routing agent, is a software agent external to the first controller, respectively to the second controller, which communicates with the first controller, respectively the second controller, on an external programming interface of the latter. - the control plan is extended to the first and second clusters of machines. - the first service routing agent, respectively the second service routing agent, is configured with an address of the second service routing agent, respectively of the first service routing agent. - the first service routing agent, respectively the second routing agent of services, is configured with a general objective of traffic distribution. The invention also relates to a method which is implemented in the preceding communication infrastructure and which is characterized in that, during the execution of the first service routing agent, by the steps of: interrogating the first service routing agent of the first controller to know the local services executed on the first cluster of machines at the current time; sending an announcement message to the second service routing agent with information on the local services; receiving an announcement message from the second service routing agent in order to know the remote services executed on the second remote cluster of machines at the current time; determining by the first service routing agent an optimal policy for distributing traffic between the local and / or remote services at the current time; and, communicating to the first controller the optimal policy determined for execution by said first controller. Preferably, the method further comprises a step of interrogation by the first service routing agent of a first gateway connecting the first cluster of machines to the intermediate network, in order to obtain a state of said network at the current time, the determination of the optimal traffic distribution policy also taking into account the state of the network at the current time. More preferably, the method in which querying the first controller to find out the local services executed on the first cluster of machines makes it possible to obtain, for each instance of a service executed on the first cluster of machines, metadata expressing operating constraints of the service instance considered. The invention also relates to a computer program product comprising software instructions which, when executed by a computer, implement the preceding method. The invention and its advantages will be better understood upon reading the following detailed description of a particular embodiment, given solely as an illustrative and non-limiting example, this description being made with reference to the appended drawings in which: [Fig.1] [Fig.1] is a schematic representation of one embodiment particular of a communication infrastructure according to the invention; [Fig.2] [Fig.2] is a representation of communications in the infrastructure of [Fig.1]; [Fig.3] [Fig.3] is a schematic representation of a software agent provided in the infrastructure of [Fig.1]; and, [Fig.4] [Fig.4] is a block representation of a process of operation of the software agent of [Fig.3]. [Fig. 1] is a schematic representation of a communication infrastructure 1 according to the invention. The infrastructure | comprises a first cluster of servers 10 and a second cluster of servers 20. The first server cluster 10 and the second server cluster 20 are interconnected by an intermediate network 3. The network 3 is for example a wide area network - WAN. The first server cluster 10 comprises a first gateway unit 11 for establishing communication between a first communication link 12 internal to the first cluster 10 and the external network 3. Connected to this first communication link 12, the cluster 10 comprises at least a first service unit 15, a first controller 13 and a first service routing agent 14. The first service unit (sometimes referred to as a “pod”) incorporates a first service instance 151, associated with a first communication proxy 152. All communication, both upstream and downstream, between the first service instance 151 and the communication link 12 takes place through the proxy 152, therefore acting as a communication interface for the first instance 151. Similarly, the second server cluster 20 comprises a second gateway unit 21 connecting a second communication link 22 of the second cluster 20 with the external network 3. Connected to this second communication link 22, the second cluster 20 comprises a second service unit 26, a third service unit 27, as well as a second controller 23 and a second service routing agent 24. The second service unit 26 contains a second service instance 261 associated with a second communication proxy 262 for communicating over the second communication link 22. The third service unit 27 contains a third service instance 271 interfaced with the second communication link 22 by a third communication proxy 272. In [Fig. 1], a user device 5 connected to the network 3 is shown. It executes a client application 6 capable of requesting a service whose provision requires the execution of one and / or other of the service instances 151, 261, 271. Preferably, the server clusters are configured by deploying an initial software configuration. This is provided by a centralized orchestrator 50 that pushes the configuration elements to each cluster. These elements are, for example, “Kubernetes” (registered trademark) components. Alternatively, the software configuration is prepared by a planning device common to the different clusters, then transmitted to local orchestrators equipping each cluster, the latter being responsible for carrying out a local deployment of the configuration. The initial configuration indicates the service(s) that a cluster must provide, as well as the constraints to be respected for the provision of each of these services (for example, an instance of a service A must operate by benefiting from x% of the computing capacity of the machine that executes it and, when this is no longer the case, initialize a new instance of service A on another machine in the cluster). The initial configuration also indicates the elements of the local service mesh associated with these services. In particular, it assigns one or more objectives to each software agent. An objective is a general, high-level constraint. It may, for example, be an authorization of communication between services belonging to a first type of service and those belonging to a second type of service across the network 3. It may, for example, also be a constraint on traffic distribution, such as the balanced distribution of data flows leaving a first cluster to a second cluster or a third cluster in the infrastructure. This flow distribution policy may be more precise and broken down by service (for example, to reach a type of service, send 70% of the traffic to the local instance, 20% to a first remote site and 10% to a second site). The local service mesh consists of a proxy per service instance, the controller, and the software agent. How these different applications are executed is not specified. Thus, instances of the controller, the software agent, a service unit, or a gateway unit can be co-located on the same machine in the cluster or on different machines. The person skilled in the art is familiar with software such as “Kubernetes” (registered trademark) which allows a software configuration to be developed, this configuration to be deployed on a cluster of machines, and this configuration to be managed during its execution (creation of new instances, deletion of certain instances, etc.) Thus, each cluster is associated with a single local service mesh, i.e., a single controller. According to the invention, a local service mesh further comprises a single service routing agent. A service routing agent is therefore associated with each controller present on the infrastructure. The service routing agent is software deployed in a co-located manner with the controller of the local service mesh that this controller manages. When we speak for example of the first agent 14, we will speak of the first controller 13 as a local controller or of the first service instance 151 or the first proxy 152 as a local service instance or a local proxy. The service routing agent can be a software component integrated directly into the local controller, for example as a plug-in. It then advantageously relies on the local controller's internal API (Application Programming Interface). However, preferably, the service routing agent is an external software relying on the local controller's external API. The latter solution is preferable for reasons of interoperability of a software agent with different possible implementations of a local service mesh controller. This allows the same service routing agent to be able to supervise different types of controller, for example those provided by the "linkerd" or "istio" service meshes (registered trademarks). The general function of a service routing agent is to extend the control plane to different clusters in a distributed manner, i.e. different local service meshes, to together enable a user's service request to be responded to. A local agent locally discovers the instances of the services present. For each of these instances, it collects information including metadata. This metadata defines a specific objective for service routing in terms of expected performance for this given service (for example, a guarantee in terms of latency, bandwidth or request processing time). The local agent advertises this information to remote agents so that each agent in the infrastructure can establish a topology of the service instances available on the infrastructure. The local agent uses this topology of service instances to then make a service routing decision (or optimal policy in the following) and configure the local service mesh accordingly, via the local controller. An optimal service routing policy, in addition to the constraints expressed by the metadata, relies on a general traffic management objective, for example uniform load balancing between clusters or asymmetric (for example 70 / 30 / 10 between three sites). The constraints provided by the metadata make it possible to select, from among all the service instances deployed on the different clusters, the subset of service instances that respect these constraints. The general traffic management objective is then applied to this subset. The general traffic management objective can be provided to the local agent during the deployment of the initial configuration. This general objective can be specified with a granularity going down to the type of service. [Fig.2] represents communications over the infrastructure of [Fig.1]. Communications are divided into a data plane and a control plane. The data plane corresponds to the exchange of data between applications. More specifically, the data plane enables the exchange of data between instances of service. Between two co-located instances, such as instances 261 and 271, this communication is carried out via a link 49 along the communication link 22 of the cluster 20, and the associated proxies 262 and 272. Between two remote instances, such as instances 151 and 261, this communication is carried out via a link 37 (along the communication link 12 between the proxy 152 and the gateway 11), a link 30 on the network 3, and a link 47 (along the communication link 22 between the gateway 21 and the proxy 262). Similarly, between instances 151 and 271, this communication is carried out via the link 37, the link 30, and a link 48 (along the communication link 22 between the gateway 21 and the proxy 272). The control plane corresponds to the service communications allowing the configuration of the different proxies associated with each of the service instances running at the current time. These communications allow — but are not limited to — the discovery of local service instances and the management of traffic between service instances via the configuration of the proxies, On the side of the first cluster 10, the local control plane of the local service mesh comprises the first controller 13. The first controller 13 is adapted to receive information from the proxy 152 via a channel 35. Preferably, this information makes it possible to describe the service instance, to evaluate its current performance (telemetry data on the traffic emitted by the service instance for example), and to define operating constraints of the service instance considered. These constraints are expressed by metadata that provides the network requirements of the service instance associated with the sending proxy. For example, a piece of metadata indicates the optimal latency required by the service instance to operate correctly. More generally, this metadata constitutes a "Service Level Agreement" (SLA) defining the level of service that the service instance wishes to obtain for optimal operation. The first controller 13 is adapted to transmit configuration commands to the proxy 152 via a channel 36. These commands may for example be a rule for routing traffic to particular service instances. Ÿ all the technical identifiers necessary to carry out this traffic distribution are added. The control plane also includes, for the first cluster 10, the first agent 14. The latter makes it possible to extend the local control plane. The first agent 14 is adapted to receive, on a channel 33, data from the first controller 13, in particular information relating to the local service instances. The first agent 14 is in communication, via a channel 32, with the second agent 24 of the remote cluster 20, so as to transmit announcement messages to it. indicating the instances running on the first cluster 10. The first agent 14 receives, on a channel 42, the announcement messages sent by the second agent 24 of the remote cluster 20. It thus receives the information relating to the instances executed on the second cluster 20. The first agent 14 is in communication via a channel 31 with the gateway unit 11, so as to receive information on the instantaneous state of the network 3 between the first and second gateway units, 11 and 21. For example, the instantaneous state of the network is given by the instantaneous latency measured along the link 30, or the bandwidth measured along the link 30. This data relating to the state of the network can be instantaneous measurements or the result of a metric based on a time series of measurements. The first agent 14 is in communication via a channel 51 with the orchestrator 50, so as to receive, at the time of initial deployment, a general traffic distribution objective, such as a general load distribution objective. The first agent 14 is capable of determining an optimal service routing policy at the current time. To do this, the agent 14 relies on the metadata, the measurements made by the gateway 11, and the general objective initially defined by the orchestrator. The optimal policy defines lower-level constraints. For example, the optimal policy defines the distribution of traffic emitted by an instance of a service A at 50% to a first instance of a service B located on the same cluster as the instance of service A and at 50% to a second instance of service B located on a cluster distant from that on which the instance of service A is executed. The first agent 14 is in communication with the first controller 13 via a channel 34 allowing the first agent to transmit the traffic management policy that it has just developed to the first controller 13 for execution. This policy allows the controller 13 to consider, in addition to the local service instances, the remote service instances discovered by the agent 14, as well as the distribution of traffic between the local or remote instances. Symmetrically, on the second cluster 20, the second controller 23 is in communication with the second and third proxies along a channel 46 so as to configure them and along a channel 45 to obtain information on the state of the associated services. The second agent 24 is connected to the second controller 23 by channels 43 and 44, to the second gateway unit 21 by a channel 41, to the first service routing agent 14 by channels 32 and 42 and to the service orchestrator 50 by a channel 52. It should be noted that channels 32, 42, 51 and 52 are communication links which physically pass over network 3, via gateways 11 and 21. [Fig.3] is a functional representation of a service routing agent, such as agent 14. The agent 14 comprises a local services discovery module 141. This module is adapted to query the local controller in order to receive the current list of local services which must be exposed between the different clusters, and to obtain information on each of these services, in particular the metadata expressing operating constraints. A service is exposed at the discretion of the local controller, for example by associating with this service, a metadata authorizing its remote announcement. The module 141 is capable of recording the information received in a table 142 of local services.In the preferred embodiment, the information received is description information (such as the name of the service, the type of the service, the tenant or user of the service, technical identifiers for accessing the service such as its IP address, its port, etc.), performance indicators (such as the rate of use of the service, the current latency, etc.), and metadata (such as ranges of SLA values). The agent 14 comprises an announcement transmission-reception module 143. In transmission, this module generates announcement messages addressed to the agents of the other clusters. The recipients of these announcement messages are known to the agent in question. The latter stores, for example, a list 148 of the remote service routing agents. This table is filled in during the initial configuration of the network and the deployment of the service mesh. An announcement message comprises the information from the first table 142 which is transmitted to the remote agents. In reception, the module 143 receives the announcement messages from the remote service routing agents. The module 143 is then able to update a second table 144 dedicated to the remote services. The information stored in this second table 144 is, for example, the name and an identifier of the cluster on which the remote service is deployed, the name of the service, the type of service, the tenant or user of the service, the rate of use of the service, technical identifiers for accessing the service such as its IP address, its port, etc. Thus, each service routing agent is able to memorize all the services deployed at the time considered on the communication infrastructure. This exchange of announcement messages can be achieved by implementing a data replication system, such as a distributed database across the different clusters. For example, for resilience reasons, a distributed database of the "eventually consistent" type. The agent 14 includes a network status determination module 145. This module is capable of interrogating the local gateway unit, which collects information on the state of the network. The module 145 is capable of maintaining a third table 146 on the state of the network. This table includes, for example, for each cluster accessible via a route on the network 3 originating from the local gateway, a measurement of the latency along this route and of the bandwidth offered along this route. Alternatively, other indicators can be measured and taken into account. Finally, the agent 14 includes a module 147 for defining an optimal policy based on the information in tables 142 and 144 relating to the services, table 146 relating to the network and the general traffic distribution objective defined during the initialization of the “service mesh” by the orchestrator 50. Once an optimal policy has been defined by the agent, module 147 is able to transmit it to the local controller so that this policy is deployed to the proxies of the various local services. In this way, proxies manage communications not only between proxies co-located on the same cluster, but also communications between remote proxies located on separate clusters. The agent 14 is executed regularly during the use of the infrastructure so as to be able to take into account any changes in the services or the state of the network. For example, in the event of a drop in bandwidth to a service instance belonging to a first remote cluster, an agent can control, via the associated controller, the configuration of the local proxies in order to direct the flow to another instance of this same service executed by a second cluster different from the first. It should be noted that depending on the type of communication between services, the service mesh can ensure adherence to already established links and take into account the updated policy only for the establishment of new links. This makes it possible in particular to avoid breaking a current link, while the service instance using this link maintains a state with respect to this link. [Fig.4] is a block representation of a method of executing a service routing agent, such as agent 14. The method 100 is performed at each execution of module 14. In a step 1041 the module 141 is executed to update the table 142. The agent 14 queries the local controller 13 to know the instances of the services executed on the local cluster at the current time and to obtain information on each of these services, current operating indicators and metadata. The information received from the controller 13 allows the module 141 to update the table 142. In a step 1043, the module 143 is executed in transmission: the agent 14 develops announcement messages from the content of the first table 142 in order to communicate to the remote agents the locally implemented service instances. In step 1044, the module 143 is executed in reception: the agent 14 receives the announcement messages coming from the remote service routing agents. The module 143 is able to extract from these messages information concerning the services executed on the remote clusters at the current time. This information allows the module 143 to update the table 144 of the remote services. In step 1045, the agent 14 queries the local gateway unit 11 to obtain updated indicators describing the state of the network 3 and the connections with the remote clusters. This information allows the module 145 to update the table 146 relating to the state of the network. In step 1047, the module 147 is executed so as to determine an optimal policy for distributing traffic between service instances at the current time. For this, the module 147 uses the information on the services available at the current time (first table 142 and second table 144), the metric describing the instantaneous state of the network (table 146), and the general objective implemented by the agent. Then, in step 1048, the module 147 transmits the current optimal policy to the local controller 13 so that the latter configures each of the proxies of the local services in accordance with the optimal policy determined in step 1047. The local controller 13 executes the current optimal policy by issuing suitable commands to the different local proxies. As indicated by loop 1050, the service routing agent 14 is executed periodically so as to manage traffic dynamically taking into account the evolution of the services, available both locally and remotely (such as for example launching a new instance, deleting an inactive instance, duplicating a highly requested instance, etc.), and the state of the network (such as for example poor bandwidth to a remote cluster or an interruption of communication with this remote cluster). The present invention has many advantages. The proposed solution enables end-to-end communication between distributed clusters that is autonomous, automatic and resilient, while adapting to the operational situation. The control plane is extended between the different local service meshes (one mesh being associated with one controller). This allows the discovery of not only local services but also remote services. The control plane then allows the implementation of a short regulation loop for traffic management between remote networks hosting services. Connectivity between remote sites, via one or more underlying networks, may be intermittent or see its characteristics evolve rapidly (as is the case for an edge network, especially a theater network), the service mesh is extended by taking into account a network metric. This makes it possible to dynamically take into account, for example, the instantaneous latency between two service instances running on remote machines, or the instantaneous bandwidth available between these two instances. Taking into account a network metric, possibly in association with other metrics (such as a metric of computing load or memory occupancy of the services), thus allows adaptive traffic management in the extended service mesh. It should be noted that in state-of-the-art service meshes dedicated to controlling communications between co-located service instances, the following assumptions are implicitly made: since communications are carried out on the cluster's communication link, latency is almost zero; furthermore, the bandwidth available on this communication link is considered infinite. However, these assumptions are not found in the case of remote services. There is therefore a strong advantage in taking network constraints into account for dynamic management of communications between remote services. Extending the control plane between different local meshes is achieved at the cost of exchanging announcement messages. However, the volume of information exchanged remains minimal and therefore does not degrade bandwidth. In the proposed architecture, there is no hierarchy or centralized control. Control is decentralized to the level of each cluster. The present invention is an extension of the service mesh technique to edge network architectures, particularly theater networks. This extension of the service mesh remains compatible with local service meshes of the state of the art. It should be noted that the elements of the communication infrastructure in [Fig.1] such as clusters, service routing agents, controllers, etc., can be supervised by a service orchestrator. This service orchestrator can be centralized between the different clusters. It constitutes a long control loop on the infrastructure where the service routing agents constitute a short and therefore reactive control loop. The deployed service mesh includes a software agent associated with each controller in a local service mesh. A software agent synchronizes the local control plane of the controller at the site it equips with that of remote sites. Together, the software agents extend service discovery between different sites. A software agent updates the distribution policy implemented by the local service mesh controller. Thus, the distribution of traffic by the proxies of services take into account communication constraints when it comes to communication between clusters or between sites. The invention makes it possible to implement adaptive service routing (i.e. taking into account the availability of the different service instances and the state of the network in the service routing decision), and dynamic (i.e. which does not rely on a static configuration, but makes a routing decision based on the performance of the service instances and / or the communication infrastructure), and distributed (i.e. which relies on a distributed control mechanism between the different clusters constituting the infrastructure). In addition, the present invention can rely on metadata associated with the types of service, which can be consulted during the service discovery stage. In addition, the present invention may be based on a general objective in terms of network SLA, or infrastructure load for communications between remote services. Such a general objective may, for example, consist of restricting the set of service instances that can be used for communication between services (for example, only instances accessible in less than 50 ms of latency and whose CPU load does not exceed 80%) will be selected. It should be noted that state-of-the-art solutions using a centralized control point, such as the “Admiral” software (in its version 1.2), make it possible to build a multi-cluster configuration that this control point (central orchestrator or controller of local orchestrators located in the different clusters) is then able to deploy. But unlike the invention, once deployed, this configuration is essentially frozen. No information is sent back from a cluster to the central orchestrator or the means implementing the “Admiral” software to dynamically update the configuration of the service mesh control plane. For example, if a new instance of a service A is launched to meet the deployment constraints of service A on the cluster, the deployed service mesh is not impacted.On the contrary, with the invention, the local agent is informed of this modification and updates the service mesh policy. Where a solution bases a slow regulation loop on a centralized orchestration system, the present invention achieves a fast regulation loop. Since the control plane management is performed by local agents, the present invention is more resilient in the event of failure of one or the other agent, than a solution based on a centralized control point, which ceases to function if this control point fails or if communications with this control point are broken.

Claims

Claims

1. Communication infrastructure (1) provided with a service mesh extended, the communication infrastructure including a plan of data and a control plane, the data plane comprising a first cluster of machines (10) and a second cluster of machines (20) connected to each other by an intermediate network (3) by means of respectively of a first gateway (11) and a second gateway (21), the first cluster of machines providing at least one first service (151) provided with a first communication proxy (152) and the second cluster of machines providing at least a second service (261) equipped with a second communication proxy (272), the control plane comprising a first local service mesh and a second local service mesh, the first service mesh premises comprising a first controller (13) provided by the first cluster of machines and adapted to configure the first proxy of com- communication to implement a defined traffic distribution by the first controller, and the second local service mesh comprising a second controller (23) provided by the second cluster of machines and adapted to configure the second communication proxy so that it implements a traffic distribution defined by the second controller, characterized in that the first cluster of machines is provided with a first service routing agent (14) and the second cluster of machines is equipped with a second service routing agent (24), the first service routing agent, respectively the second agent service routing, being suitable for: discover the services running at the current time on the first cluster of machines by interrogating the first controller, respectively on the second cluster of machines by questioning the second controller; send and receive announcement messages with the second agent, respectively the first agent, so as to share information relating to the services discovered; depending on the services executed at the current time on the first and second clusters of machines, determine a first traffic distribution policy for the or each first proxy of the first cluster of machines, respect- tively a second traffic distribution policy for the or each second proxy of the second cluster of machines; And, command the first controller, respectively the second controller, so that the latter deploys the first policy traffic distribution, respectively the second policy of traffic distribution.

2. Infrastructure according to claim 1, wherein the first agent of service routing (14), respectively the second routing agent of services (24), is adapted to receive from the first gateway (11), respectively from the second gateway (21), information on a network status (3), and determine the first distribution policy of the traffic, respectively the second non-traffic distribution policy only based on the services running at the current time on the first and second clusters of machines, but also of the state network current.

3. Infrastructure according to claim 1 or claim 2, in which the first service routing agent (14), respectively the second service routing agent (24), is an external software agent to the first controller (13), respectively to the second controller (23), which communicates with the first controller, respectively the second controller, on an external programming interface of the latter.

4. Infrastructure according to any one of claims 1 to 3, in which the control plane is extended to the first and second clusters of machines.

5. Infrastructure according to any one of claims 1 to 4, in which the first service routing agent (14), respectively the second service routing agent (24), is configured with an address of the second service routing agent (24), respectively of the first service routing agent (14).

6. Infrastructure according to any one of claims 1 to 5, in which the first service routing agent (14), respectively the second service routing agent (24), is configured with a purpose general traffic distribution.

7. Method (100) implemented in a communication infrastructure (1) according to any one of claims 1 to 6, characterized in that, when executing the first service routing agent (14), said method comprises the steps of: - query the first service routing agent (14) of the first controller (13) to know the local services executed on the first cluster of machines (10) at the current time; - send an announcement message to the second routing agent of services with information on local services: - receive an announcement message from the second service routing agent in order to know the remote services running on the second cluster of machines (20) remote at the current time; - determined by the first service routing agent of a policy optimal distribution of traffic between local and / or remote services the current moment; and, - communicate to the first controller the determined optimal policy for execution by the said first controller.

8. The method of claim 7, further comprising a step query by the first service routing agent (14) of a first gateway (11) connecting the first cluster of machines (10) to the intermediate network (3). in order to obtain a state of said network at the moment current, the determination of the optimal traffic distribution policy also taking into account the state of the network at the current time.

9. A method according to claim 7 or claim 8, wherein in- ask the first controller (13) about local services executed on the first cluster of machines (10) makes it possible to obtain, for each instance of a service running on the first cluster of machines, metadata expressing functional constraints- operation of the service instance considered.

10. Computer program product comprising software instructions which, when executed by a computer, implement a method according to any one of claims 7 to 9.